Red Hat Summit3장. 오브젝트 최대값에 따른 환경 계획
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 수 | 2,500 [3][4] |
| 코어당 Pod 수 | 기본값 없음 |
| 네임스페이스 수 [5] | 10,000 |
| 빌드 수 | 10,000(기본 Pod RAM 512Mi) - S2I(Source-to-Image) 빌드 전략 |
| 네임스페이스당 Pod 수 [6] | 25,000 |
| Ingress 컨트롤러당 경로 및 백엔드 수 | 라우터당 2,000개 |
| 보안 수 | 80,000 |
| 구성 맵 수 | 90,000 |
| 서비스 수 [7] | 10,000 |
| 네임스페이스당 서비스 수 | 5,000 |
| 서비스당 백엔드 수 | 5,000 |
| 네임스페이스당 배포 수 [6] | 2,000 |
| 빌드 구성 수 | 12,000 |
| CRD(사용자 정의 리소스 정의) 수 | 512 [8] |
- 일시 정지 Pod는 2000 노드 규모에서 OpenShift Container Platform의 컨트롤 플레인 구성 요소를 과부하시키기 위해 배포되었습니다. 유사한 숫자로 확장하는 기능은 특정 배포 및 워크로드 매개변수에 따라 달라집니다.
- 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
-
이 테스트는 컨트롤 플레인 3개, 인프라 노드 2개, 작업자 노드 26개 등 31개의 서버가 있는 클러스터에서 테스트되었습니다. 2,500개의 사용자 Pod가 필요한 경우 각 노드에 2000개 이상의 Pod를 포함할 수 있을 만큼 큰 네트워크를 할당하고
maxPods가2500으로 설정된 사용자 정의 kubelet 구성이 모두 필요한20개의hostPrefix가 필요합니다. 자세한 내용은 OCP 4.13에서 노드당 2500개의 Pod 실행을 참조하십시오. -
노드당 테스트된 최대 Pod는
OVNKubernetes네트워크 플러그인을 사용하는 클러스터의 경우 2,500입니다.OpenShiftSDN네트워크 플러그인의 노드당 테스트된 최대 Pod는 500개의 포드입니다. - 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 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.13, 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]))
-
5분 창에 Pod 생성 요청에 대한 Prometheus 쿼리:
- CPU의 클러스터 노드 리소스 소비
- 메모리의 클러스터 노드 리소스 사용
