3.2. 호스팅된 컨트롤 플레인의 크기 조정 지침


호스트 클러스터 워크로드 및 작업자 노드 수를 포함한 많은 요인은 특정 수의 작업자 노드 내에 적합한 호스팅 컨트롤 플레인 수에 영향을 미칩니다. 이 크기 조정 가이드를 사용하여 호스트된 클러스터 용량 계획에 도움이 됩니다. 이 가이드에서는 고가용성 호스팅 컨트롤 플레인 토폴로지를 가정합니다. 로드 기반 크기 조정 예제는 베어 메탈 클러스터에서 측정되었습니다. 클라우드 기반 인스턴스에는 메모리 크기와 같은 제한 요소가 다를 수 있습니다.

다음 리소스 사용률 크기 조정을 재정의하고 메트릭 서비스 모니터링을 비활성화할 수 있습니다.

OpenShift Container Platform 버전 4.12.9 이상에서 테스트된 다음 고가용성 호스팅 컨트롤 플레인 요구 사항을 참조하십시오.

  • 78 Pod
  • etcd의 경우 3GiB PV
  • 최소 vCPU: 약 5.5코어
  • 최소 메모리: 약 19GiB

3.2.1. Pod 제한

각 노드의 maxPods 설정은 컨트롤 플레인 노드에 들어갈 수 있는 호스트 클러스터 수에 영향을 미칩니다. 모든 control-plane 노드에서 maxPods 값을 기록하는 것이 중요합니다. 고가용성 호스팅 컨트롤 플레인마다 약 75개의 Pod를 계획합니다.

베어 메탈 노드의 경우 기본 maxPods 설정 250는 제한 요소가 될 수 있습니다. 이는 머신에 많은 리소스가 부족하더라도 Pod 요구 사항을 충족하는 각 노드에 대해 약 3개의 호스팅 컨트롤 플레인이 적합하기 때문입니다. KubeletConfig 값을 구성하여 maxPods 값을 500으로 설정하면 호스트된 컨트롤 플레인 밀도가 증가할 수 있으므로 추가 컴퓨팅 리소스를 활용할 수 있습니다.

3.2.2. 요청 기반 리소스 제한

클러스터에서 호스팅할 수 있는 최대 호스팅 컨트롤 플레인 수는 Pod의 호스팅된 컨트롤 플레인 CPU 및 메모리 요청을 기반으로 계산됩니다.

고가용성 호스트 컨트롤 플레인은 5개의 vCPU 및 18GiB 메모리를 요청하는 78 Pod로 구성됩니다. 이러한 기준 번호는 클러스터 작업자 노드 리소스 용량과 비교하여 호스팅되는 컨트롤 플레인의 최대 수를 추정합니다.

3.2.3. 로드 기반 제한

클러스터에서 호스팅할 수 있는 최대 호스팅 컨트롤 플레인 수는 일부 워크로드가 호스팅된 컨트롤 플레인 Kubernetes API 서버에 배치될 때 호스팅된 컨트롤 플레인 CPU 및 메모리 사용률을 기반으로 계산됩니다.

다음 방법은 워크로드가 증가할 때 호스팅된 컨트롤 플레인 리소스 사용률을 측정하는 데 사용됩니다.

  • KubeVirt 플랫폼을 사용하는 동안 각각 8 vCPU 및 32GiB를 사용하는 9개의 작업자가 있는 호스트 클러스터
  • 다음 정의에 따라 API 컨트롤 플레인 과부하에 중점을 두도록 구성된 워크로드 테스트 프로필입니다.

    • 각 네임스페이스에 대해 생성된 오브젝트로, 총 네임스페이스 100개까지 확장
    • 연속 오브젝트 삭제 및 생성에 대한 추가 API 과부하
    • 워크로드 쿼리-초당 (QPS) 및 Burst 설정은 클라이언트 측 제한을 제거하기 위해 높은 설정

로드가 1000개의 QPS로 증가하면 호스트된 컨트롤 플레인 리소스 사용률이 9개의 vCPU 및 2.5GB 메모리로 증가합니다.

일반적인 크기 조정을 위해 중간 호스트 클러스터 로드인 1000 QPS API 속도와 호스트 클러스터 로드가 많은 2000 QPS API를 고려하십시오.

참고

이 테스트에서는 예상되는 API 로드에 따라 컴퓨팅 리소스 사용률을 높이기 위한 추정 요소를 제공합니다. 정확한 사용률 비율은 클러스터 워크로드의 유형 및 속도에 따라 다를 수 있습니다.

다음 예제에서는 워크로드 및 API 속도 정의에 대한 호스팅된 컨트롤 플레인 리소스 스케일링을 보여줍니다.

Expand
표 3.11. API 속도 테이블
QPS(API 속도)vCPU 사용메모리 사용량(GiB)

낮은 부하 (50 QPS 미만)

2.9

11.1

중간 로드 (1000 QPS)

11.9

13.6

높은 부하 (2000 QPS)

20.9

16.1

호스트된 컨트롤 플레인 크기 조정은 API 활동, etcd 활동 또는 둘 다로 인해 발생하는 컨트롤 플레인 로드 및 워크로드에 관한 것입니다. 데이터베이스 실행과 같은 데이터 플레인 로드에 중점을 둔 호스팅된 Pod 워크로드는 API 비율이 높지 않을 수 있습니다.

3.2.4. 크기 조정 계산 예

