홈
제품
OpenShift Container Platform
4.12
확장 및 성능
3장. 오브젝트 최대값에 따른 환경 계획

3장. 오브젝트 최대값에 따른 환경 계획

OpenShift Container Platform 클러스터를 계획하는 경우 다음과 같은 테스트된 오브젝트 최대값을 고려하십시오.

이러한 지침은 가능한 가장 큰 클러스터를 기반으로 합니다. 크기가 작은 클러스터의 경우 최대값이 더 낮습니다. etcd 버전 또는 스토리지 데이터 형식을 비롯하여 명시된 임계값에 영향을 주는 요인은 여러 가지가 있습니다.

대부분의 경우 이러한 수치를 초과하면 전체 성능이 저하됩니다. 반드시 클러스터가 실패하는 것은 아닙니다.

주의

Pod 시작 및 중지 Pod와 같이 빠른 변경이 발생하는 클러스터는 문서화된 것보다 실제 가능한 최대 크기를 줄일 수 있습니다.

3.1. OpenShift Container Platform에 대해 테스트된 클러스터 최대값(주요 릴리스)

참고

Red Hat은 OpenShift Container Platform 클러스터 크기 조정에 대한 직접적인 지침을 제공하지 않습니다. 이는 클러스터가 지원되는 OpenShift Container Platform 범위 내에 있는지 여부를 확인하기 때문에 클러스터 스케일링을 제한하는 모든 다차원 요소를 신중하게 고려해야 하기 때문입니다.

OpenShift Container Platform은 절대 클러스터 최대값이 아닌 테스트된 클러스터 최대값을 지원합니다. OpenShift Container Platform 버전, 컨트롤 플레인 워크로드 및 네트워크 플러그인의 모든 조합이 테스트된 것은 아니므로 다음 표가 모든 배포에 대한 스케일링을 절대 예상하지는 않습니다. 모든 측면이 동시에 최대로 확장되지 않을 수 있습니다. 이 표에는 특정 워크로드 및 배포 구성에 대해 테스트된 최대값이 포함되어 있으며 유사한 배포에서 예상되는 항목에 대한 스케일링 가이드 역할을 합니다.

최대값 유형	4.x 테스트된 최대값
노드 수	2,000 ^[1]
Pod 수 ^[2]	150,000
노드당 Pod 수	500 ^[3]
코어당 Pod 수	기본값 없음
네임스페이스 수 ^[4]	10,000
빌드 수	10,000(기본 Pod RAM 512Mi) - S2I(Source-to-Image) 빌드 전략
네임스페이스당 Pod 수 ^[5]	25,000
Ingress 컨트롤러당 경로 및 백엔드 수	라우터당 2,000개
보안 수	80,000
구성 맵 수	90,000
서비스 수 ^[6]	10,000
네임스페이스당 서비스 수	5,000
서비스당 백엔드 수	5,000
네임스페이스당 배포 수 ^[5]	2,000
빌드 구성 수	12,000
CRD(사용자 정의 리소스 정의) 수	512 ^[7]

2000 노드 규모에서 OpenShift Container Platform의 컨트롤 플레인 구성 요소를 완화하기 위해 Pod 일시 중지가 배포되었습니다. 유사한 숫자로 확장하는 기능은 특정 배포 및 워크로드 매개변수에 따라 달라집니다.
여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
이 테스트는 작업자 노드가 100개이며 작업자 노드당 Pod가 500개인 클러스터에서 수행되었습니다. 기본 maxPods는 계속 250입니다. maxPods가 500이 되도록 하려면 사용자 정의 kubelet 구성을 사용하여 500으로 설정된 maxPods가 포함된 클러스터를 생성해야 합니다. 500개의 사용자 Pod가 필요한 경우 노드에서 이미 실행되고 있는 시스템 Pod가 10~15개가 있으므로 hostPrefix 22가 필요합니다. 연결된 PVC(영구 볼륨 클레임)가 있는 Pod의 최대 수는 PVC가 할당된 스토리지 백엔드에 따라 달라집니다. 이 테스트에서는 OCS v4(OpenShift Data Foundation v4)만 이 문서에서 설명하는 노드당 Pod 수를 충족할 수 있었습니다.
활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하기 위해 조각 모음을 포함한 etcd에 대한 유지보수를 정기적으로 수행하는 것이 좋습니다.
시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트에서 반복해야 하는 컨트롤 루프가 많습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
각 서비스 포트와 각 서비스 백엔드는 iptables에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
OpenShift Container Platform에는 OpenShift Container Platform에서 설치한 제품, OpenShift Container Platform 및 사용자가 생성한 CRD를 포함하여 512개의 CRD(사용자 정의 리소스 정의)가 제한됩니다. 512개 이상의 CRD가 생성된 경우 oc 명령 요청이 제한될 수 있습니다.

3.1.1. 시나리오 예

예를 들어 500개의 작업자 노드(m5.2xl)를 테스트하고 OpenShift Container Platform 4.12, OVN-Kubernetes 네트워크 플러그인 및 다음 워크로드 오브젝트를 사용하여 지원됩니다.

기본값 외에도 200 네임스페이스
노드당 Pod 60개, 서버 30개 및 클라이언트 Pod 30개(전체 30개)
57 이미지 스트림/ns (전체 11.4k)
서버 Pod에서 지원하는 서비스/시간 15개 (3k 합계)
이전 서비스에서 지원하는 15개의 경로/시간 (3k 합계)
20개의 보안/ns (4k 합계)
10개의 구성 맵/ns (2k 합계)
6개의 네트워크 정책/ns, 거부를 포함한 allow-from 수신 및 네임스페이스 내 규칙
57개의 빌드/시간

다음 요인은 클러스터 워크로드 스케일링에 영향을 미치는 것으로 알려져 있으며 배포를 계획할 때 스케일링 수에 반영되어야 합니다. 자세한 정보 및 지침은 영업 담당자 또는 Red Hat 지원에 문의하십시오.

노드당 Pod 수
Pod당 컨테이너 수
사용된 프로브 유형(예: liveness/readiness, exec/http)
네트워크 정책 수
프로젝트 수 또는 네임스페이스 수
프로젝트당 이미지 스트림 수
프로젝트당 빌드 수
서비스/엔드포인트 및 유형
경로 수
shard 수
보안 수
구성 맵 수
API 호출 속도 또는 클러스터 구성이 얼마나 빠르게 변경되는지 추정하는 클러스터 "churn"입니다.
- 5분 창에 Pod 생성 요청에 대한 Prometheus 쿼리: sum(irate(apiserver_request_count{resources",verb="POST"}[5m])
- 5분 창을 통해 초당 모든 API 요청에 대한 Prometheus 쿼리: sum(irate(apiserver_request_count{}[5m]))
CPU의 클러스터 노드 리소스 소비
메모리의 클러스터 노드 리소스 사용

맨 위로 이동

3장. 오브젝트 최대값에 따른 환경 계획

3.1. OpenShift Container Platform에 대해 테스트된 클러스터 최대값(주요 릴리스)

3.1.1. 시나리오 예

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links