VMware Enterprise PKS

[번역] Using Host Groups with Availability Zones (AZs) in Enterprise PKS

출처 : https://cormachogan.com/2019/12/20/using-host-groups-for-availability-zones-azs-in-enterprise-pks/

pks-logo.webp

이번주 초 vSphere Host Groups가 엔터프라이즈 PKS의 가용성 영역과 어떻게 작동했는가에 대한 질문을 받은 후, 이 기능을 이해하고 있는지 확인하기 위해 연구실에 vSphere Host Groups를 설치하고 약간의 테스트를 하기로 결정했다. 기본적으로 이 기능을 통해 vSphere Host Group 기능을 사용하여 여러 ESXi 호스트를 그룹화한다. 그런 다음 Enterprise PKS에서 Availability Zone(일반적으로 AZ라고 함)을 구축할 때 호스트 그룹은 AZ와 연결될 수 있다. 그러면 Enterprise PKS가 이 AZ에 배포하는 모든 것이 해당 호스트 그룹의 ESXi 호스트에 자동으로 배치된다.

테스트에서 먼저 단일 호스트 그룹을 생성했는데, 여기에는 여러 ESXi 호스트가 추가되어 있었다. 그리고 나서 내가 PKS에 AZ를 만들었을 때, 호스트 그룹과 AZ를 연관시켰다. 이는 Enterprise PKS 배포가 호스트 그룹에 정의된 동일한 ESXi 호스트 집합에 BOSH VM, PKS VM, Kubernetes 클러스터 마스터 및 worker 노드를 배치했음을 의미한다. 첫 번째 K8s 클러스터가 배포된 후(VM 그룹이 자동으로 생성됨) 호스트 그룹(및 후속 VM 그룹):

VC-Host-Group.png

VC-VM-Group.png

좋아 - 간단하군. 모든 PKS 오브젝트는 같은 Host Group에 배치되었다. 이제 Host Group을 사용하여 좀 더 복잡한 작업을 수행할 수 있는지 알아자.

두 번째 AZ를 만들고 BOSH Director와 PKS VM을 일종의 '관리' AZ에 배치한 다음 다른 '프로덕션' AZ에 Kubernetes 클러스터를 배치할 수 있는지 살펴보겠다. 이를 위해 Pivotal Ops Manager에서 AZ 구성을 수정할 수 있어야 한다. 이것은 기본적으로 가능하지 않다. 그러나 엔터프라이즈 PKS에는 기존 AZ 구성을 수정할 수 있는 '고급 모드'를 활성화하는 방법이 있다. 고급 모드를 활성화하기 위한 지침은 여기에서 찾을 수 있다. 설명서에 따라 주의하여 사용하기 바란다.

이제 고급 모드를 활성화한 후 Pivotal Ops Manager의 BOSH 타일로부터 두 번째 AZ를 생성하고, 두 AZ를 두 개의 다른 호스트 그룹을 참조하도록 할 수 있다. 호스트 그룹 PKS-AZ-1에는 3개의 ESXi 호스트가 포함되어 있으며 호스트 그룹 PKS-AZ-2에는 단일 ESXi 호스트가 포함되어 있다.

Second-AZ.png

다음 단계는 새로운 AZ가 네트워크에 접속할 수 있도록 하는 것이다. 단순히 새로운 AZ가 원래의 AZ가 이미 사용하던 기존 네트워크를 사용하도록 허락했다.

Second-AZ-access-network.png

BOSH 타일의 최종 구성 단계는 BOSH Director의 가용성 구역을 선택하는 것이다. 전술한 바와 같이 이 테스트는 단일 호스트를 포함하는 동일한 호스트 그룹에 BOSH Director 및 PKS VM을 배치하고 3개의 호스트를 가진 호스트 그룹에 K8 클러스터를 배치하는 것이다. 따라서 BOSH Director가 새로운 AZ를 사용하도록 Singleton Availability Zone을 수정했다.

BOSH-Director-AZ.png

그런 다음 vSphere용 BOSH Director의 모든 변경 내용을 저장한다. Enterprise PKS 타일로 관심을 돌립시다. Enterprise PKS 타일의 첫 번째 단계는 이전에 BOSH Director에서 했던 것처럼 PKS 작업의 AZ를 선택하는 것이다. CH-AZ-2를 다시 사용할 것이다.

PKS-singleton-jobs.png

마지막 단계는 쿠버네티스 클러스터에 사용하고자 하는 각 플랜(plan)에서 AZ fin을 선택하는 것이다. Enterprise PKS를 사용하면 마스터 노드와 작업자 노드 모두에 대해 서로 다른 AZ를 선택할 수 있다. 또한 여러 개의 AZ를 가용성 영역으로 균등하게 분산시키려면 포함시킬 수 있다. 이것을 꽤 단순하게 유지했고 플랜에 있는 마스터와 워커 모두에게 동일한 AZ를 선택했다. 마스터와 워커에 대한 AZ의 관점에서 본 내 플랜은 다음과 같다.