이 예제에서는 다음 시나리오에 대한 크기 조정 지침을 제공합니다.

  • hypershift.openshift.io/control-plane 노드로 레이블이 지정된 베어 메탈 작업자 세 개
  • maxPods 값이 500으로 설정
  • 예상되는 API 속도는 로드 기반 제한에 따라 중간 또는 약 1000입니다.
Expand
표 3.12. 입력 제한
제한 설명서버 1서버 2

작업자 노드의 vCPU 수

64

128

작업자 노드의 메모리(GiB)

128

256

작업자당 최대 Pod 수

500

500

컨트롤 플레인을 호스팅하는 데 사용되는 작업자 수

3

3

최대 QPS 대상 속도(초당 API 요청)

1000

1000

Expand
표 3.13. 크기 조정 계산 예

작업자 노드 크기 및 API 속도를 기반으로 계산된 값

서버 1

서버 2

계산 노트

vCPU 요청을 기반으로 작업자당 최대 호스트 컨트롤 플레인

12.8

25.6

호스트된 컨트롤 플레인당 총 vCPU 요청 수 5개

vCPU 사용을 기반으로 작업자당 최대 호스트 컨트롤 플레인

5.4

10.7

vCPUS Cryostat (2.9 측정 유휴 vCPU 사용량 + (QPS 대상 비율 Cryostat 1000) × 9.0 QPS 증가당 vCPU 사용량 측정)

메모리 요청을 기반으로 작업자당 최대 호스트 컨트롤 플레인

7.1

14.2

작업자 메모리 GiB Cryostat 18GiB의 호스트된 컨트롤 플레인당 총 메모리 요청

메모리 사용량을 기반으로 작업자당 최대 호스트된 컨트롤 플레인

9.4

18.8

작업자 메모리 GiB Cryostat (1.1 측정 유휴 메모리 사용량 + (QPS 대상 비율 Cryostat 1000) × 2.5는 1000 QPS 증가당 메모리 사용량 측정)

노드 Pod 제한에 따라 작업자당 최대 호스트 컨트롤 플레인

6.7

6.7

호스팅된 컨트롤 플레인당 500 maxPods Cryostat 75개의 Pod

이전에 언급된 최소 최대값

5.4

6.7

 
 

vCPU 제한 요소

maxPods 제한 요소

 

관리 클러스터 내의 최대 호스트 컨트롤 플레인 수

16

20

이전에 언급된 최소 최대 × 3 개의 컨트롤 플레인 작업자

Expand
표 3.14. 호스트된 컨트롤 플레인 용량 메트릭

이름

설명

mce_hs_addon_request_based_hcp_capacity_gauge

클러스터가 고가용성 호스팅 컨트롤 플레인 리소스 요청을 기반으로 호스팅할 수 있는 최대 호스트 컨트롤 플레인 수입니다.

mce_hs_addon_low_qps_based_hcp_capacity_gauge

모든 호스팅 컨트롤 플레인이 클러스터 Kube API 서버에 약 50 QPS를 생성하는 경우 클러스터에서 호스팅할 수 있는 호스트 컨트롤 플레인의 최대 최대 수입니다.

mce_hs_addon_medium_qps_based_hcp_capacity_gauge

모든 호스팅된 컨트롤 플레인이 클러스터 Kube API 서버에 약 1000개의 QPS를 생성하는 경우 클러스터에서 호스팅할 수 있는 호스트 컨트롤 플레인의 최대 최대 수입니다.

mce_hs_addon_high_qps_based_hcp_capacity_gauge

모든 호스팅된 컨트롤 플레인이 약 2000 QPS를 클러스터 Kube API 서버로 만드는 경우 클러스터에서 호스팅할 수 있는 호스팅되는 컨트롤 플레인의 최대 수입니다.

mce_hs_addon_average_qps_based_hcp_capacity_gauge

클러스터에서 호스트된 컨트롤 플레인의 기존 평균 QPS를 기반으로 호스팅할 수 있는 최대 호스트 컨트롤 플레인 수입니다. 활성 호스트 컨트롤 플레인이 없는 경우 낮은 QPS를 기대할 수 있습니다.

3.2.5. 호스팅 및 독립 실행형 컨트롤 플레인 간의 공유 인프라

서비스 공급자는 독립 실행형 OpenShift Container Platform 컨트롤 플레인과 호스팅된 컨트롤 플레인 간에 인프라를 공유하여 리소스를 보다 효과적으로 사용할 수 있습니다. 3-노드 OpenShift Container Platform 클러스터는 호스팅된 클러스터의 관리 클러스터가 될 수 있습니다.

인프라 공유는 리소스 효율성이 필요한 소규모 배포와 같이 제한된 환경에 유용할 수 있습니다.

인프라를 공유하기 전에 인프라에 호스팅된 컨트롤 플레인을 지원할 수 있는 충분한 리소스가 있는지 확인합니다. OpenShift Container Platform 관리 클러스터에서는 호스팅된 컨트롤 플레인을 제외하고 다른 아무것도 배포할 수 없습니다. 관리 클러스터에 호스팅된 클러스터의 결합된 부하를 처리할 수 있는 충분한 CPU, 메모리, 스토리지 및 네트워크 리소스가 있는지 확인합니다. 워크로드는 필수가 아니어야 하며 초당 쿼리당 낮은 쿼리(QPS) 프로필에 속해야 합니다. 리소스 및 워크로드에 대한 자세한 내용은 "호스팅 컨트롤 플레인에 대한 지침"을 참조하십시오.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

Theme

© 2025 Red Hat