[번역] vSphere Supervisor Namespace

출처 : https://frankdenneman.nl/2020/04/01/vsphere-supervisor-namespace/

vSphere 7 with Kubernetes를 사용하면 vSphere 클러스터가 컨테이너를 기본 구성 요소(vSphere Pods)로 실행하고 관리할 수 있다. 이 시리즈의 이전 두 기사는 vSphere 파드의 초기 배치와 개별 vSphere 파드의 계산 리소스 관리를 다룬다. 이 글은 vSphere Supervisor 네임스페이스 구성의 계산 리소스 관리 측면을 다룬다. 코맥 호건은 그의 (우수한) 블로그 시리즈에서 슈퍼바이저자 네임스페이스의 스토리지 측면을 살펴볼 것이다.

슈퍼바이저 클러스터(Supervisor Cluster)

쿠버네티스가 활성화되면 vSphere 클러스터가 Supervisor 클러스터로 전환된다. 세 개의 제어부 노드가 스핀업되어 vSphere 클러스터에 배치되며, 클러스터 내의 ESXi 노드는 Kubernetes 클러스터의 워커 노드(리소스 공급자) 역할을 한다. 각 ESXi 노드에서 vSpherelet이 실행되어 vSphere 파드를 제어하고 통신한다. ESXi의 컨테이너 런타임에 대한 자세한 내용은 "Initial Placement of a vSphere pod" 글을 참조하기 바란다.

슈퍼바이저 네임스페이스(Supervisor Namespace)

일단 가동되고 실행되면 Supervisor 클러스터는 연속적인 컴퓨팅 리소스 범위다. 클러스터를 더 작은 리소스 풀로 분할하려는 경우 네임스페이스를 사용하면 슈퍼바이저 클러스터가 멀티 테넌시(Multi-tenancy) 플랫폼으로 전환된다. 적절한 멀티 테넌시(Multi-tenancy)에는 보안 모델이 필요하며, 네임스페이스는 vAdmin을 통해 해당 네임스페이스에 액세스할 수 있는 사용자(개발자)를 제어할 수 있다. 네임스페이스에 연결된 스토리지 정책은 워크로드에 대해 (영구적인) 스토리지에 대해 서로 다른 유형과 클래스를 제공한다.

vSphere 파드만이 슈퍼바이저 네임스페이스에 의해 노출된 리소스를 사용할 수 있는 것은 아니다. vSphere 파드와 가상 시스템은 모두 네임스페이스 내부에 배치할 수 있다. 일반적으로 네임스페이스 내부에 배치된 가상 머신은 TKG(Tanzu Kubernetes Grid Cluster)를 실행할 수 있다. 그러나 다른 가상 머신을 네임스페이스에 배포할 수도 있다.

네임스페이스를 사용하면 애플리케이션 환경을 보다 높은 수준으로 관리할 수 있다. 기존 설정을 실행하고 컨테이너에서 실행되는 이 애플리케이션에 새 서비스를 추가하는 가상 시스템으로 구성된 애플리케이션이 있는 경우 이러한 구성을 단일 네임스페이스로 그룹화할 수 있다. 적절한 스토리지 및 계산 리소스를 네임스페이스에 할당하고 애플리케이션 전체를 모니터링한다. 우리는 수백 또는 수천 개의 가상 머신을 개별적으로 관리하는 것에서 작은 네임스페이스 그룹을 관리하는 것으로 전환하고 싶다. (즉, 업레벨링 워크로드 관리).

Supervisor-Namespace.png

기본(Default) 네임스페이스

컴퓨트 리소스는 vSphere DRS 리소스 풀을 통해 네임스페이스에 제공되며, 이 리소스 풀은 직접 노출되지 않으며, vAdmin은 네임스페이스 UI를 통해 리소스 풀과 인터페이스한다. 아래 스크린샷에서는 vSphere with Kubernetes가 사용하도록 설정된 WLD(Workload Domain Cluster)를 볼 수 있다. 슈퍼바이저 클러스터 내부에는 상위 리소스 풀 "Namespace"가 자동으로 생성되며, Supervisor 클러스터의 세 개의 제어면 VM이 네임스페이스 리소스 풀에 직접 배포된다. (이 문제는 나중에 말하겠다.) 코맥과 나는 몇 개의 네임스페이스를 만들었고 네임스페이스 "frank-ns"이 강조되었다.

