Getting started with vSphere with Tanzu

vSphere 7.0U1의 출시로 vSphere with Kubernetes는 VMware Cloud Foundation(VCF)에서 분리되었다. VMware는 현재 두 개의 vSphere with Kubernetes 제품을 보유하고 있으며, 원래 VCF 기반 vSphere with Kubernetes 제품 및 VCF 외부의 새로운 제품인 vSphere with Tanzu 제품을 보유하고 있다. 이 기록은 HA-Proxy가 포함된 Tanzu와 함께 새로운 vSphere를 구축하는 과정을 밟기 위한 것이다. 나는 이 단 하나의 게시물에서 모든 것을 커버하지 않고, 그 과정을 밟고 있는 4개의 게시물을 연재 할 것이다.

차이점: Tanzu와 VCF, Tanzu와 vSphere의 차이점

나는 두 버전의 비교로 시작하는 것이 유용하다고 생각했다. VCF에서 쿠베르네츠가 포함된 vSphere의 원래 버전을 홍보할 때 다음 슬라이드를 사용했었다.

이 슬라이드를 사용하여 VMware는 Tanzu와 함께 VCF의 다양한 서비스가 vSphere에서 기본적으로 PodVM 형태로 컨테이너를 제공하는 방법, NSX-T가 Supervisor 클러스터와 TKG 클러스터 모두에 로드 밸런싱을 제공하는 방법, vSphere CSI 드라이버와 CNS가 통합되어 Supervisor Cluster와 TKG 클러스터에 영구 스토리지를 제공하는 방법, 고객이 클릭 한 번으로 Supervisor 클러스터에 하버 이미지 레지스트리를 배치할 수 있는 방법에 대해 설명하였다.

또한 vSphere with Kubernetes가 PodVMs 및 Supervisor Cluster를 통해 vSphere with Kubernetes를 개발자에게 제공했다고 설명했지만, 개발자들이 좀 더 네이티브하고 업스트림 Kubernetes 경험을 원하거나 필요로 하는 경우 간단한 매니페스트 파일을 통해 업스트림, 컨포머넌트, VMware Engineered 및 지원하는 탄주 쿠버네티스 클러스터를 지원한다.

위의 슬라이드를 수정하여 vSphere 7.0U1 출시 당시 비슷한 내용을 보고 다음 슬라이드를 생성했다. 이 슬라이드에서는 새로운 vSphere with Tanzu의 몇 가지 차이점을 강조한다.

보시다시피 꽤 많은 차이가 있다. 나는 다음 표에서 주목했다.

주요 이점으로는 vSphere with Tanzu를 구축하기 위해 VCF가 더 이상 필요하지 않으며, 쿠베르네츠에 로드 밸런싱을 제공하기 위해 NSX-T가 필요하지 않다는 점이다. VCF와 NSX-T는 모두 vSphere with Kubernetes에서 사용할 수 있도록 여전히 지원된다는 점에 유의한다. 새로운 점은 이제 HA-Proxy를 사용하여 로드 밸런서(Supervisor 제어부 API 서버 및 TKG 클러스터 API 서버에 필요함)를 제공한다는 것이다. 그러나 NSX-T가 없으면 이 릴리스에서 PodVM 구성을 사용할 수 없다. Harbor는 PodVM을 활용했기 때문에, 더 이상 내장된 레지스트리 서비스를 배치할 능력이 없다. 또 다른 주요 차이점은 TKG 클러스터의 Calico에서 Antrea 컨테이너 네트워크 인터페이스(CNI)로의 전환이다.

NSX-T(v3.x)를 사용할 수 있는 경우 해당 네트워크 스택을 vSphere with Tanzu와 계속 사용할 수 있으며, 이 경우에도 여전히 PodVM 구성을 사용할 수 있다는 점에 유의한다.

HA-Proxy 및 vSphere with Tanzu에 대한 요구 사항

이 섹션에는 HA-Proxy 및 vSphere with Tanzu를 배포하는 데 필요한 전체 사전 요구 사항 세트가 나열되어 있다. HA-Proxy를 배포할 때는 두 가지 옵션이 있다는 점에 유의한다. 즉, NIC 2개 또는 NIC 3개로 배포할 수 있다. 2개의 NIC 구성에는 관리 네트워크와 워크로드 네트워크가 있다. 관리 네트워크는 TKG 노드 IP 주소와 통신하고 로드 밸런서 IP 주소를 제공하기 위해 워크로드 네트워크가 사용되는 동안 슈퍼바이저 콘트롤 플레인과 통신한다. 3개의 NIC 구성에서 프런트엔드 네트워크라고 하는 세 번째 네트워크가 구성된다. 이렇게 하면 로드 밸런서 IP 주소 범위가 워크로드 네트워크에서 FrontEnd 네트워크로 이동된다. 다음 게시물에서는 HA-Proxy를 배포할 때 이 요구 사항에 대해 자세히 설명하겠지만, 요구 사항 관점에서 로드 밸런서 IP 주소에 다른 프런트엔드 네트워크가 사용되고 있다고 가정한다.

TKG 제어부 노드(워크로드 네트워크에서 프로비저닝됨)는 로드 밸런서 IP 주소(프론트 엔드 네트워크에서 프로비저닝됨)와 통신할 수 있어야 한다는 점에 유의하십시오. 다른 서브넷/VLAN을 사용할 수 있지만 서브넷 간에 경로가 있는지 확인하십시오.

HA & DRS

vSphere with Tanzu가 사용할 클러스터에서 DRS 및 HA가 모두 사용하도록 설정되어 있는지 확인한다.

스토리지 정책

Supervisor Cluster VM에 대해 원하는 스토리지 정책을 생성했는지 확인한다. vSAN을 사용하고 있으므로 기본 vSAN 스토리지 정책을 사용한다. 적절한 정책을 만들 수 있다.

컨텐츠 라이브러리

• HA-Proxy OVA용 컨텐츠 라이브러리를 생성한다. HA-Proxy OVA를 이 컨텐츠 라이브러리에 추가하고 이 라이브러리에서 배포해야 한다.
• TKG 이미지에 대한 컨텐츠 라이브러리를 생성한다. 이 컨텐츠 라이브러리는 TKG 클러스터 가상 시스템을 배포하는 데 사용할 가상 시스템 이미지를 저장하는 데 사용된다. 이러한 이미지에 TKG 구독 URL을 사용한다.

네트워크 요구 사항

• Management Network에서 HA-Proxy에 대한 FQDN 및 정적 IP 주소 식별
• Worker Network에서 HA-Proxy의 정적 IP 주소 식별
• (선택사항) HA-Proxy – Frontend Network의 정적 IP 주소 식별
• Management Network에서 Supervisor VM의 IP 주소 범위 식별
• Workload Network의 IP 주소 범위를 식별. 이러한 노드는 TKG “guest” 클러스터에 대해 프로비저닝된 노드와 감독자 제어부 노드 모두에서 사용된다.
• Load Balancer의 IP 주소 범위 식별 – Worker Network 또는 Frontend 네트워크(선택 사항)에서 사용할 수 있다
• 클러스터의 모든 호스트에 대해 구성된 VDS(vSphere Distributed Switch)