[번역] vSphere with Kubernetes on VCF 4.0 Consolidated Architecture

출처 : https://cormachogan.com/2020/05/26/vsphere-with-kubernetes-on-vcf-4-0-consolidated-architecture/

Cloud-Foundation-Icon-2020-264x190.png

한 달 전에 VMware Cloud Foundation(VCF) 4.0이 출시된 이후 한 가지 질문을 반복적으로 받았는데, 언제 VCF 4.0 통합 아키텍처에서 vSphere with Kubernetes(이전의 Project Pacific)를 실행할 수 있는가? 다시 말해, vSphere를 실행할 별도의 VI Workload Domain을 구축하지 않고 관리 도메인에 vSphere with Kubernetes를 언제 구축할 수 있는지 알아보는 것이다. 이 요청의 주된 이유는 vSphere with Kubernetes를 실행하는 데 필요한 ESXi 호스트 수가 7개에서 4개로 줄어들기 때문이다. 이제 통합 아키텍처(Consolidated Architecture)라고 부르는 VCF 4.0의 관리 도메인에서 vSphere를 Kubernetes와 함께 실행할 수 있도록 전폭적인 지원을 받게 됨을 알려드리게 되어 기쁘게 생각한다.

Cloud-Native-Apps-Icon-2020.png

"방법"에 들어가기 전에, 통합이라는 용어에 관해서 서로 다른 정의를 지적하고 싶다. 통합이라는 용어는 관리 도메인에서 VM 워크로드를 실행하는 데 사용되지만, 통합 아키텍처라는 용어는 관리 도메인에서 워크로드를 실행하는 데에도 사용된다. 다시 말해 관리 도메인에서 관리 VM과 함께 VM을 항상 실행할 수 있다는 점을 강조하고자 한다. 이 게시물은 후자와 vSphere with Kubernetes 워크로드가 있는 관리 도메인을 선택할 수 있는 기능에 대해 언급한 것이다. 자세한 내용은 VCF 4.0의 관리 도메인에서 vSphere with Kubernetes를 배포하는 방법에 대한 단계를 참조하기 바란다.

Cloud Builder를 통해 정상적으로 VCF 4.0 배포

초기 배치는 이전에 여기에 게시된 것과 정확히 동일하다. 이전과 같이, 가져오는 동안 AVN(Application Virtual Networks)을 배포하는 옵션을 포함하지 않는다. NSX-T Edge는 나중에 별도의 단계로 생성된다.

1-cloud-builder-deploy.png

배포가 완료되면 SDDC 관리자를 시작한다. 로그인하면 4개의 ESXi 호스트로 구성된 단일 워크로드 도메인인 관리 도메인(Management Domain)이 표시되며, 또한 vCenter 7.0을 실행하고 vSAN 7.0이 자동으로 배포된다. 관리 도메인에는 vSAN이 필요하다.

6-sddc-mgr.png

VCF 4.0에서는 NSX-T 3.0도 자동으로 배포된다. NSX-T Manager에 로그인하면 ESXi 호스트의 전송 노드 및 영역을 볼 수 있다. 그러나 가져오는 동안 AVN(Application Virtual Network)을 건너뛰었기 때문에 NSX-T Edge 노드를 아직 배포하지 않았다. 따라서, Tier0 또는 Tier1 논리적 라우터 또는 정의된 다른 네트워크 서비스는 없다.

7-nsx-t-mgr.png

관리 도메인에 NSX-T Edge 추가

vSphere with Kubernetes에서는 NSX-T가 네트워킹 서비스를 제공해야 한다. NSX-T는 Tier0 및 Tier1 논리적 라우터를 제공한다. NSX-T는 또한 SNAT 송신 및 로드 밸런서 수신 기능을 Supervisor Cluster 및 Guest Cluster에 제공한다. vSphere with Kubernetes에서 생성된 각 네임스페이스는 자체 Tier-1 논리적 라우터뿐만 아니라 필요한 SNAT 및 로드 밸런서 IP 주소를 얻는다. 이 기능은 NSX-T Edge에 의해 제공되며, VCF 4.0에서는 관리 도메인을 포함한 워크로드 도메인에 NSX-T Edge의 프로비저닝이 완전히 자동화된다.

NSX-T Edge를 배포하려면 SDDC Manager에서 관리 도메인을 마우스 오른쪽 버튼으로 클릭한다. 드롭다운 목록에서 Edge 클러스터 추가를 선택한다. Edge 클러스터의 마법사를 채우는 방법에 대한 자세한 내용은 이 게시물을 참조한다.