보다시피, 이 새로운 구조물은 새로운 아이콘으로 처리된다. 화면 오른쪽에 있는 요약 페이지에는 상태, 권한(아직 구성되지 않음), 연결된 구성된 스토리지 정책, 계산 리소스의 용량 및 사용량이 표시된다. 화면 아래 부분에는 포드 또는 TKG 클러스터를 구축했는지 여부가 표시된다. 이 예에서는 현재 3개의 포드가 실행되고 있다.

Supervisor-Namespace-Overview-1536x809.png

컴퓨트 리소스 관리

vAdmin은 기존 리소스 풀을 사용하여 CPU 및 메모리 예약, 공유 및 제한을 설정하여 계산 리소스의 소비를 보장하고 제한할 수 있다. 슈퍼바이저 네임스페이스는 동일한 설정을 노출시키지 않는다. 네임스페이스는 vAdmin이 컨테이너 단위로 제한 또는 요청(예약)과 제한을 설정할 수 있도록 한다.

Supervisor-Namespace-Resource-Limits.png

Limits

vAdmin은 전체 네임스페이스에 대한 CPU 또는 메모리 리소스에 대한 제한을 설정할 수 있다. 이렇게 하면 개발자는 네임스페이스에 워크로드를 배치할 수 있으며 슈퍼바이저 클러스터의 전체 컴퓨팅 용량을 소비할 위험을 감수할 수 없다. 또한 리소스 풀 제한을 초과하여 vAdmin은 컨테이너당 기본 제한을 설정할 수 있다. 네임스페이스는 컨테이너 워크로드의 YAML 파일에 지정된 리소스 구성에 관계없이 들어오는 각 워크로드에 자동으로 제한을 가한다. 여기에 vAdmin은 오브젝트 한계도 지정할 수 있다. 네임스페이스에 대해 최대 수의 파드를 지정할 수 있으며, 궁극적으로는 네임스페이스에 배치된 워크로드 구조에 의해 소비되는 총 자원을 제한할 수 있다.

Supervisor-Namespace-Objects-Limits.png

Reservations

슈퍼바이저 네임스페이스는 네임스페이스 수준에서 예약(reservation)을 설정하는 옵션을 제공하지 않는다. 그러나 리소스 풀은 확장 가능한 예약으로 구성되며 이를 통해 리소스 풀이 부모로부터 예약되지 않은 리소스를 요청할 수 있다. 이러한 예약되지 않은 리소스는 워크로드에 대한 예약 가능한 리소스 요청을 충족하기 위해 필요하다. 리소스 풀 "Namespaces"는 모든 네임스페이스가 배포된 상위 리소스 풀입니다. 리소스 풀 "Namespaces"가 예약된 리소스로 구성되어 있지 않으므로 클러스터 개체라고 더 잘 알려진 루트 리소스 풀인 상위 리소스로부터 예약되지 않은 리소스를 요청하게 된다.

Expandable-Reservation.png

작업 부하를 경합으로부터 보호하기 위해 자원의 예약이 필요하다. 이것은 두 가지 방법으로 할 수 있다. vAdmin은 컨테이너당 기본 예약을 설정할 수 있으며, 또는 YAML 파일의 리소스 구성에서 리소스 요청을 지정해야 한다. vAdmin이 컨테이너당 기본 예약을 설정하면 해당 네임스페이스에 배포된 모든 컨테이너가 해당 설정으로 구성된다. 개발자는 작업 부하 YAML 파일에서 각 컨테이너에 대한 요청 또는 제한을 개별적으로 지정할 수 있다. 사용된 요청과 한도의 조합을 바탕으로 쿠버네티스는 자동으로 포드 내부의 용기에 QoS 클래스를 할당한다. 그리고 Qos 클래스에 근거하여 매립이 일어난다. 쿠버네티스에는 BestEffort, Burstable, Guaranteed의 3가지 서비스 품질(QoS) 클래스(class)가 있다.

Kubernetes-QoS-Classes-Overview.png

버스트 가능 클래스와 보증 클래스는 모두 요청 구성으로 구성된다. Burstable QoS 클래스의 경우 한계는 요청에 의해 지정된 숫자를 초과한다. 보증된 QoS 클래스는 제한(limit)와 요청(request)이 동일한 값으로 설정되어야 한다. 즉, 네임스페이스의 상대적 우선 순위가 요청 설정에 의해 보호되지 않는 BestEffort 또는 Burstable 워크로드의 리소스 부분이 리소스 경합 중에 필요한 리소스를 얻을 것인지 여부를 결정한다는 것이다. 상대 우선 순위는 네임스페이스에 할당된 공유 수준에 의해 지정된다.

