7장. 오브젝트 최대값에 따른 환경 계획
OpenShift Container Platform 클러스터를 계획하는 경우 다음과 같은 테스트된 오브젝트 최대값을 고려하십시오.
이러한 지침은 가능한 가장 큰 클러스터를 기반으로 합니다. 크기가 작은 클러스터의 경우 최대값이 더 낮습니다. etcd 버전 또는 스토리지 데이터 형식을 비롯하여 명시된 임계값에 영향을 주는 요인은 여러 가지가 있습니다.
대부분의 경우 이러한 수치를 초과하면 전체 성능이 저하됩니다. 반드시 클러스터가 실패하는 것은 아닙니다.
시작 및 종료 포드가 많은 클러스터 등 급격한 변화가 발생하는 클러스터는 문서화된 것보다 실제 최대 크기가 낮을 수 있습니다.
7.1. OpenShift Container Platform에 대해 테스트된 클러스터 최대값(주요 릴리스) 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 OpenShift Container Platform 클러스터 크기 조정에 대한 직접적인 지침을 제공하지 않습니다. 클러스터가 OpenShift Container Platform의 지원 범위 내에 있는지 확인하려면 클러스터 규모를 제한하는 모든 다차원적 요소를 신중하게 고려해야 하기 때문입니다.
OpenShift Container Platform은 절대 클러스터 최대값이 아닌 테스트된 클러스터 최대값을 지원합니다. OpenShift Container Platform 버전, 제어 평면 워크로드, 네트워크 플러그인의 모든 조합이 테스트된 것은 아니므로, 다음 표는 모든 배포에 대한 절대적인 규모 기대치를 나타내는 것은 아닙니다. 모든 차원에서 동시에 최대치까지 확장하는 것은 불가능할 수도 있습니다. 이 표에는 특정 작업 부하와 배포 구성에 대한 테스트된 최대값이 포함되어 있으며, 유사한 배포에서 예상할 수 있는 사항에 대한 규모 가이드 역할을 합니다.
| 최대값 유형 | 4.x 테스트된 최대값 |
|---|---|
| 노드 수 | 2,000 [1] |
| 포드 수 [2] | 150,000 |
| 노드당 Pod 수 | 2,500 [3] |
| 네임스페이스 수 [4] | 10,000 |
| 빌드 수 | 10,000(기본 Pod RAM 512Mi) - S2I(Source-to-Image) 빌드 전략 |
| 네임스페이스당 포드 수 [5] | 25,000 |
| 기본 2라우터 배포당 경로 수 | 9,000 |
| 비밀의 개수 | 80,000 |
| 구성 맵의 수 | 90,000 |
| 서비스 수 [6] | 10,000 |
| 네임스페이스당 서비스 수 | 5,000 |
| 서비스당 백엔드 수 | 5,000 |
| 네임스페이스당 배포 수 [5] | 2,000 |
| 빌드 구성 수 | 12,000 |
| 사용자 정의 리소스 정의(CRD) 수 | 1,024 [7] |
- OpenShift Container Platform의 제어 평면 구성 요소에 2000개 노드 규모로 스트레스를 가하기 위해 일시 중지 포드가 배포되었습니다. 비슷한 숫자로 확장할 수 있는 능력은 구체적인 배포 및 작업 부하 매개변수에 따라 달라집니다.
- 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
-
이는 31개의 서버, 즉 3개의 제어 평면, 2개의 인프라 노드, 26개의 작업자 노드로 구성된 클러스터에서 테스트되었습니다. 2,500개의 사용자 포드가 필요한 경우 각 노드가 2,000개 이상의 포드를 포함할 수 있을 만큼 큰 네트워크를 할당하는
hostPrefix를20으로설정하고,maxPods를2500으로 설정한 사용자 지정 kubelet 구성을 사용해야 합니다. 자세한 내용은 OCP 4.13에서 노드당 2500개의 포드 실행을 참조하세요. - 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 저장소를 확보하려면 조각 모음을 포함한 etcd의 정기적 유지 관리를 적극 권장합니다.
- 시스템에는 상태의 변경에 대한 반응으로 주어진 네임스페이스의 모든 객체를 반복해야 하는 여러 개의 제어 루프가 있습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
-
각 서비스 포트와 각 서비스 백엔드는
iptables에 해당 항목을 가지고 있습니다. 주어진 서비스의 백엔드 수는Endpoints개체의 크기에 영향을 미치고, 이는 시스템 전체로 전송되는 데이터 크기에 영향을 미칩니다. -
29개 서버로 구성된 클러스터에서 테스트했습니다. 제어 평면 3개, 인프라 노드 2개, 워커 노드 24개입니다. 클러스터에는 500개의 네임스페이스가 있습니다. OpenShift Container Platform은 OpenShift Container Platform에서 설치한 CRD, OpenShift Container Platform과 통합된 제품 및 사용자가 생성한 CRD를 포함하여 총 사용자 정의 리소스 정의(CRD)를 1,024개로 제한합니다. 1,024개가 넘는 CRD가 생성된 경우
oc명령 요청이 제한될 가능성이 있습니다.
7.1.1. 시나리오 예 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어, 500개의 워커 노드(m5.2xl)가 OpenShift Container Platform 4.19, OVN-Kubernetes 네트워크 플러그인 및 다음 워크로드 객체를 사용하여 테스트되었으며 지원됩니다.
- 기본값 외에 200개의 네임스페이스
- 노드당 60개의 포드, 30개의 서버 포드와 30개의 클라이언트 포드(총 30,000개)
- 57개 이미지 스트림/ns(총 11.4k)
- 서버 포드가 지원하는 15개 서비스/ns(총 3k)
- 이전 서비스에서 지원하는 15개 경로/ns(총 3k)
- 20개의 비밀/ns(총 4k개)
- 10개의 구성 맵/ns(총 2k)
- 6 네트워크 정책/ns, deny-all, allow-from ingress 및 intra-namespace 규칙 6개
- 57개 빌드/ns
다음 요소는 클러스터 작업 부하 확장에 긍정적 또는 부정적으로 영향을 미치는 것으로 알려져 있으며, 배포를 계획할 때 확장 수치에 반영해야 합니다. 추가 정보 및 지침이 필요하면 영업 담당자나 Red Hat 지원팀 에 문의하세요.
- 노드당 Pod 수
- 포드당 컨테이너 수
- 사용된 프로브 유형(예: 활성/준비, 실행/http)
- 네트워크 정책의 수
- 프로젝트 또는 네임스페이스 수
- 프로젝트당 이미지 스트림 수
- 프로젝트당 빌드 수
- 서비스/엔드포인트 수 및 유형
- 경로 수
- 샤드의 수
- 비밀의 개수
- 구성 맵의 수
API 호출 비율 또는 클러스터 "이탈"은 클러스터 구성에서 상황이 얼마나 빨리 변경되는지에 대한 추정치입니다.
-
5분 창 동안 초당 포드 생성 요청에 대한 Prometheus 쿼리:
sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m])) -
5분 동안 초당 모든 API 요청에 대한 Prometheus 쿼리:
sum(irate(apiserver_request_count{}[5m]))
-
5분 창 동안 초당 포드 생성 요청에 대한 Prometheus 쿼리:
- CPU의 클러스터 노드 리소스 소비
- 클러스터 노드 리소스 메모리 소비