2장. 권장되는 성능 및 확장성 관행
2.1. 권장되는 제어 평면 관행 링크 복사링크가 클립보드에 복사되었습니다!
이 주제에서는 OpenShift Container Platform의 제어 평면에 대한 권장 성능 및 확장성 사례를 제공합니다.
2.1.1. 클러스터 스케일링에 대한 권장 사례 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션의 지침은 클라우드 공급자 통합을 통한 설치에만 관련이 있습니다.
다음 모범 사례를 적용하여 OpenShift Container Platform 클러스터의 작업자 머신 수를 스케일링하십시오. 작업자 머신 세트에 정의된 복제본 수를 늘리거나 줄여 작업자 머신을 스케일링합니다.
노드 수가 많아지도록 클러스터를 확장하는 경우 다음을 수행합니다.
- 고가용성을 위해 모든 사용 가능한 영역으로 노드를 분산합니다.
- 한 번에 확장하는 머신 수가 25~50개를 넘지 않도록 합니다.
- 주기적인 공급자 용량 제약을 완화하기 위해 비슷한 크기의 대체 인스턴스 유형을 사용하여 각 사용 가능한 영역에 새로운 컴퓨팅 머신 세트를 만드는 것을 고려하세요. 예를 들어 AWS에서 m5.large 및 m5d.large를 사용합니다.
클라우드 제공자는 API 서비스 할당량을 구현할 수 있습니다. 따라서 점진적으로 클러스터를 스케일링하십시오.
모든 컴퓨팅 머신 세트의 복제본이 동시에 더 높은 숫자로 설정된 경우 컨트롤러가 머신을 생성하지 못할 수 있습니다. OpenShift Container Platform이 배포된 클라우드 플랫폼에서 처리할 수 있는 요청 수는 프로세스에 영향을 미칩니다. 컨트롤러는 상태를 사용하여 머신을 생성하고, 점검하고, 업데이트하는 동안 더 많이 쿼리하기 시작합니다. OpenShift Container Platform이 배포된 클라우드 플랫폼에는 API 요청 제한이 있습니다. 클라우드 플랫폼의 제한으로 인해 과도한 쿼리로 인해 머신 생성이 실패할 수 있습니다.
노드 수가 많아지도록 스케일링하는 경우 머신 상태 점검을 활성화하십시오. 실패가 발생하면 상태 점검에서 상태를 모니터링하고 비정상 머신을 자동으로 복구합니다.
대규모 고밀도 클러스터를 확장하여 노드 수를 줄이면 종료되는 노드에서 병렬로 실행 중인 객체를 비우거나 내보내는 프로세스가 필요하기 때문에 많은 시간이 걸릴 수 있습니다. 또한 제거할 개체가 너무 많으면 클라이언트 요청 처리에 병목 현상이 발생할 수 있습니다. 기본 클라이언트 초당 쿼리 수(QPS)와 버스트 속도는 현재 각각 50
과 100
으로 설정되어 있습니다. 이러한 값은 OpenShift Container Platform에서 수정할 수 없습니다.
2.1.2. 컨트롤 플레인 노드 크기 조정 링크 복사링크가 클립보드에 복사되었습니다!
제어 평면 노드 리소스 요구 사항은 클러스터의 노드와 개체의 수와 유형에 따라 달라집니다. 다음의 제어 평면 노드 크기 권장 사항은 제어 평면 밀도 중심 테스트 또는 클러스터 밀도 테스트 의 결과를 기반으로 합니다. 이 테스트는 주어진 수의 네임스페이스에 걸쳐 다음 객체를 생성합니다.
- 1개의 이미지 스트림
- 1 빌드
-
2개의 포드 복제본이
절전
상태에 있고 각각 4개의 비밀, 4개의 구성 맵 및 1개의 하향 API 볼륨을 마운트하는 5개의 배포 - 각각 이전 배포 중 하나의 TCP/8080 및 TCP/8443 포트를 가리키는 5개의 서비스
- 이전 서비스 중 첫 번째 서비스를 가리키는 1개 경로
- 2048개의 난수 문자열을 포함하는 10개의 비밀
- 2048개의 무작위 문자열을 포함하는 10개의 구성 맵
작업자 노드 수 | 클러스터 밀도(네임스페이스) | CPU 코어 수 | 메모리(GB) |
---|---|---|---|
24 | 500 | 4 | 16 |
120 | 1000 | 8 | 32 |
252 | 4000 | 16개이지만 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 24개입니다. | 64개이지만 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 128개입니다. |
501이지만 OVN-Kubernetes 네트워크 플러그인으로 테스트되지 않았습니다. | 4000 | 16 | 96 |
위 표의 데이터는 AWS 상에서 실행되는 OpenShift 컨테이너 플랫폼을 기반으로 하며, r5.4xlarge 인스턴스를 제어 평면 노드로, m5.2xlarge 인스턴스를 작업자 노드로 사용합니다.
컨트롤 플레인 노드가 3개인 대규모 및 밀도가 높은 클러스터에서는 노드 중 하나가 중지, 재부팅 또는 실패할 때 CPU 및 메모리 사용량이 증가합니다. 실패는 전원, 네트워크, 기반 인프라의 예상치 못한 문제로 인해 발생할 수도 있고, 비용을 절감하기 위해 클러스터를 종료한 후 의도적으로 다시 시작하는 경우도 있습니다. 나머지 두 개의 제어 평면 노드는 높은 가용성을 유지하기 위해 부하를 처리해야 하며, 이로 인해 리소스 사용량이 증가합니다. 이는 제어 평면 노드가 격리되고, 드레인되고, 재부팅되어 운영 체제 업데이트와 제어 평면 운영자 업데이트가 적용되기 때문에 업그레이드 중에도 예상됩니다. 연쇄적인 실패를 방지하려면 컨트롤 플레인 노드의 전체 CPU 및 메모리 리소스 사용량을 사용 가능한 모든 용량의 최대 60%로 유지하여 리소스 사용량 급증을 처리하세요. 리소스 부족으로 인한 다운타임을 방지하기 위해 컨트롤 플레인 노드에서 CPU 및 메모리를 늘립니다.
노드 크기 조정은 클러스터의 노드 수와 개체 수에 따라 달라집니다. 또한 클러스터에서 개체가 현재 생성되는지에 따라 달라집니다. 객체 생성 중에는 객체가 실행
단계에 있을 때보다 리소스 사용 측면에서 제어 평면이 더 활발하게 작동합니다.
OLM(Operator Lifecycle Manager)은 제어 평면 노드에서 실행되며 메모리 사용량은 OLM이 클러스터에서 관리해야 하는 네임스페이스와 사용자가 설치한 운영자의 수에 따라 달라집니다. 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.19 클러스터에서 제어 평면 노드 크기를 수정할 수 있습니다.
- 사용자가 제공한 설치 방법으로 설치된 클러스터입니다.
- AWS 클러스터는 설치 프로그램에서 제공하는 인프라 설치 방법을 통해 설치됩니다.
- 제어 평면 머신을 관리하기 위해 제어 평면 머신 세트를 사용하는 클러스터입니다.
다른 모든 구성의 경우, 설치 중에 총 노드 수를 추정하고 제안된 제어 평면 노드 크기를 사용해야 합니다.
OpenShift Container Platform 4.19에서는 OpenShift Container Platform 3.11 및 이전 버전과 비교했을 때 CPU 코어의 절반(500밀리코어)이 이제 시스템에 의해 기본적으로 예약됩니다. 이러한 점을 고려하여 크기가 결정됩니다.
2.1.2.1. 제어 평면 머신에 대해 더 큰 Amazon Web Services 인스턴스 유형 선택 링크 복사링크가 클립보드에 복사되었습니다!
Amazon Web Services(AWS) 클러스터의 제어 플레인 머신에 더 많은 리소스가 필요한 경우 제어 플레인 머신에 사용할 더 큰 AWS 인스턴스 유형을 선택할 수 있습니다.
제어 평면 머신 세트를 사용하는 클러스터의 절차는 제어 평면 머신 세트를 사용하지 않는 클러스터의 절차와 다릅니다.
클러스터의 ControlPlaneMachineSet
CR 상태가 확실하지 않은 경우 CR 상태를 확인할 수 있습니다.
2.1.2.1.1. 제어 평면 머신 세트를 사용하여 Amazon Web Services 인스턴스 유형 변경 링크 복사링크가 클립보드에 복사되었습니다!
제어 평면 머신이 사용하는 Amazon Web Services(AWS) 인스턴스 유형을 변경하려면 제어 평면 머신 세트 사용자 정의 리소스(CR)의 사양을 업데이트하면 됩니다.
사전 요구 사항
- AWS 클러스터는 제어 평면 머신 세트를 사용합니다.
프로세스
다음 명령을 실행하여 제어 평면 머신 세트 CR을 편집합니다.
oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster
$ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow providerSpec
필드 아래의 다음 줄을 편집하세요.providerSpec: value: ... instanceType: <compatible_aws_instance_type>
providerSpec: value: ... instanceType: <compatible_aws_instance_type>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이전 선택과 동일한 기반을 사용하여 더 큰 AWS 인스턴스 유형을 지정합니다. 예를 들어,
m6i.xlarge를
m6i.2xlarge
또는m6i.4xlarge
로 변경할 수 있습니다.
변경 사항을 저장하십시오.
-
기본
RollingUpdate
업데이트 전략을 사용하는 클러스터의 경우 Operator는 변경 사항을 제어 평면 구성에 자동으로 전파합니다. -
OnDelete
업데이트 전략을 사용하도록 구성된 클러스터의 경우 제어 평면 머신을 수동으로 교체해야 합니다.
-
기본
2.1.2.1.2. AWS 콘솔을 사용하여 Amazon Web Services 인스턴스 유형 변경 링크 복사링크가 클립보드에 복사되었습니다!
AWS 콘솔에서 인스턴스 유형을 업데이트하여 제어 플레인 머신이 사용하는 Amazon Web Services(AWS) 인스턴스 유형을 변경할 수 있습니다.
사전 요구 사항
- 클러스터의 EC2 인스턴스를 수정하는 데 필요한 권한으로 AWS 콘솔에 액세스할 수 있습니다.
-
cluster-admin
역할이 있는 사용자로 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
프로세스
- AWS 콘솔을 열고 제어 플레인 머신의 인스턴스를 가져옵니다.
컨트롤 플레인 머신 인스턴스 1개를 선택합니다.
- 선택한 컨트롤 플레인 시스템의 경우 etcd 스냅샷을 생성하여 etcd 데이터를 백업하십시오. 자세한 내용은 "etcd 백업"을 참조하세요.
- AWS 콘솔에서 제어 평면 머신 인스턴스를 중지합니다.
-
중지된 인스턴스를 선택하고 작업
인스턴스 설정 인스턴스 유형 변경을 클릭합니다. -
인스턴스를 더 큰 유형으로 변경하고 해당 유형이 이전 선택 항목과 동일한 기준인지 확인한 다음 변경 사항을 적용합니다. 예를 들어,
m6i.xlarge를
m6i.2xlarge
또는m6i.4xlarge
로 변경할 수 있습니다. - 인스턴스를 시작합니다.
-
OpenShift Container Platform 클러스터에 인스턴스에 해당하는
Machine
객체가 있는 경우 AWS 콘솔에 설정된 인스턴스 유형과 일치하도록 객체의 인스턴스 유형을 업데이트합니다.
- 각 컨트롤 플레인 시스템에 대해 이 프로세스를 반복합니다.