Shares

DRS는 리소스 경합이 있을 때 상대적 우선 순위를 결정하기 위해 클러스터 내의 개체에 공유(share)를 할당한다. 공유를 많이 소유할수록 원하는 자원을 얻는 우선 순위가 높아진다. 이것은 믿을 수 없을 정도로 역동적이고 우아한 방법으로 활동적인 오브젝트들의 요구에 부응한다. VM 또는 리소스 풀은 전 세계의 모든 공유를 가질 수 있지만, 해당 오브젝트가 활성 워크로드를 푸시하고 있지 않으면 이러한 공유는 직접 실행되지 않는다. 일반적으로 어떤 대상에 부여된 공유의 가치를 결정하기 위해 최악의 시나리오 계산을 사용한다. 이러한 연습에서는 각 오브젝트가 100% 활성인 경우, 공의의 가치를 계산한다. 즉, 완벽한 폭풍우.

DRS는 각 개체 공유를 할당한다. DRS는 개체의 구성된 리소스를 기반으로 공유를 부여한다. vCPU의 수와 메모리 양, 공유 수와 곱하기. 개체의 우선 순위 수준(낮음, 정상, 높음)이 공유 계수를 결정한다. 우선 순위는 1:2:4의 비율을 가진다. 정상 우선 순위는 기본 우선 순위로, 각 vCPU는 1000개의 CPU 공유를 부여받는다. 메모리 MB당 10의 공유가 할당된다. 예를 들어 vCPU 구성이 2개인 VM의 경우 정상 우선 순위 수준이 할당되면 2000개의 공유(2 vCPU x 1000)가 수신된다. VM이 높은 우선 순위 수준으로 구성된 경우 4000 공유(2 vCPU x 2000)을 받는다. 리소스 풀만으로는 워크로드를 실행할 수 없지만 DRS는 상대적 우선 순위를 결정하기 위해 이 구성에 공유를 할당해야 한다. 따라서 DRS에 대한 리소스 풀의 내부 정의는 4개의 vCPU, 16GB VM과 동일하다. 따라서 포함된 오브젝트 수에 관계없이 정상적인 우선 순위 리소스 풀에 4000개의 CPU와 163840개의 메모리 공유가 부여된다.

네임스페이스에는 일반 우선 순위 수준으로 구성된 리소스 풀이 장착되어 있다. 네임스페이스 내부에 배치된 모든 개체도 정상 우선순위를 받으며, 이는 변경할 수 없다. "Scheduling vSphere Pods" 글에서 설명한 바와 같이 컨테이너는 프로세스 집합이며 하드웨어별 크기 조정 구성이 포함되어 있지 않다. CPU 주기의 수와 보유하고자 하는 메모리 양과 리소스 사용의 상한만을 나열한다. vSphere는 요청과 제한을 vSphere 파드(CRX)에 대한 CPU 및 메모리 크기로 해석하고 DRS는 이 구성을 기반으로 공유를 할당할 수 있다. 더 많은 컨테이너가 파드 내부에 배치될 수 있기 때문에, 컨테이너의 제한과 요청의 조합은 vSphere 파드에 가상 하드웨어를 할당하는 데 사용된다.

BestEffort 워크로드에는 요청과 제한이 설정되어 있지 않으므로 기본 싸이징은 vCPU 1개와 512MB로 사용된다. 공유의 관점에서, 이것은 단일 컨테이너를 실행하는 vSphere 파드가 1,000의 CPU 공유와 5120의 메모리 공유를 받는다는 것을 의미한다. Burstable QoS 클래스는 요청 집합 또는 요청과 제한을 모두 가지고 있다. 두 설정 중 하나가 기본 크기보다 크면 해당 메트릭을 사용하여 컨테이너의 크기를 결정한다(아래 이미지 참조). 파드 매니페스트에 여러 개의 컨테이너가 포함된 경우 각 컨테이너의 가장 큰 매개 변수가 추가되고 그 결과는 vSphere 파드 크기로 사용된다. 예를 들어, 파드는 컨테이너의 기본 크기보다 큰 요청과 제한이 있는 두 개의 컨테이너를 포함한다. CPU 한도가 CPU 요청 수량을 초과한다. 그 결과 vSphere는 두 CPU 한도의 합계를 사용하며 파드 라이프사이클, 파드 구성 및 vSpherelet 상호작용을 담당하는 구성 요소에 약간의 패딩을 추가한다. 메모리에도 비슷한 계산이 나온다.

