1.4. 컨트롤 플레인 노드 크기 조정
컨트롤 플레인 노드 리소스 요구사항은 클러스터의 노드 수에 따라 달라집니다. 다음 컨트롤 플레인 노드 크기 권장 사항은 컨트롤 플레인 밀도 중심 테스트 결과를 기반으로 합니다. 컨트롤 플레인 테스트에서는 노드 수에 따라 각 네임스페이스의 클러스터에서 다음 오브젝트를 생성합니다.
- 12개의 이미지 스트림
- 3개의 빌드 구성
- 6개의 빌드
- 각각 두 개의 시크릿을 마운트하는 2개의 Pod 복제본이 있는 배포 1개
- 2개의 배포에 1개의 Pod 복제본이 2개의 시크릿을 마운트함
- 이전 배포를 가리키는 서비스 3개
- 이전 배포를 가리키는 경로 3개
- 10개의 시크릿, 이 중 2 개는 이전 배포에 의해 마운트됨
- 10개의 구성 맵, 이 중 두 개는 이전 배포에 의해 마운트됨
| 작업자 노드 수 | 클러스터 로드(네임스페이스) | CPU 코어 수 | 메모리(GB) |
|---|---|---|---|
| 25 | 500 | 4 | 16 |
| 100 | 1000 | 8 | 32 |
| 250 | 4000 | 16 | 96 |
3개의 마스터 또는 컨트롤 플레인 노드가 있는 대규모 및 고밀도 클러스터에서는 노드 중 하나가 중지되거나, 재부팅 또는 실패할 때 CPU 및 메모리 사용량이 증가합니다. 비용 절감을 위해 클러스터를 종료한 후 클러스터를 재시작하는 의도적인 경우 외에도 전원, 네트워크 또는 기본 인프라와 관련된 예기치 않은 문제로 인해 오류가 발생할 수 있습니다. 나머지 두 컨트롤 플레인 노드는 고가용성이 되기 위해 부하를 처리하여 리소스 사용량을 늘려야 합니다. 이는 마스터가 직렬로 연결, 드레이닝, 재부팅되어 운영 체제 업데이트를 적용하고 컨트롤 플레인 Operator 업데이트를 적용하기 때문에 업그레이드 중에도 이 문제가 발생할 수 있습니다. 단계적 오류를 방지하려면 컨트롤 플레인 노드의 전체 CPU 및 메모리 리소스 사용량을 리소스 사용량 급증을 처리하기 위해 사용 가능한 모든 용량의 60%로 유지합니다. 리소스 부족으로 인한 다운타임을 방지하기 위해 컨트롤 플레인 노드에서 CPU 및 메모리를 늘립니다.
노드 크기 조정은 클러스터의 노드 수와 개체 수에 따라 달라집니다. 또한 클러스터에서 개체가 현재 생성되는지에 따라 달라집니다. 개체 생성 중에 컨트롤 플레인은 개체가 running 단계에 있을 때보다 리소스 사용량 측면에서 더 활성화됩니다.
OLM(Operator Lifecycle Manager)은 컨트롤 플레인 노드에서 실행되며, 메모리 공간은 OLM이 클러스터에서 관리해야 하는 네임스페이스 및 사용자 설치된 operator 수에 따라 다릅니다. OOM이 종료되지 않도록 컨트를 플레인 노드의 크기를 적절하게 조정해야 합니다. 다음 데이터 지점은 클러스터 최대값 테스트 결과를 기반으로 합니다.
| 네임스페이스 수 | 유휴 상태의 OLM 메모리(GB) | 5명의 사용자 operator가 설치된 OLM 메모리(GB) |
|---|---|---|
| 500 | 0.823 | 1.7 |
| 1000 | 1.2 | 2.5 |
| 1500 | 1.7 | 3.2 |
| 2000 | 2 | 4.4 |
| 3000 | 2.7 | 5.6 |
| 4000 | 3.8 | 7.6 |
| 5000 | 4.2 | 9.02 |
| 6000 | 5.8 | 11.3 |
| 7000 | 6.6 | 12.9 |
| 8000 | 6.9 | 14.8 |
| 9000 | 8 | 17.7 |
| 10,000 | 9.9 | 21.6 |
설치 관리자 프로비저닝 인프라 설치 방법을 사용하는 경우 실행 중인 OpenShift Container Platform 4.8 클러스터에서 컨트롤 플레인 노드 크기를 변경할 수 없습니다. 대신 총 노드 수를 추정하고 설치하는 동안 권장되는 컨트롤 플레인 노드 크기를 사용해야 합니다.
권장 사항은 OpenShift SDN이 있는 OpenShift Container Platform 클러스터에서 네트워크 플러그인으로 캡처된 데이터 포인트를 기반으로 합니다.
OpenShift Container Platform 3.11 및 이전 버전과 비교하면, OpenShift Container Platform 4.8에서는 기본적으로 CPU 코어의 절반(500밀리코어)이 시스템에 의해 예약되어 있습니다. 이러한 점을 고려하여 크기가 결정됩니다.
1.4.1. AWS(Amazon Web Services) 마스터 인스턴스의 플레이버 크기 증가
클러스터에 AWS 마스터 노드에 과부하가 발생하고 마스터 노드에 더 많은 리소스가 필요한 경우 마스터 인스턴스의 플레이버 크기를 늘릴 수 있습니다.
AWS 마스터 인스턴스의 플레이버 크기를 늘리기 전에 etcd를 백업하는 것이 좋습니다.
사전 요구 사항
- AWS에 IPI(설치 프로그램 프로비저닝 인프라) 또는 UPI(사용자 프로비저닝 인프라) 클러스터가 있습니다.
절차
- AWS 콘솔을 열고 마스터 인스턴스를 가져옵니다.
- 하나의 마스터 인스턴스를 중지합니다.
-
중지된 인스턴스를 선택하고 작업
인스턴스 설정 인스턴스 유형 변경을 클릭합니다. -
인스턴스를 더 큰 유형으로 변경하고 유형이 이전 선택과 동일한 기본인지 확인하고 변경 사항을 적용합니다. 예를 들어
m5.xlarge를 m로 변경할 수 있습니다.5.2xlarge또는m5.4xlarge - 인스턴스를 백업하고 다음 master 인스턴스에 대한 단계를 반복합니다.
추가 리소스