10-Add-Edge-Cluster.png

NSX-T Edge 사용 사례는 "Workload Management"에 대한 항목으로, 기본적으로 이 NSX-T Edge가 vSphere with Kubernetes에 사용됨을 의미한다. 이렇게 하면 Edge 크기가 자동으로 Large로 설정되고 Tier0 Service HA가 Active-Active로 설정된다. 이 단계에서는 또한 WCPReady 태그를 NSX-T Manager의 Edge Cluster에 추가한다. 이 태그는 나중에 논의 한다.

한 가지 더 언급할 것은 내 연구실에서는 업스트림 라우터에 접근할 수 없다는 것이다. 이것은 BGP를 통해 Tier0 논리적 라우터에 피어링할 수 없다는 것을 의미한다. 따라서 내 Tier0 라우팅 유형으로 Static을 선택하고 있다. 이것은 나중에 라우팅에 관한 한 많은 추가적인 수동 단계를 의미한다. 또 다른 옵션은 EBGP이다. EBGP는 Tier0 논리적 라우터를 물리적 업스트림 라우터에 피어링해야 하며, 자동 라우트 학습을 가능하게 한다. EBGP는 프로덕션 환경에서 훨씬 더 일반적인 설정이 될 수 있지만 불행히도 내 연구실에서는 가능하지 않다. 여기서 워크로드 관리는 Edge 클러스터 추가 마법사에서 지정된다.

12-wld-mgmt-use-case.png

두 NSX-T Edge 노드에 대한 세부 정보가 추가된 후 마법사를 완료하고 유효성 검사가 통과했는지 확인하고 NSX-T Edge 클러스터를 배포한다. 이제 NSX-T Manager로 돌아가 관리 도메인에 쿠버넷이 포함된 vSphere를 배포할 수 있도록 해야 하지만, 먼저 추가 단계를 따르지 않고 관리 도메인에 vSphere with Kubernetes를 배포하려고 하면 어떻게 되는지 살펴보자.

클러스터가 Workload Management와 호환되지 않음

VCF 4.0 통합 아키텍처에서 SDDC 매니저는 워크로드 관리를 사용하도록 설정할 때(vSphere with Kubernetes 배포) 유효성 검사를 위해 vSphere 클러스터를 선택하는 것을 허용하지 않는다. 쿠베르네테스 배포를 vSphere로 진행하려면 vSphere 클라이언트를 사용해야 한다. 그러나 vSphere Client에서 이제 워크로드 관리를 사용하도록 설정하면 관리 도메인의 vSphere 클러스터가 호환되는 것으로 표시되지 않는다.

13-v7k8s-not-compat.png

Workload Domain vCenter Server의 NSX-T Manager에 '신뢰(trust)'가 설정되지 않았기 때문이다. 이제 그렇게 하자.

NSX-T Manager에서 신뢰 설정 및 태그 추가

NSX-T Manager에서 시스템 보기로 이동한다. Configuration > Fabric에서 Compute Manager를 선택한다. Management Domain vCenter Server 목록이 나타난다. Edit 링크를 클릭하여 vCenter Server / Compute Manager 속성을 연다. Enable Trust을 Yes로 설정하고 Save를 누른다.

15-v7k8s-nsx-enable-trust.png

이제, 추가적인 단계가 필요할지도 모른다. 이는 불러오기 작업 중에 AVN(Application Virtual Network)을 배포했는지, 아니면 SDDC Manager를 사용하여 여기서와 같이 Edge Cluster를 생성했는지에 따라 달라진다. 불러오는 동안 AVN을 배치했다면 이 단계가 필요할 것이다. 또한 NSX-T Edge Cluster를 배포할 때 사용 사례로 "Workload Management"를 선택하지 않은 경우에도 이 단계를 수행한다.

NSX-T Manager에서 System 보기로 다시 한 번 이동하십시오. Configuration > Fabric에서 Nodes를 선택한다. 그런 다음 Edge Cluster를 선택하고, Edge Cluster 이름을 클릭한다. 이제 태그를 확인한다. 아래 그림과 같이 VCF와 WCPReady의 두 가지가 있어야 한다. WCPReady가 없는 경우, Manage > Add 단계를 사용하여 추가해야 한다.