Resource-Allocation-Setting-Impact-vSphere-Pod-Size.png형제 경쟁 중 상대적 우선 순위

이러한 vSphere 파드 크기가 왜 그렇게 흥미로운가? vSphere 7의 DRS는 확장 가능한 공유(Scalable share)라는 새로운 기능을 갖추고 있으며 하위 개체의 CPU 및 메모리 구성을 사용하여 형제와 관련하여 리소스 풀의 상대적 우선 순위를 올바르게 변환한다. 리소스 풀은 내부에 배포된 개체의 상위 항목이다. 즉, 리소스 경합 중에 리소스 풀은 상위 리소스인 "Namespace" 리소스 풀에 리소스를 요청하고, 이 풀은 부모로부터 루트 리소스 풀(Supervisor Cluster)을 요청하게 된다. 각각의 레벨에서, 다른 물체들은 완벽한 폭풍우 동안 같은 일을 하고 있다. 그것은 우리가 형제간의 경쟁관계를 다루어야 한다는 것을 의미한다.

parent-child-domain.png

"Namespace" RP 안에는 몇 개의 오브젝트가 존재한다. 두 개의 네임스페이스와 세 개의 제어부 VM. 예약은 어떤 오브젝트도 보호하지 않으며, 따라서 각 개오브젝트는 126.14 GB 중 일부를 원할 경우 자신의 공유 가치로 그 오브젝트와 싸워나가야 한다. 각 제어부 VM은 24GB로 구성되며 245,760개의 공유를 소유한다. 두 RP 모두 163,840개의 CPU 공유를 소유하고 있다. UI에 나타난 바와 같이, "Namespace" RP 내에서 총 1,064,960개의 공유가 발행되고 있으며, 두 자원 풀은 총 공유의 23.08%를 소유하고 있는 반면, 두 자원 풀은 15.38%를 소유하고 있다. 최악의 경우, 이는 "Namespace" RP가 126.14 GB를 다섯 개의 오브젝트(시블링)로 나눈다는 것을 의미한다. 각 제어부 노드는 126.14GB = 29.11GB의 23.08%를 소비할 수 있다. 구성된 하드웨어보다 더 많이 할당할 수 없기 때문에 이 상황에서는 최대 24GB(및 VM 오버헤드)까지 소비할 수 있다. 나머지 5GB는 리소스 풀로 다시 이동하며 이를 필요로 하는 오브젝트 사이에 분산된다. 이 경우 세 개의 제어기 모두 72 GB(3 x 24 GB)를 소비하며 54.14 GB는 "frank-ns" 네임스페이스와 "vmware-system-reg..."(habor 등) 네임스페이스에 배포된다.

Namespaces-RP-Root-view-memory.png

각 네임스페이스 내의 오브젝트의 리소스 요구 사항은 형제(sibling) 간에 네임스페이스의 상대적 우선순위를 빠르게 초과할 수 있다. 그리고 더 많은 네임스페이스가 배치되어 형제간의 상대적 우선순위가 더욱 희석될 것으로 예상된다. 이 동작은 다음 스크린샷에서 강조된다. 그동안 Cormac은 새로운 작업 부하를 배치해 왔다. 그는 자신의 vSphere 파드를 위한 네임스페이스를 만들었다. 그는 TKG 클러스터와 Cassandra 클러스터를 배치했다. 모두 자신의 네임스페이스에 배치되어 있다.

보시다시피, 내 네임스페이스 "frank-ns"는 상대적인 우선순위 희석 현상을 경험하고 있다. 공유 비중은 15.38%에서 10.53%로 희석됐다. 리소스 경합이 발생할 경우 BestEffort 및 Burstable 배포에서 이전과 동일한 양의 리소스를 얻지 못할 것으로 예상할 수 있다. 제어부 노드에 대해서도 동일한 사항이 적용된다. 그들은 이제 전체 메모리 리소스 양의 15.79%를 받을 권리가 있다. 즉, 각 제어부 노드는 19.92GB(126.14GB의 15.79%)에 액세스할 수 있다.

