3.2. 호스팅된 제어 평면에 대한 크기 조정 지침


호스팅된 클러스터 작업 부하와 작업자 노드 수를 포함한 여러 요소가 특정 수의 작업자 노드에 얼마나 많은 호스팅된 제어 평면이 들어갈 수 있는지에 영향을 미칩니다. 이 크기 조정 가이드를 활용하여 호스팅 클러스터 용량 계획을 세우세요. 이 지침에서는 가용성이 높은 호스팅 제어 평면 토폴로지를 가정합니다. 부하 기반 크기 조정 사례는 베어 메탈 클러스터에서 측정되었습니다. 클라우드 기반 인스턴스에는 메모리 크기와 같은 다양한 제한 요소가 있을 수 있습니다.

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

OpenShift Container Platform 버전 4.12.9 이상에서 테스트된 다음의 고가용성 호스팅 제어 평면 요구 사항을 참조하세요.

  • 78개의 포드
  • etcd용 8GiB PV 3개
  • 최소 vCPU: 약 5.5개 코어
  • 최소 메모리: 약 19GiB

3.2.1. Pod 제한

각 노드의 maxPods 설정은 제어 평면 노드에 들어갈 수 있는 호스팅 클러스터 수에 영향을 미칩니다. 모든 제어 평면 노드에서 maxPods 값을 기록하는 것이 중요합니다. 가용성이 높은 호스팅 제어 평면마다 약 75개의 포드를 계획합니다.

베어 메탈 노드의 경우, 기본 maxPods 설정인 250은 각 노드에 대략 3개의 호스팅된 제어 평면이 적합하기 때문에 제한 요소가 될 가능성이 높습니다. 머신에 여유 리소스가 충분하더라도 마찬가지입니다. KubeletConfig 값을 구성하여 maxPods 값을 500으로 설정하면 호스팅된 제어 평면 밀도가 더 높아지고, 이를 통해 추가 컴퓨팅 리소스를 활용하는 데 도움이 됩니다.

3.2.2. 요청 기반 리소스 제한

클러스터가 호스팅할 수 있는 호스팅된 제어 평면의 최대 수는 포드의 호스팅된 제어 평면 CPU 및 메모리 요청을 기반으로 계산됩니다.

고가용성 호스팅 제어 평면은 5개의 vCPU와 18GB 메모리를 요청하는 78개의 포드로 구성됩니다. 이러한 기준 수치는 클러스터 워커 노드 리소스 용량과 비교되어 호스팅된 제어 평면의 최대 수를 추정합니다.

3.2.3. 부하 기반 한도

클러스터가 호스팅할 수 있는 호스팅된 제어 평면의 최대 수는 일부 작업 부하가 호스팅된 제어 평면 Kubernetes API 서버에 적용될 때 호스팅된 제어 평면 Pod의 CPU 및 메모리 사용률을 기반으로 계산됩니다.

다음 방법은 작업 부하가 증가함에 따라 호스팅된 제어 평면 리소스 사용률을 측정하는 데 사용됩니다.

  • KubeVirt 플랫폼을 사용하면서 각각 8개의 vCPU와 32GiB를 사용하는 9개의 작업자가 있는 호스팅 클러스터
  • 다음 정의를 기반으로 API 제어 평면 스트레스에 초점을 맞추도록 구성된 워크로드 테스트 프로필입니다.

    • 각 네임스페이스에 대해 객체를 생성하여 총 100개의 네임스페이스까지 확장 가능
    • 지속적인 객체 삭제 및 생성으로 인한 추가 API 스트레스
    • 클라이언트 측 제한을 제거하기 위해 초당 작업 쿼리 수(QPS) 및 버스트 설정을 높게 설정했습니다.

부하가 1000 QPS 증가하면 호스팅된 제어 평면 리소스 사용률은 vCPU 9개와 메모리 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 활동 또는 둘 다를 유발하는 제어 평면 부하와 작업 부하에 관한 것입니다. 데이터베이스 실행과 같은 데이터 플레인 부하에 초점을 맞춘 호스팅된 포드 워크로드는 높은 API 속도를 가져오지 못할 수 있습니다.

3.2.4. 크기 계산 예

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

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

워커 노드의 vCPU 수

64

128

워커 노드의 메모리(GiB)

128

256

작업자당 최대 포드 수

500

500

제어 평면을 호스팅하는 데 사용되는 작업자 수

3

3

최대 QPS 목표 속도(초당 API 요청 수)

1000

1000

Expand
표 3.13. 크기 계산 예

워커 노드 크기 및 API 비율을 기반으로 계산된 값

서버 1

서버 2

계산 노트

vCPU 요청에 따른 작업자당 최대 호스팅 제어 평면

12.8

25.6

작업자 vCPU 수 ÷ 호스팅된 제어 평면당 총 5개의 vCPU 요청

vCPU 사용량에 따른 작업자당 최대 호스팅 제어 평면

5.4

10.7

vCPUS 수 ÷ (2.9 측정된 유휴 vCPU 사용량 + (QPS 목표 비율 ÷ 1000) × 1000 QPS 증가당 9.0 측정된 vCPU 사용량)

메모리 요청에 따른 작업자당 최대 호스팅 제어 평면

7.1

14.2

작업자 메모리 GiB ÷ 호스팅된 제어 평면당 총 메모리 요청 18GiB

메모리 사용량에 따른 작업자당 최대 호스팅 제어 평면

9.4

18.8

작업자 메모리 GiB ÷ (11.1 측정된 유휴 메모리 사용량 + (QPS 대상 속도 ÷ 1000) × 2.5 측정된 메모리 사용량(1000 QPS 증가당))

노드당 Pod 제한에 따른 작업자당 최대 호스팅 제어 평면

6.7

6.7

최대 500개 포드 ÷ 호스팅된 제어 평면당 75개 포드

이전에 언급된 최대값의 최소값

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

모든 호스팅 제어 평면이 클러스터 Kube API 서버에 약 2000 QPS를 보내는 경우 클러스터가 호스팅할 수 있는 호스팅 제어 평면의 최대 추정 수는 얼마입니까?

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