VCF에서 VMware vSphere Kubernetes 서비스 설계: 주요 웨비나와 현장 질문 답변

출처: VMware 블로그

최근 진행한 VMware vSphere Kubernetes Service (VKS) on VMware Cloud Foundation 웨비나를 놓치셨다면 걱정 마세요. Momentum AI CIO인 Caleb Washburn과 제가 아키텍처와 설계에 대해 이야기했으며, VCF Professional Services 수석 아키텍트인 Libby Shen이 청중의 다양한 질문에 답했습니다. 이번 글에서는 라이브 세션의 최고의 Q&A와 고객 현장에서 매일 마주하는 주요 질문들을 모아 직접 전달합니다.

아키텍처, 가용 영역 및 배포

Q: VMware vSphere Supervisor, VKS 클러스터 및 가용 영역(AZ)을 설정하려면 최소 몇 대의 VMware ESX 호스트가 필요합니까?
A: VMware vSAN 및 HA를 지원하기 위한 ESX 호스트 클러스터의 표준 최소 요구 사항은 3대입니다. VCF에서 AZ는 독립적인 물리적 장애 도메인의 논리적 구성을 의미하며, 일반적으로 쿼럼과 가용성을 유지하려면 영역당 최소 3대의 호스트가 필요합니다.

Q: 관리 제어 플레인을 위해 두 데이터 센터에 걸친 단일 스트레치 ESX 메트로 클러스터를 사용하지 않는 이유는 무엇인가요? 지원되나요?
A: 스트레치 클러스터는 VCF 9.x의 관리 도메인과 워크로드 도메인 모두에서 완전히 지원됩니다. 다만 VCF 9.1에서는 3‑Zone 배포 모델을 현대적인 표준으로 강력히 권장하고 있습니다. 이는 2‑사이트 메트로 클러스터에서 발생할 수 있는 스플릿‑브레인 위험 없이 더 높은 장애 내성을 제공합니다.

Q: 워커 노드가 ESX 호스트에 존재한다면, vSphere Supervisor 제어 플레인 VM과 워크로드 클러스터 제어 플레인 VM은 어디에 배치되나요?
A: VKS에서는 vSphere Supervisor 제어 플레인과 워크로드 클러스터 노드 모두 최종적으로 ESX 위에서 실행됩니다. vSphere Supervisor 제어 플레인 VM은 vSphere Supervisor가 활성화된 vSphere 클러스터에 배포되며 vCenter/VCF가 관리합니다. 워크로드 클러스터를 생성하면 해당 Kubernetes 제어 플레인 노드와 워커 노드도 ESX 호스트에 VM으로 프로비저닝되며, 일반적으로 DRS/HA에 의해 배치 및 가용성 규칙에 따라 분산됩니다. 따라서 ESX가 공통 기반이며, 차이는 해당 VM이 vSphere Supervisor 플랫폼 제어 플레인에 속하는가, 아니면 테넌트/워크로드 Kubernetes 클러스터에 속하는가에 있습니다.

Q: 영역을 활용해 K8s 클러스터의 노드 풀에 HA를 적용할 수 있나요?
A: 네. VCF 9.1에서는 노드 풀을 vSphere Zone에 걸쳐 분산시킬 수 있습니다. 이를 통해 단일 클러스터의 워커 노드가 여러 물리적 장애 도메인에 걸쳐 배치되어 진정한 고가용성을 달성할 수 있습니다.

Q: vSphere Supervisor의 가상 머신 서비스를 사용해 VM을 배포하는 것과 vCenter를 통한 “클래식” 방식으로 배포하는 것의 차이는 무엇인가요?
A: 클래식 vCenter UI를 통한 VM 배포는 명령형이며 수동 작업입니다. 반면 VM 서비스는 개발자가 Kubernetes 선언형 API(YAML 파일)로 가상 머신을 프로비저닝하도록 해, 선언형·셀프서비스 GitOps 모델을 구현합니다. 이는 VM을 Kubernetes 객체처럼 취급해 컨테이너와 동일한 자동화된 CI/CD 파이프라인에 포함시킬 수 있게 합니다.

VMware Cloud Foundation 자동화 통합

Q: vCenter의 vSphere Supervisor용 External IP Block이 VCF Automation Organization IP Space Block과 달라야 하나요, 아니면 서브넷을 분할해서 사용할 수 있나요?
A: vSphere Supervisor External IP Block과 VCF Automation Organization IP Space / External IP Block이 반드시 완전히 별개의 라우팅 네트워크일 필요는 없습니다. 동일한 큰 라우팅 서브넷에서 파생될 수 있습니다. 다만 각 소비자에게 할당되는 실제 범위는 중복되지 않아야 하며, 동일한 VMware NSX/VCF IPAM 할당 구조를 통해 관리되지 않는 한 겹치면 안 됩니다. 실무에서는 상위 서브넷을 전용 서브 블록으로 나누어 하나는 vSphere Supervisor/VKS 외부 서비스용, 다른 블록은 VCF Automation 조직이나 VPC용으로 구분하는 것이 좋습니다.

네트워킹, 컨테이너 네트워크 인터페이스 (CNI), 및 로드 밸런싱

Q: VKS는 어떤 CNI를 사용하나요? Cilium, Antrea, Calico를 사용할 수 있나요?
A: VKS 클러스터의 기본 CNI는 Antrea이며, VCF 9.1에서는 Antrea‑NSX 어댑터를 통해 NSX 스택과 깊게 통합됩니다. VKS는 CNCF‑준수이므로 게스트 클러스터 내에서 Calico나 Cilium 같은 다른 CNI도 실행할 수 있지만, Antrea가 가장 원활한 네이티브 가시성을 제공합니다. VKS 3.6부터는 “bring your own CNI”가 허용됩니다.

**Q: 전통적인 vSphere 8 NSX Classic 방식과 비교했을 때 VKS 시나리오에서 VPC를 사용하는 주요