Supervisor-Namespace-Relative-priority-dilution-1536x621.png

디자인 결정

제어부 노드에 예약을 적용하거나 리소스 풀을 생성하고 RP 수준에서 예약을 설정하는 것을 고려하겠다. VM 개체 수준에서 예약이 설정된 경우 승인 제어 및 HA 다시 시작 작업에 영향을 미친다(클러스터에서 하나 또는 여러 개의 호스트 장애 후 예약되지 않은 호스트 리소스가 충분한지 여부)

예약된 리소스

"Namespace" RP에서 사용할 수 있는 미예약 자원의 양은 네임스페이스 중 하나에 보장된 워크로드 또는 버스트 가능한 워크로드를 배치할 때 희석된다. 네임스페이스를 지원하는 RP는 "Expandable"로 구성되므로 부모에게 이러한 자원을 요청한다. 지배기업이 이러한 자원을 이용할 수 있는 경우, 자녀 자원에 이를 제공하고 즉시 예약된 것으로 표시한다. 네임스페이스는 네임스페이스가 존재하는 한 이러한 리소스를 소유할 것이다. 보장된 워크로드 또는 버스트 가능한 워크로드가 파괴되면 예약된 리소스가 상위 리소스로 다시 이동한다. 예약된 자원은 사용 중일 때 주식가치에 근거하여 다른 워크로드에 의해 할당될 수 없다.

여기서 주목해야 할 것은 이 상황에서 여러 개의 버스트 가능한 작업 부하가 네임스페이스 내부에 배치된다는 점이다. "Namespaces" RP의 사용 예약은 36.75GB의 자원이 예약되어 있음을 보여준다. 그러나 표를 볼 때 네임스페이스나 VM 중 어느 것도 예약을 확인하지 않고 있다. 그 열은 개체 자체에 직접 구성된 예약을 보여주기 때문이다. 그리고 네임스페이스를 지원하는 리소스 풀은 예약과 함께 직접 구성되지 않을 것이다. RP 내에서 실행 중인 vSphere 포드 또는 VM 예약을 합산하지 않는다는 점에 유의하십시오!

네임스페이스의 요약 보기는 네임스페이스의 용량과 사용량을 보여준다. 이 예에서 요약 페이지는 "Cormac-ns"로 표시된다. 그것은 네임스페이스가 3.3GHz와 4.46GB를 "사용"한다는 것을 보여준다.

Cormac-ns-summary.png

이 숫자들은 예약(요청)과 실제 사용의 조합이다. 이것은 각각의 개별 포드를 검사할 때 볼 수 있다. "cassandra-0" 파드의 요약 페이지에는 1개의 CPU가 할당되고 1GB가 할당되고, 파드는 약간의 메모리와 약간의 CPU 사이클을 소비한다는 것을 보여준다.

Cormac-ns-cassandra-node-summary.png

파드의 메타데이터는 이 파드가 QoS 등급의 보증 서비스를 가지고 있다는 것을 보여준다. YAML 파일을 볼 때 CPU와 메모리 리소스의 요청과 제한이 동일한 것을 알 수 있다. 흥미롭게도 CPU 리소스 설정은 500m를 보여준다. m은 millicpu를 의미한다. 1000millicpu는 1개의 vCPU와 같으므로 이 YAML 파일은 이 컨테이너가 코어의 반을 소비해도 괜찮다고 기술하고 있다. 그러나 vSphere에는 코어 절반의 가상 CPU에 대한 구성 규격이 없다. vSphere는 MHz당 스케줄링할 수 있지만 이 설정은 CRX(vSphere 포드) 구성을 정의하는 데 사용된다. 따라서 vSphere 파드는 최소 1개의 vCPU로 구성되며 이는 용량 및 사용 보기에 나열된다.

Cormac-ns-cassandra-node-YAML.png

확장 가능한 공유(Scalable Shares)

이 점이 흥미로운 이유는 확장 가능한 공유가 리소스 풀 내의 모든 개체의 총 메모리 구성에 대한 vCPU 수를 기반으로 새 공유 값을 계산할 수 있기 때문이다. 이 새로운 기능이 광범위한 리소스 풀 구조에서 어떻게 동작하는지가 다음 기사의 주제다.