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 속도 정의에 대한 호스팅된 제어 평면 리소스 확장을 보여줍니다.
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입니다.
제한 설명 | 서버 1 | 서버 2 |
---|---|---|
워커 노드의 vCPU 수 | 64 | 128 |
워커 노드의 메모리(GiB) | 128 | 256 |
작업자당 최대 포드 수 | 500 | 500 |
제어 평면을 호스팅하는 데 사용되는 작업자 수 | 3 | 3 |
최대 QPS 목표 속도(초당 API 요청 수) | 1000 | 1000 |
워커 노드 크기 및 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개 |
이전에 언급된 최대값의 최소값 | 5.4 | 6.7 | |
vCPU 제한 요소 |
| ||
관리 클러스터 내 호스팅 제어 평면의 최대 수 | 16 | 20 | 이전에 언급된 최대값의 최소값 × 3개의 제어 평면 작업자 |
이름 | 설명 |
| 고가용성 호스팅 제어 평면 리소스 요청을 기반으로 클러스터가 호스팅할 수 있는 호스팅 제어 평면의 최대 예상 수입니다. |
| 모든 호스팅 제어 평면이 클러스터 Kube API 서버에 약 50 QPS를 보내는 경우 클러스터가 호스팅할 수 있는 호스팅 제어 평면의 최대 추정 수입니다. |
| 모든 호스팅 제어 평면이 클러스터 Kube API 서버에 약 1000 QPS를 보내는 경우 클러스터가 호스팅할 수 있는 호스팅 제어 평면의 최대 추정 수입니다. |
| 모든 호스팅 제어 평면이 클러스터 Kube API 서버에 약 2000 QPS를 보내는 경우 클러스터가 호스팅할 수 있는 호스팅 제어 평면의 최대 추정 수는 얼마입니까? |
| 클러스터가 호스팅할 수 있는 호스팅 제어 평면의 최대 개수는 호스팅 제어 평면의 기존 평균 QPS를 기준으로 추정됩니다. 활성화된 호스팅 제어 평면이 없으면 QPS가 낮아질 수 있습니다. |