multi-az-master.png

multi-az-worker.png

이제 남은 것은 Pivotal Ops Manager의 변경사항을 적용하기만 하면 된다. 실제로 변경 사항을 적용하면 BOSH VM과 Enterprise PKS VM이 모두 새로운 AZ로 자동 이전되었다. 변경 사항이 완전히 적용되었을 때 VM 그룹 구성은 다음과 같이 보였다. 첫 번째 클러스터는 단일 마스터 노드와 4개의 워커 노드를 가진 K8s 클러스터다.

multi-AZHG1.png

BOSH Director 및 PKS를 포함하는 Availability Zone/VM Group:

multi-AZHG2.png

매우 좋다 - 이제 배치의 다른 부분을 다른 AZ에 배치할 수 있다. 구성을 완료한 후에는 고급 모드를 사용하지 않도록 설정한다.

Availability Zones/Host Groups/vSAN Fault Domains

Pivotal은 vSAN Fault Domain과 함께 Host Group의 사용에 관한 몇 가지 추가 문서를 여기에 제공했다. 간단히 말해, vSAN Fault Domain을 Host Group에 매핑할 수 있다. 즉, Kubernetes 클러스터에 대해 Rack Awareness와 같은 것을 달성하고 싶다면 각 랙의 각 호스트를 Fault Domain에 팝업할 수 있다. 이 호스트 그룹이 위와 같이 AZ와 연결되어 있고 모든 AZ에 K8s 마스터 및 K8s 노동자를 분산시키기로 결정하면 완전한 랙 장애를 허용할 수 있는 Kubernetes 클러스터를 갖게 된다. 이거 꽤 근사하다.

또한 이를 vSAN 확장 클러스터로 확장할 수 있으며, 각 사이트는 자체적으로 장애 영역(fault domain)이며, 최대 2개의 장애 도메인과 함께 작동하도록 제공한다. 설명서에 따라 요구 사항에 따라 한 사이트 또는 두 사이트 모두에 쿠버넷 노드를 배치할 수 있다. [Update] vSAN Stated Clusters와 함께 Host Group을 사용하는 것은 권장되지 않는다는 것을 알게 되었다. 나는 여기서 주요 이유가 K8s 콘트롤 플레인에 1 이상의 홀수(즉, 최소 3)개의 마스터가 있어야 하며 vSAN Stretched Cluster는 2개의 장애 도메인만 제공하므로 의심스럽다. 따라서 한 사이트에는 항상 두 명의 마스터가 있을 것이고, 만약 그 사이트가 실패한다면, 완전히 K8s 클러스터를 무너뜨릴 것이다. PKS v1.5 및 v1.6에 대해 문서화된 내용은 vSAN Stretched Cluster와 관련된 문구를 제거하도록 업데이트되었다. 그러나 집필 당시 PKS v1.4에는 계속 등장한다. 나는 PKS v1.4 문서에서도 그것을 제거해 달라는 요청이 들어왔다고 들었다.

Introducing Cloud Native Storage for vSphere

출처 : https://blogs.vmware.com/virtualblocks/2019/08/14/introducing-cloud-native-storage-for-vsphere/

 

클라우드 네이티브 스토리지가 필요한 이유

컨테이너 환경은 high-churn, 아주 역동적인 환경이다. 매시간 수십, 수백, 수천 개의 컨테이너를 만들고 삭제할 수 있다. 수동으로 회전할 때 스토리지를 관리하는 것은 엄청난 변화율 때문에 불가능하다. 컨테이너 워크로드에 대한 스토리지 프로비저닝을 자동화하는 답이 필요해진다.

Cloud Native Storage(CNS)는 vSphere 및 K8(Kuebernetes) 기능으로, K8이 vSphere에 스토리지를 완전히 자동화되고 확장 가능한 방식으로 프로비저닝하는 방법과 vCenter 내의 CNS UI를 통해 관리자가 컨테이너 볼륨에 대한 가시성을 제공할 수 있도록 하는 기능이다.

컨테이너와 VM을 동일 플랫폼, 방법으로 실행하고, 모니터링하고, 관리한다. 라이프사이클과 운영에 인프라스트럭쳐의 단순화가 필요하다. 워크로드와 클라우드 간에 일관된 운영을 위해 이미 알고 있는 플랫폼을 사용해서, 비용 절감과 인프라 관리에 소요되는 시간을 줄이고 비즈니스 가치를 제공하는 애플리케이션을 구축하는 데 더 많은 시간을 투자하십시오.