3장. 제한 및 확장성
이 문서에서는 ROSA(Red Hat OpenShift Service on AWS) 클러스터의 테스트된 클러스터 최대값과 최대값 테스트에 사용되는 테스트 환경 및 구성에 대한 정보를 자세히 설명합니다. 컨트롤 플레인 및 인프라 노드 크기 조정 및 스케일링에 대한 정보도 제공됩니다.
3.1. ROSA 테스트된 클러스터 최대값
ROSA(Red Hat OpenShift Service on AWS) 클러스터 설치를 계획하는 경우 다음과 같은 테스트된 오브젝트 최대값을 고려하십시오. 테이블은 (ROSA) 클러스터에서 테스트된 각 유형에 대한 최대 제한을 지정합니다.
이러한 지침은 다중 가용성 영역 구성의 102 컴퓨팅 노드 (작업자라고도 함)의 클러스터를 기반으로 합니다. 크기가 작은 클러스터의 경우 최대값이 더 낮습니다.
모든 테스트에 사용되는 OpenShift Container Platform 버전은 OCP 4.8.0입니다.
| 최대값 유형 | 4.8 테스트된 최대값 |
|---|---|
| 노드 수 | 102 |
| Pod 수 [1] | 20,400 |
| 노드당 Pod 수 | 250 |
| 코어당 Pod 수 | 기본값이 없습니다. |
| 네임스페이스 수 [2] | 3,400 |
| 네임스페이스당 Pod 수 [3] | 20,400 |
| 서비스 수 [4] | 10,000 |
| 네임스페이스당 서비스 수 | 10,000 |
| 서비스당 백엔드 수 | 10,000 |
| 네임스페이스당 배포 수 [3] | 1,000 |
- 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
- 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 사용할 수 있도록 조각 모음을 포함하여 etcd를 정기적으로 유지보수하는 것이 좋습니다.
- 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트에서 반복해야 하는 컨트롤 루프가 많습니다. 단일 네임스페이스에 형식의 오브젝트가 많으면 루프 비용이 많이 들고 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
- 각 서비스 포트와 각 서비스 백엔드는 iptables에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
OpenShift Container Platform 4.8에서는 CPU 코어의 절반(500밀리코어)이 이전 버전의 OpenShift Container Platform과 비교하여 시스템에 의해 예약되어 있습니다.