SDDC 관리자를 통해 Edge Cluster를 배포하고 사용 사례로 "Workload Management"를 선택하는 경우에는 이 단계를 수행하지 않는다.

WCPReady-Tag.png

이제 워크로드 관리를 사용하도록 설정할 때 관리 도메인의 vSphere 클러스터가 vSphere UI에서 호환되는 것으로 표시되어야 한다.

16-v7k8s-compat.png

이제 나머지 워크로드 관리 배포를 진행하여 vSphere with Kubernetes를 롤아웃한다. 이것을 하는 방법에 대한 전체 단계는 이 이전 게시물에서 찾을 수 있다. 모든 것이 성공적으로 배포되면, 쿠베르네츠 API 서버는 수신 범위에서 로드 밸런서 IP 주소를 수신하고 다음과 같은 형태로 나타나야 한다.

21-completed.png

또한 정적 경로를 Tier0 라우팅 유형으로 선택했다면 이제 제어부 LB를 연결하고 vSphere with Kubernetes에 필요한 Kubectel 도구를 다운로드할 수 있을 것이다.

22-K8s-Tools.png

NSX-T와 관리 도메인 vCenter Server 간의 신뢰 관계를 설정하는 단계는 향후 릴리스에서 자동화된다는 점에 유의하십시오.

추가 주의사항

NSX-T Edge를 배포할 때 정적 경로 접근 방식을 Tier0 Routing Type으로 사용했다면 이제 정적 경로를 Tier0에 추가한다. 이는 제어면이 외부 저장소에서 컨테이너 이미지를 풀(pull) 수 있도록 하기 위함이다. 변경할 물리적 네트워킹 인프라에 액세스할 수 없는 경우 Tier0에 대한 SNAT 규칙도 추가한다. EBGP를 통해 자동화할 수 있는 업스트림 라우터에 액세스하지 못하는 것은 짜증나는 일이지만, 적어도 해결책이 있다. 나는 이 포스트에 나의 정적 경로와 SNAT 설정을 자세히 적어두었다.

NSX-T Edge를 배포할 때 EBGP를 Tier0 Routing Type으로 사용하기로 결정한 경우 또 다른 주의 사항이 있다. 이 문제는 제어부 API 서버 로드 밸런서 IP 주소에 연결하여 도구를 다운로드할 수 없는 것으로 나타난다. BGP Route Advertisements가 무심코 차단됐기 때문이다. 이 문제를 해결하려면 Tier0 Route Advertisement 구성을 수정하고 새 사용자 지정 경로 맵을 생성하십시오. NSX-T의 Tier0 라우팅 섹션에서 다음 3단계를 추가한다.

  • 네트워크를 허용하는 새 IP Prefix List를 만든다.
  • 1단계에서 생성된 새 IP Prefix와 일치하고 모든 네트워크를 허용하는 새 Custom Route Map을 만든다.
  • 2단계에서 작성된 새 Custom Route Map을 사용하려면 default Route Map으로 편집한다.

이것은 이제 모든 경로가 광고될 것이라는 것을 의미한다. 이 문제는 곧 발표될 발표에서도 다룰 것이다. 또한 EBGP Routing Type으로 구체적이다. 정적 경로를 Routing Type으로 선택한 경우에는 관련이 없다.

맺음말

이제 vSphere with Kubernetes / Workload Management를 VCF 4.0의 4 노드 관리 도메인에 성공적으로 배포했다. 이제 별도의 VI Workload Domain에 배포된 Workload Management를 사용하는 것처럼 이 환경을 계속 사용하한다. 이 환경을 사용하여 네임스페이스를 생성하고, Supervisor 클러스터에 PodVM을 배포하며, 게스트 TKG(Tanzu Kubernetes Grid) 클러스터를 생성할 수 있다.

23-namespaces.png

vSphere with Kubernetes를 사용하여 TKG 클러스터를 배포하는 방법에 대한 자세한 내용을 보려면 이 링크를 클릭하십시오.

VCF 4.0 통합 아키텍처에 대한 자세한 내용과 VCF 4.0 통합 아키텍처에서 vSphere with Kubernetes를 배포하는 방법에 대한 자세한 백서를 어디서 얻을 수 있는지, 내 동료 Kyle Gleed의 블로그 게시물을 확인한다. Kyle이 글에서 언급했듯이, Cloud Foundation 4.0 Consolidated Architecture의 추가 자격 증명으로 vSphere with Kubernetes를 쉽게 시작할 수 있기를 바란다.