확장 및 성능
프로덕션 환경에서 OpenShift Container Platform 클러스터 스케일링 및 성능 튜닝
초록
1장. OpenShift 컨테이너 플랫폼 확장성 및 성능 개요 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 클러스터의 성능과 규모를 최적화하는 데 도움이 되는 모범 사례와 도구를 제공합니다. 다음 문서에서는 권장되는 성능 및 확장성 관행, 참조 설계 사양, 최적화 및 저지연 튜닝에 대한 정보를 제공합니다.
Red Hat 지원팀에 문의하려면 지원 받기를 참조하세요.
일부 성능 및 확장성 운영자는 OpenShift Container Platform 릴리스 주기와 독립적인 릴리스 주기를 갖습니다. 자세한 내용은 OpenShift 연산자를 참조하세요.
1.1. 권장되는 성능 및 확장성 관행 링크 복사링크가 클립보드에 복사되었습니다!
1.2. 통신사 참조 설계 사양 링크 복사링크가 클립보드에 복사되었습니다!
1.3. 계획, 최적화 및 측정 링크 복사링크가 클립보드에 복사되었습니다!
IBM Z 및 IBM LinuxONE에 대한 권장 사례
클러스터 안정성 향상 및 작업 분할을 위한 저지연 튜닝
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 콘솔에 설정된 인스턴스 유형과 일치하도록 객체의 인스턴스 유형을 업데이트합니다.
- 각 컨트롤 플레인 시스템에 대해 이 프로세스를 반복합니다.
2.2. 권장되는 인프라 관행 링크 복사링크가 클립보드에 복사되었습니다!
이 주제에서는 OpenShift Container Platform의 인프라에 대한 권장 성능 및 확장성 사례를 제공합니다.
2.2.1. 인프라 노드 크기 조정 링크 복사링크가 클립보드에 복사되었습니다!
인프라 노드는 OpenShift Container Platform 환경의 일부를 실행하도록 레이블이 지정된 노드입니다. 인프라 노드 리소스 요구사항은 클러스터 사용 기간, 노드, 클러스터의 오브젝트에 따라 달라집니다. 이러한 요인으로 인해 Prometheus의 지표 또는 시계열 수가 증가할 수 있기 때문입니다. 다음 인프라 노드 크기 권장 사항은 제어 평면 노드 크기 섹션에 자세히 설명된 클러스터 밀도 테스트에서 관찰된 결과를 기반으로 합니다. 여기서 모니터링 스택과 기본 인그레스 컨트롤러가 이러한 노드로 이동되었습니다.
작업자 노드 수 | 클러스터 밀도 또는 네임스페이스 수 | CPU 코어 수 | 메모리(GB) |
---|---|---|---|
27 | 500 | 4 | 24 |
120 | 1000 | 8 | 48 |
252 | 4000 | 16 | 128 |
501 | 4000 | 32 | 128 |
일반적으로 클러스터당 세 개의 인프라 노드를 사용하는 것이 좋습니다.
이러한 크기 조정 권장 사항은 지침으로 사용해야 합니다. Prometheus는 고도의 메모리 집약적 애플리케이션입니다. 리소스 사용량은 노드 수, 오브젝트, Prometheus 지표 스크래핑 간격, 지표 또는 시계열, 클러스터 사용 기간 등 다양한 요인에 따라 달라집니다. 또한 라우터 리소스 사용량은 경로 수와 인바운드 요청의 양/유형에 따라 영향을 받을 수도 있습니다.
이러한 권장 사항은 클러스터 생성 중에 설치된 모니터링, 수신 및 레지스트리 인프라 구성 요소를 호스팅하는 인프라 노드에만 적용됩니다.
OpenShift Container Platform 4.19에서는 OpenShift Container Platform 3.11 및 이전 버전과 비교했을 때 CPU 코어의 절반(500밀리코어)이 이제 시스템에 의해 기본적으로 예약됩니다. 명시된 크기 조정 권장 사항은 이러한 요인의 영향을 받습니다.
2.2.2. Cluster Monitoring Operator 스케일링 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은CMO(Cluster Monitoring Operator)가 수집하여 Prometheus 기반 모니터링 스택에 저장하는 지표를 노출합니다. 관리자는 OpenShift Container Platform 웹 콘솔에서 Observe → Dashboards 로 이동하여 시스템 리소스, 컨테이너 및 구성 요소 메트릭에 대한 대시보드를 볼 수 있습니다.
2.2.3. Prometheus 데이터베이스 스토리지 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 다양한 규모에 대해 다양한 테스트를 수행했습니다.
- 다음 Prometheus 저장 요구 사항은 규정적인 것이 아니며 참조용으로 사용해야 합니다. Prometheus에서 수집한 메트릭을 노출하는 포드, 컨테이너, 경로 또는 기타 리소스의 수를 포함하여 작업 부하 활동 및 리소스 밀도에 따라 클러스터에서 더 높은 리소스 소비가 관찰될 수 있습니다.
- 저장 요구 사항에 맞게 크기 기반 데이터 보존 정책을 구성할 수 있습니다.
노드 수 | 포드 수(포드당 컨테이너 2개) | Prometheus 스토리지 증가(1일당) | Prometheus 스토리지 증가(15일당) | 네트워크(tsdb 청크당) |
---|---|---|---|---|
50 | 1800 | 6.3GB | 94GB | 16MB |
100 | 3600 | 13GB | 195GB | 26MB |
150 | 5400 | 19GB | 283GB | 36MB |
200 | 7200 | 25GB | 375GB | 46MB |
스토리지 요구사항이 계산된 값을 초과하지 않도록 예상 크기의 약 20%가 오버헤드로 추가되었습니다.
위의 계산은 기본 OpenShift Container Platform Cluster Monitoring Operator용입니다.
CPU 사용률은 약간의 영향을 미칩니다. 50개 노드 및 1,800개 Pod당 비율이 약 40개 중 1개 코어입니다.
OpenShift Container Platform 권장 사항
- 최소한 두 개의 인프라(infra) 노드를 사용하세요.
- SSD 또는 NVMe(Non-volatile Memory express) 드라이브를 사용하여 openshift-container-storage 노드를 3개 이상 사용합니다.
2.2.4. 클러스터 모니터링 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 모니터링 스택에서 Prometheus 구성 요소의 저장 용량을 늘릴 수 있습니다.
프로세스
Prometheus의 스토리지 용량을 늘리려면 다음을 수행합니다.
cluster-monitoring-config.yaml
이라는 YAML 구성 파일을 만듭니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Prometheus 보존의 기본값은
PROMETHEUS_RETENTION_PERIOD=15d
입니다. 단위는 s, m, h, d 접미사 중 하나를 사용하는 시간으로 측정됩니다. - 2 4
- 클러스터의 스토리지 클래스입니다.
- 3
- 일반적인 값은
PROMETHEUS_STORAGE_SIZE=2000Gi
입니다. 저장 값은 일반 정수이거나 다음 접미사 중 하나를 사용하는 고정 소수점 정수일 수 있습니다: E, P, T, G, M, K. 또한 2의 거듭제곱인 Ei, Pi, Ti, Gi, Mi, Ki를 사용할 수도 있습니다. - 5
- 일반적인 값은
ALERTMANAGER_STORAGE_SIZE=20Gi
입니다. 저장 값은 일반 정수이거나 다음 접미사 중 하나를 사용하는 고정 소수점 정수일 수 있습니다: E, P, T, G, M, K. 또한 2의 거듭제곱인 Ei, Pi, Ti, Gi, Mi, Ki를 사용할 수도 있습니다.
- 보존 기간, 스토리지 클래스, 스토리지 크기에 대한 값을 추가합니다.
- 파일을 저장합니다.
다음을 실행하여 변경사항을 적용합니다.
oc create -f cluster-monitoring-config.yaml
$ oc create -f cluster-monitoring-config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3장. 통신사 핵심 참조 설계 사양 링크 복사링크가 클립보드에 복사되었습니다!
통신사 코어 참조 설계 사양(RDS)은 상용 하드웨어에서 실행되는 OpenShift Container Platform 클러스터를 구성하여 통신사 코어 워크로드를 호스팅합니다.
3.1. Telco Core RDS 4.19 사용 모델 개요 링크 복사링크가 클립보드에 복사되었습니다!
Telco 코어 참조 설계 사양(RDS)은 신호 및 집계와 같은 컨트롤 플레인 기능을 포함하여 대규모 통신 애플리케이션을 지원하는 플랫폼을 설명합니다. 또한 몇 가지 중앙 집중식 데이터 플레인 기능(예: 사용자 플레인 기능(UPF))이 포함되어 있습니다. 이러한 기능은 일반적으로 확장성, 복잡한 네트워킹 지원, 복원력 있는 소프트웨어 정의 스토리지를 필요로 하며, RAN과 같은 원거리 배포보다 덜 엄격하고 제약이 적은 성능 요구 사항을 지원합니다.
3.2. 통신사 코어 클러스터 사용 모델에 대하여 링크 복사링크가 클립보드에 복사되었습니다!
통신사 코어 클러스터 사용 모델은 상용 하드웨어에서 실행되는 클러스터를 위해 설계되었습니다. 통신사 코어 클러스터는 신호, 집계, 세션 경계 컨트롤러(SBC)와 같은 제어 평면 기능과 5G 사용자 평면 기능(UPF)과 같은 중앙 집중식 데이터 평면 기능을 포함한 대규모 통신사 애플리케이션을 지원합니다. 통신사 핵심 클러스터 기능에는 확장성, 복잡한 네트워킹 지원, 복원력 있는 소프트웨어 정의 스토리지가 필요하며, 원거리 RAN 구축에 비해 엄격하지 않고 제약이 적은 성능 요구 사항을 지원해야 합니다.
통신사의 핵심 기능에 대한 네트워킹 요구 사항은 다양한 네트워킹 기능과 성능 지점에 따라 크게 다릅니다. IPv6는 필수이며 듀얼 스택이 일반적입니다. 일부 기능에는 최대 처리량과 트랜잭션 속도가 필요하며 사용자 평면 DPDK 네트워킹 지원이 필요합니다. 다른 기능은 보다 일반적인 클라우드 네이티브 패턴을 사용하며 OVN-Kubernetes, 커널 네트워킹 및 부하 분산을 활용할 수 있습니다.
통신사 핵심 클러스터는 표준으로 3개의 제어 평면과 스톡(비 RT) 커널로 구성된 1개 이상의 작업자 노드로 구성됩니다. 네트워킹 및 성능 요구 사항이 다양한 워크로드를 지원하기 위해 MachineConfigPool
사용자 지정 리소스(CR)를 사용하여 작업자 노드를 분할할 수 있습니다(예: 비사용자 데이터 플레인 또는 고처리량 사용 사례). 필수적인 통신사 운영 기능을 지원하기 위해 핵심 클러스터에는 Day 2 OLM 관리 운영자의 표준 세트가 설치되어 있습니다.
그림 3.1. Telco 핵심 RDS 클러스터 서비스 기반 아키텍처 및 네트워킹 토폴로지
3.3. 참조 설계 범위 링크 복사링크가 클립보드에 복사되었습니다!
통신사 코어, 통신사 RAN 및 통신사 허브 참조 설계 사양(RDS)은 통신사 코어 및 통신사 RAN 프로필을 실행하는 클러스터에 대해 안정적이고 반복 가능한 성능을 얻기 위해 권장, 테스트 및 지원되는 구성을 담고 있습니다.
각 RDS에는 클러스터가 개별 프로필을 실행할 수 있도록 설계 및 검증되는 릴리스된 기능 및 지원되는 구성이 포함되어 있습니다. 이 구성은 기능 및 KPI 대상을 충족하는 기본 OpenShift Container Platform 설치를 제공합니다. 각 RDS는 개별 구성에 대해 예상되는 변형도 설명합니다. 각 RDS의 검증에는 긴 기간과 대규모 테스트가 포함되어 있습니다.
검증된 참조 구성은 OpenShift Container Platform의 각 주요 Y-stream 릴리스에 대해 업데이트됩니다. Z-stream 패치 릴리스는 참조 구성에 대해 주기적으로 다시 테스트됩니다.
3.4. 참조 설계의 편차 링크 복사링크가 클립보드에 복사되었습니다!
검증된 통신 코어, 통신 RAN DU 및 통신 허브 참조 설계 사양(RDS)에서 벗어나면 변경하는 특정 구성 요소나 기능 외에도 상당한 영향을 미칠 수 있습니다. 편차는 전체 솔루션의 맥락에서 분석 및 엔지니어링이 필요합니다.
RDS의 모든 편차는 명확한 작업 추적 정보로 분석 및 문서화되어야 합니다. 실사실은 파트너로부터 참조 설계에 맞춰 편차를 가져오는 방법을 이해할 것으로 예상됩니다. 이를 위해서는 파트너사가 Red Hat과 협력하여 플랫폼에서 최상의 결과를 얻을 수 있도록 활용 사례를 제공하기 위해 추가 리소스를 제공해야 할 수 있습니다. 이는 솔루션의 지원 가능성과 Red Hat 및 파트너 간의 조정을 보장하는 데 매우 중요합니다.
RDS의 편차는 다음과 같은 결과 중 일부 또는 모두를 가질 수 있습니다.
- 문제를 해결하는 데 시간이 더 걸릴 수 있습니다.
- 프로젝트 서비스 수준 계약(SLA), 프로젝트 기한, 최종 공급자 성능 요구 사항이 누락될 위험이 있습니다.
승인되지 않은 편차는 행정 수준에서 에스컬레이션이 필요할 수 있습니다.
참고Red Hat은 파트너 참여 우선 순위에 따라 편차 요청의 우선 순위를 지정합니다.
3.5. 통신사 핵심 공통 기준 모델 링크 복사링크가 클립보드에 복사되었습니다!
다음 구성 및 사용 모델은 모든 통신사 핵심 사용 사례에 적용할 수 있습니다. 통신사의 핵심 사용 사례는 이러한 공통적인 기능 기준을 기반으로 구축됩니다.
- 클러스터 토폴로지
통신사 핵심 클러스터는 다음 요구 사항을 준수합니다.
- 고가용성 제어 평면(3개 이상의 제어 평면 노드)
- 예약 불가능한 제어 평면 노드
- 여러 머신 구성 풀
- 스토리지
- 통신사의 핵심 사용 사례에는 OpenShift Data Foundation에서 제공하는 영구 저장소가 필요합니다.
- 네트워킹
통신사 코어 클러스터 네트워킹은 다음 요구 사항을 준수합니다.
- 듀얼 스택 IPv4/IPv6(IPv4 기본).
- 완전히 분리됨 – 클러스터는 수명 주기의 어떤 시점에서도 공용 네트워크에 액세스할 수 없습니다.
- 다양한 네트워크를 지원합니다. 세분화된 네트워킹은 운영, 관리 및 유지 보수(OAM), 신호 및 스토리지 트래픽을 분리합니다.
- IPv6 지원에 필요한 클러스터 네트워크 유형은 OVN-Kubernetes입니다.
통신사 코어 클러스터는 RHCOS, SR-IOV 네트워크 운영자, 부하 분산 장치 및 기타 구성 요소의 지원을 받는 여러 계층의 네트워킹을 갖추고 있습니다. 이러한 계층에는 다음이 포함됩니다.
클러스터 네트워킹 계층. 클러스터 네트워크 구성은 설치 구성을 통해 정의되고 적용됩니다. 2일차 작업 중에 NMState Operator를 사용하여 구성을 업데이트합니다. 초기 구성을 사용하여 다음을 설정합니다.
- 호스트 인터페이스 구성.
- 활성/활성 본딩(LACP).
-
2차/추가 네트워크 계층. 네트워크
추가
Network 또는NetworkAttachmentDefinition
CR을 통해 OpenShift Container Platform CNI를 구성합니다. 초기 구성을 사용하여 MACVLAN 가상 네트워크 인터페이스를 구성합니다. - 애플리케이션 워크로드 계층. 사용자 평면 네트워킹은 클라우드 기반 네트워크 기능(CNF)에서 실행됩니다.
- 서비스 메시
- 통신사 CNF는 Service Mesh를 사용할 수 있습니다. 모든 통신사 코어 클러스터에는 서비스 메시 구현이 필요합니다. 구현 및 구성의 선택은 이 사양의 범위를 벗어납니다.
3.6. 배포 계획 링크 복사링크가 클립보드에 복사되었습니다!
작업자 노드 및 머신 구성 풀
MachineConfigPools
(MCP) 사용자 정의 리소스(CR)를 사용하면 고객 계획 매개변수에 따라 통신사 핵심 클러스터의 작업자 노드를 여러 노드 그룹으로 세분화할 수 있습니다. MCP를 사용한 신중한 배포 계획은 배포 및 업그레이드 시간을 최소화하는 데 필수적이며, 더 중요한 것은 클러스터 업그레이드 중에 통신사급 서비스가 중단되는 것을 최소화하는 것입니다.
설명
통신사 코어 클러스터는 MCP를 사용하여 작업자 노드를 추가적인 별도 역할로 분할할 수 있습니다(예: 하드웨어 프로필이 다름). 이를 통해 각 역할에 맞게 사용자 정의 튜닝이 가능하며, 통신사 핵심 클러스터의 배포나 업그레이드를 가속화하는 데 중요한 역할을 합니다. 더 중요한 점은 여러 MCP를 사용하면 하나 이상의 유지 관리 창에 걸쳐 클러스터 업그레이드를 적절하게 계획할 수 있다는 것입니다. 이는 신중한 계획이 없다면 통신사 수준의 서비스에 영향을 미칠 수 있으므로 매우 중요합니다.
클러스터 업그레이드 중에 제어 평면을 업그레이드하는 동안 MCP를 일시 중지할 수 있습니다. 자세한 내용은 "카나리아 롤아웃 업데이트 수행"을 참조하세요. 이렇게 하면 MCP가 일시 중지 해제될 때까지 작업자 노드가 재부팅되지 않고 실행 중인 작업 부하가 영향을 받지 않습니다.
신중한 MCP 계획을 사용하면 언제든지 어떤 노드 세트를 업그레이드할지 시기와 순서를 제어할 수 있습니다. MCP를 사용하여 통신사 업그레이드를 계획하는 방법에 대한 자세한 내용은 "업데이트 전에 노드에 MachineConfigPool 레이블 적용"을 참조하세요.
초기 배포를 시작하기 전에 MCP와 관련하여 다음 엔지니어링 고려 사항을 염두에 두십시오.
PerformanceProfile
정의를 사용할 때 각 MCP는 정확히 하나의 PerformanceProfile
정의 또는 조정된 프로필 정의에 연결되어야 한다는 점을 기억하세요. 따라서 원하는 구성이 여러 MCP에 대해 동일하더라도 각 MCP에는 여전히 자체적인 전용 PerformanceProfile
정의가 필요합니다.
다음과 같은 고려 사항에 따라 작업자 노드를 분할하기 위한 적절한 전략으로 MCP 라벨링을 계획하세요.
- 작업자 노드 유형: 동등한 하드웨어 프로필을 갖춘 노드 그룹을 식별합니다. 예를 들어, 제어 평면 네트워크 기능(NF)을 위한 작업자와 사용자 데이터 평면 NF를 위한 작업자입니다.
- 워커 노드 유형당 워커 노드 수.
- 동등한 하드웨어 프로필에 필요한 최소 MCP 수는 1이지만, 더 큰 클러스터의 경우 더 많을 수 있습니다. 예를 들어, 각 단계에서 클러스터 용량에 영향을 미치는 비율을 낮추어 보다 세분화된 업그레이드를 지원하기 위해 하드웨어 프로필당 더 많은 MCP를 설계할 수 있습니다.
MCP 내의 노드에 대한 업데이트를 수행하기 위한 전략은 업그레이드 요구 사항과 선택한
maxUnavailable
값에 따라 형성됩니다.- 허용되는 유지 관리 기간의 수.
- 유지 관리 기간.
- 워커 노드의 총 수.
-
MCP에 대해 원하는
maxUnavailable
(동시에 업데이트되는 노드 수)입니다.
작업자 노드에 대한 CNF 요구 사항은 다음과 같습니다.
- 업그레이드 중에 필요한 Pod당 최소 가용성은 Pod 중단 예산(PDB)으로 구성됩니다. PDB는 업그레이드 중에 통신사 서비스 수준 계약(SLA)을 유지하는 데 필수적입니다. PDB에 대한 자세한 내용은 "포드 중단 예산을 사용하여 작동해야 하는 포드 수를 지정하는 방법 이해"를 참조하세요.
- 각 복제본이 별도의 하드웨어에서 실행되도록 Pod당 최소한의 진정한 고가용성이 필요합니다.
- Pod 친화성 및 반친화성 링크: Pod 친화성 및 반친화성을 사용하는 방법에 대한 자세한 내용은 "친화성 및 반친화성 규칙을 사용하여 다른 Pod에 대한 Pod 배치"를 참조하세요.
- 통신사 수준의 서비스에 영향을 줄 수 있는 업그레이드 유지 관리 기간 및 빈도입니다.
3.7. 통신사 핵심 클러스터 공통 사용 모델 엔지니어링 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 클러스터 작업 부하에 대한 자세한 내용은 "애플리케이션 작업 부하"에 나와 있습니다.
작업자 노드는 다음 CPU 중 하나에서 실행되어야 합니다.
- OpenShift Container Platform에서 지원하는 Intel 3세대 Xeon(IceLake) CPU 이상이거나 실리콘 보안 버그(Spectre 등) 완화 기능이 꺼진 CPU입니다. Skylake 및 이전 CPU의 경우 Spectre 및 유사한 완화 조치를 활성화하면 트랜잭션 성능이 40% 감소할 수 있습니다. Skylake 및 이전 CPU가 전원 상태를 변경하면 지연이 발생할 수 있습니다.
- AMD EPYC Zen 4 CPU(Genoa, Bergamo).
-
작업자 노드에서 IRQ 밸런싱이 활성화되었습니다.
PerformanceProfile
CR은globalDisableIrqLoadBalancing
매개변수를false
값으로 설정합니다. 보장된 QoS 포드는 "CPU 분할 및 성능 튜닝"에 설명된 대로 격리를 보장하도록 주석이 달려 있습니다.
모든 클러스터 노드에는 다음과 같은 기능이 있어야 합니다.
- 하이퍼스레딩을 활성화하세요
- x86_64 CPU 아키텍처를 가지고 있습니다
- 스톡(비실시간) 커널을 활성화하세요
- 작업 분할을 위해 구성되지 않았습니다.
클러스터 내의 머신 구성 풀에 따라 전원 관리와 최대 성능 간의 균형이 다릅니다. 다음 구성은 머신 구성 풀 그룹의 모든 노드에서 일관되어야 합니다.
- 클러스터 스케일링. 자세한 내용은 "확장성"을 참조하세요.
- 클러스터는 최소 120개 노드까지 확장할 수 있어야 합니다.
-
CPU 파티셔닝은
PerformanceProfile
CR을 사용하여 구성되며MachineConfigPool
기준으로 노드에 적용됩니다. 추가 고려 사항은 "CPU 파티셔닝 및 성능 튜닝"을 참조하세요. OpenShift Container Platform의 CPU 요구 사항은 구성된 기능 세트와 애플리케이션 워크로드 특성에 따라 달라집니다. kube-burner 노드 밀도 테스트에서 생성된 3000개 포드의 시뮬레이션 워크로드를 실행하는 참조 구성에 따라 구성된 클러스터의 경우 다음 CPU 요구 사항이 검증됩니다.
- 제어 평면 및 작업자 노드에 예약된 CPU의 최소 수는 NUMA 노드당 2개의 CPU(4개의 하이퍼스레드)입니다.
- DPDK가 아닌 네트워크 트래픽에 사용되는 NIC는 최대 32개의 RX/TX 대기열을 사용하도록 구성해야 합니다.
- 포드나 기타 리소스가 많은 노드에는 추가로 예약된 CPU가 필요할 수 있습니다. 나머지 CPU는 사용자 작업 부하에 사용할 수 있습니다.
참고OpenShift 컨테이너 플랫폼 구성, 작업 부하 크기 및 작업 부하 특성의 변화에 따라 OpenShift 플랫폼에 필요한 CPU 수에 미치는 영향을 파악하기 위해 추가 분석이 필요합니다.
3.7.1. 애플리케이션 워크로드 링크 복사링크가 클립보드에 복사되었습니다!
통신사 코어 클러스터에서 실행되는 애플리케이션 워크로드에는 고성능 클라우드 기반 네트워크 기능(CNF)과 기존의 베스트 이포트 또는 버스트 가능 포드 워크로드가 혼합되어 포함될 수 있습니다.
보장된 QoS 예약은 성능 또는 보안 요구 사항으로 인해 CPU를 독점적 또는 전용으로 사용해야 하는 Pod에서 사용할 수 있습니다. 일반적으로 사용자 평면 네트워킹(예: DPDK)을 사용하여 고성능 또는 지연에 민감한 CNF를 실행하는 Pod는 노드 튜닝과 보장된 QoS 스케줄링을 통해 달성된 전용 전체 CPU의 독점적인 사용이 필요합니다. 전용 CPU가 필요한 Pod 구성을 만들 때는 하이퍼스레드 시스템의 잠재적 영향을 알고 있어야 합니다. 전체 코어(2개의 하이퍼스레드)를 포드에 할당해야 하는 경우 포드는 2개의 CPU 배수를 요청해야 합니다.
높은 처리량이나 낮은 지연 네트워킹이 필요하지 않은 네트워크 기능을 실행하는 Pod는 최선의 노력 또는 버스트 가능 QoS Pod로 예약해야 하며 전용 또는 분리된 CPU 코어가 필요하지 않습니다.
- 엔지니어링 고려 사항
다음 정보를 사용하여 통신사 핵심 작업 부하와 클러스터 리소스를 계획하세요.
- OpenShift Container Platform 4.19부터 cgroup v1은 더 이상 지원되지 않으며 제거되었습니다. 이제 모든 워크로드는 cgroup v2와 호환되어야 합니다. 자세한 내용은 Red Hat OpenShift 워크로드 컨텍스트에서 Red Hat Enterprise Linux 9의 변경 사항을 참조하세요.
- CNF 애플리케이션은 Kubernetes를 위한 Red Hat 모범 사례 의 최신 버전을 준수해야 합니다.
애플리케이션의 요구에 따라 베스트 이포트 및 버스트 가능 QoS 포드를 혼합하여 사용하세요.
-
노드를 구성하는
PerformanceProfile
CR에서 예약되거나 격리된 CPU를 적절히 구성하여 보장된 QoS 포드를 사용합니다. - 보장된 QoS Pod에는 CPU를 완전히 분리하기 위한 주석이 포함되어야 합니다.
- 최선의 노력과 버스트 가능 포드는 독점적인 CPU 사용을 보장하지 않습니다. 작업 부하는 다른 작업 부하, 운영 체제 데몬 또는 커널 작업에 의해 우선 처리될 수 있습니다.
-
노드를 구성하는
exec 프로브는 아껴서 사용하고 다른 적합한 옵션을 사용할 수 없는 경우에만 사용하세요.
-
CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오. 다른 프로브 구현(예:
httpGet
또는tcpSocket
)을 사용합니다. - exec 프로브를 사용해야 하는 경우 exec 프로브 빈도 및 수량을 제한합니다. exec 프로브의 최대 개수는 10개 미만으로 유지해야 하며, 빈도는 10초 미만으로 설정해서는 안 됩니다.
- 정상 상태 작동에서는 많은 리소스를 사용하지 않으므로 시작 프로브를 사용할 수 있습니다. exec 프로브의 제한은 주로 liveness 및 readiness 프로브에 적용됩니다. 실행 프로브는 프로세스 포킹이 필요하기 때문에 다른 프로브 유형에 비해 관리 코어에서 CPU 사용량이 훨씬 더 높습니다.
-
CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오. 다른 프로브 구현(예:
3.7.2. 신호 작업 부하 링크 복사링크가 클립보드에 복사되었습니다!
신호 작업 부하에서는 일반적으로 SCTP, REST, gRPC 또는 이와 유사한 TCP나 UDP 프로토콜을 사용합니다. 신호 작업 부하는 MACVLAN 또는 SR-IOV 인터페이스로 구성된 보조 멀티 CNI를 사용하여 초당 수십만 건의 트랜잭션(TPS)을 지원합니다. 이러한 작업 부하는 보장된 QoS나 버스트 가능한 QoS를 갖춘 포드에서 실행될 수 있습니다.
3.8. 통신사 핵심 RDS 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션에서는 통신 핵심 워크로드를 실행하기 위해 클러스터를 구성하고 배포하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.
3.8.1. CPU 파티셔닝 및 성능 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
- CPU 분할은 민감한 워크로드를 일반 작업, 인터럽트, 드라이버 작업 대기열에서 분리하여 성능을 향상시키고 지연 시간을 줄입니다. 다음 섹션에서는 이러한 보조 프로세스에 할당된 CPU를 예약된 것으로 지칭합니다. 하이퍼스레딩이 활성화된 시스템에서는 CPU가 하나의 하이퍼스레드입니다.
- 제한 및 요구사항
운영 체제에는 커널 네트워킹을 포함한 모든 지원 작업을 수행하려면 일정량의 CPU가 필요합니다.
- 사용자 플레인 네트워킹 애플리케이션(DPDK)만 있는 시스템에는 운영 체제와 인프라 구성 요소를 위해 예약된 코어가 최소 하나(활성화된 경우 하이퍼스레드 2개) 필요합니다.
- 하이퍼스레딩이 활성화된 시스템에서는 핵심 형제 스레드가 항상 동일한 CPU 풀에 있어야 합니다.
- 예약 및 분리된 코어 세트에는 모든 CPU 코어가 포함되어야 합니다.
- 각 NUMA 노드의 코어 0은 예약된 CPU 세트에 포함되어야 합니다.
- 저지연 작업에는 인터럽트, 커널 스케줄러 또는 플랫폼의 다른 부분의 영향을 받지 않도록 특별한 구성이 필요합니다. 자세한 내용은 "성과 프로필 만들기"를 참조하세요.
- 엔지니어링 고려 사항
-
OpenShift Container Platform 4.19부터
cgroup v1은
더 이상 지원되지 않으며 제거되었습니다. 이제 모든 워크로드는cgroup v2
와 호환되어야 합니다. 자세한 내용은 Red Hat OpenShift 워크로드 컨텍스트에서 Red Hat Enterprise Linux 9의 변경 사항 (Red Hat Knowledgebase)을 참조하세요. -
필요한 최소 예약 용량(
systemReserved
)은 Red Hat Knowledgebase 솔루션의 지침을 따라 찾을 수 있습니다 . OCP 4 노드에서 시스템에 예약하는 것이 권장되는 CPU 및 메모리 양은 얼마입니까? - 실제 필수 예약된 CPU 용량은 클러스터 구성 및 워크로드 특성에 따라 다릅니다.
- 예약된 CPU 값은 전체 코어(2개의 하이퍼스레드) 정렬로 반올림해야 합니다.
- CPU 파티셔닝이 변경되면 해당 머신 구성 풀에 포함된 노드가 비워지고 재부팅됩니다.
- 예약된 CPU는 OpenShift Container Platform 노드의 할당 가능한 용량에서 제거되므로 Pod 밀도가 감소합니다.
실시간 작업 부하 힌트는 실시간 지원 작업 부하에 대해 활성화되어야 합니다.
-
실시간
workloadHint
설정을 적용하면nohz_full
커널 명령줄 매개변수가 적용되어 고성능 애플리케이션의 성능이 향상됩니다.workloadHint
설정을 적용하면cpu-quota.crio.io: "disable"
주석과 적절한runtimeClassName
값이 없는 격리된 포드나 버스트 가능한 포드는 CRI-O 속도 제한의 대상이 됩니다.workloadHint
매개변수를 설정할 때는 성능 향상과 CRI-O 속도 제한의 잠재적 영향 간의 상충 관계를 알고 있어야 합니다. 필수 포드에 올바르게 주석이 달려 있는지 확인하세요.
-
실시간
- IRQ 친화성 지원이 없는 하드웨어는 분리된 CPU에 영향을 미칩니다. 모든 서버 하드웨어는 IRQ 친화성을 지원해야 하며, 이를 통해 CPU QoS가 보장된 포드가 할당된 CPU를 최대한 활용할 수 있습니다.
-
OVS는 네트워크 트래픽 요구 사항에 맞게
cpuset
항목을 동적으로 관리합니다. 기본 CNI에서 높은 네트워크 처리량을 처리하기 위해 추가 CPU를 예약할 필요가 없습니다. - 클러스터에서 실행되는 작업 부하가 커널 수준 네트워킹을 사용하는 경우 하드웨어가 허용한다면 참여 NIC의 RX/TX 대기열 수를 16 또는 32개로 설정해야 합니다. 기본 대기열 수를 알아두세요. 구성이 없으면 기본 대기열 수는 온라인 CPU당 RX/TX 대기열 1개입니다. 이로 인해 너무 많은 인터럽트가 할당될 수 있습니다.
irdma 커널 모듈은 코어 수가 많은 시스템에서 너무 많은 인터럽트 벡터를 할당하는 결과를 초래할 수 있습니다. 이러한 상황을 방지하기 위해 참조 구성에서는
PerformanceProfile
의 커널 명령줄 인수를 통해 이 커널 모듈이 로드되는 것을 제외합니다. 일반적으로 핵심 작업에는 이 커널 모듈이 필요하지 않습니다.참고일부 드라이버는 대기열 수를 줄인 후에도 인터럽트를 할당 해제하지 않습니다.
-
OpenShift Container Platform 4.19부터
3.8.2. 서비스 메시 링크 복사링크가 클립보드에 복사되었습니다!
- 설명
- 통신사 핵심 클라우드 네이티브 기능(CNF)에는 일반적으로 서비스 메시 구현이 필요합니다. 특정 서비스 메시 기능과 성능 요구 사항은 애플리케이션에 따라 달라집니다. 서비스 메시 구현 및 구성을 선택하는 것은 이 문서의 범위를 벗어납니다. 구현 시 포드 네트워킹에서 발생하는 추가 대기 시간을 포함하여 클러스터 리소스 사용 및 성능에 미치는 서비스 메시의 영향을 고려해야 합니다.
3.8.3. 네트워킹 링크 복사링크가 클립보드에 복사되었습니다!
다음 다이어그램은 통신사 핵심 참조 설계 네트워킹 구성을 설명합니다.
그림 3.2. 통신사 코어 참조 설계 네트워킹 구성
- 이번 릴리스의 새로운 기능
- 포드 수준 본딩으로 통신사 핵심 검증을 확장합니다.
- SR-IOV 운영자에 대해 리소스 인젝터에서 실패한 정책을 실패한 정책으로 이동하는 기능을 지원합니다.
metallb-system
네임스페이스에 사용자 정의 FRRConfiguration
CR이 있는 경우 이를 openshift-network-operator
네임스페이스로 이동해야 합니다.
- 설명
- 클러스터는 듀얼 스택 IP(IPv4 및 IPv6)로 구성되었습니다.
- 검증된 물리적 네트워크 구성은 두 개의 듀얼 포트 NIC로 구성됩니다. 한 NIC는 기본 CNI(OVN-Kubernetes)와 IPVLAN 및 MACVLAN 트래픽에서 공유되고, 두 번째 NIC는 SR-IOV VF 기반 Pod 트래픽에 전담됩니다.
-
두 개의 NIC 포트가 연결된 활성-활성 IEEE 802.3ad LACP 모드에서 Linux 본딩 인터페이스(
bond0
)가 생성됩니다. 상단형 랙 네트워킹 장비는 mLAG(멀티 섀시 링크 집계) 기술을 지원하고 이에 맞게 구성되어야 합니다. -
VLAN 인터페이스는 기본 CNI를 포함하여
bond0
위에 생성됩니다. -
본드 및 VLAN 인터페이스는 설치 과정의 네트워크 구성 단계에서 클러스터 설치 시 생성됩니다. 기본 CNI에서 사용하는
vlan0
VLAN을 제외한 다른 모든 VLAN은 Kubernetes NMstate Operator를 사용하여 2일차 활동 중에 생성할 수 있습니다. - MACVLAN 및 IPVLAN 인터페이스는 해당 CNI를 통해 생성됩니다. 그들은 동일한 기본 인터페이스를 공유하지 않습니다. 자세한 내용은 "클러스터 네트워크 운영자"를 참조하세요.
- SR-IOV VF는 SR-IOV 네트워크 운영자가 관리합니다.
-
LoadBalancer 서비스 뒤에 있는 포드에 대해 일관된 소스 IP 주소를 보장하려면
EgressIP
CR을 구성하고podSelector
매개변수를 지정합니다. 다음을 수행하여 서비스 트래픽 분리를 구현할 수 있습니다.
-
NodeNetworkConfigurationPolicy
CR을 사용하여 노드에서 VLAN 인터페이스와 특정 커널 IP 경로를 구성합니다. -
각 VLAN에 대해 MetalLB
BGPPeer
CR을 생성하여 원격 BGP 라우터와 피어링을 설정합니다. -
선택한
BGPPeer
리소스 목록에 어떤 IP 주소 풀을 광고해야 하는지 지정하기 위해 MetalLBBGPAdvertisement
CR을 정의합니다. 다음 다이어그램은 특정 VLAN 인터페이스를 통해 특정 서비스 IP 주소가 외부에 광고되는 방식을 보여줍니다. 서비스 경로는BGPAdvertisement
CR에 정의되어 있으며IPAddressPool1
및BGPPeer1
필드의 값으로 구성됩니다.
-
그림 3.3. 통신사 코어 참조 설계 MetalLB 서비스 분리
3.8.3.1. CNO(Cluster Network Operator) 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
클러스터 네트워크 운영자(CNO)는 클러스터 설치 중에 기본 OVN-Kubernetes 네트워크 플러그인을 포함한 클러스터 네트워크 구성 요소를 배포하고 관리합니다. CNO를 사용하면 기본 인터페이스 MTU 설정, 포드 이그레스를 위한 노드 라우팅 테이블을 사용하는 OVN 게이트웨이 구성, MACVLAN과 같은 추가 보조 네트워크를 구성할 수 있습니다.
네트워크 트래픽 분리를 지원하기 위해 여러 네트워크 인터페이스가 CNO를 통해 구성됩니다. 이러한 인터페이스로의 트래픽은 NMState Operator를 사용하여 적용되는 정적 경로를 통해 구성됩니다. Pod 트래픽이 올바르게 라우팅되도록 하려면 OVN-K는
routingViaHost
옵션을 활성화하여 구성됩니다. 이 설정은 Pod 송신 트래픽에 대해 OVN이 아닌 커널 라우팅 테이블 및 적용된 정적 경로를 사용합니다.Whereabouts CNI 플러그인은 DHCP 서버를 사용하지 않고 추가 Pod 네트워크 인터페이스에 대한 동적 IPv4 및 IPv6 주소를 제공하는 데 사용됩니다.
- 제한 및 요구사항
- IPv6 지원에는 OVN-Kubernetes가 필요합니다.
- 대규모 MTU 클러스터 지원을 사용하려면 연결된 네트워크 장치를 동일하거나 더 큰 값으로 설정해야 합니다. 최대 8900의 MTU 크기가 지원됩니다.
MACVLAN과 IPVLAN은 동일한 기본 커널 메커니즘, 특히
rx_handler
에 의존하기 때문에 동일한 기본 인터페이스에 함께 위치할 수 없습니다. 이 핸들러를 사용하면 호스트가 패킷을 처리하기 전에 타사 모듈이 들어오는 패킷을 처리할 수 있으며, 네트워크 인터페이스당 하나의 핸들러만 등록될 수 있습니다. MACVLAN과 IPVLAN은 모두 작동하기 위해 각자의rx_handler를
등록해야 하므로 충돌이 발생하고 동일한 인터페이스에 공존할 수 없습니다. 자세한 내용은 소스 코드를 검토하세요.- 대체 NIC 구성으로는 공유 NIC를 여러 개의 NIC로 분할하거나 단일 듀얼 포트 NIC를 사용하는 것이 있지만, 이러한 구성은 테스트 및 검증되지 않았습니다.
- 단일 스택 IP 구성을 사용하는 클러스터는 검증되지 않습니다.
-
Network
CR의reachabilityTotalTimeoutSeconds
매개변수는EgressIP
노드 도달성 검사 총 시간 초과를 초 단위로 구성합니다. 권장 값은1
초입니다. -
Pod 수준 SR-IOV 본딩 모드는
active-backup
으로 설정되어야 하며miimon
의 값도 설정되어야 합니다(100
이 권장됨).
- 엔지니어링 고려 사항
-
Pod 이그레스 트래픽은
routingViaHost
옵션을 사용하는 커널 라우팅 테이블에 의해 처리됩니다. 적절한 정적 경로를 호스트에 구성해야 합니다.
-
Pod 이그레스 트래픽은
3.8.3.2. 로드 밸런서 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
metallb-system
네임스페이스에 사용자 정의 FRRConfiguration
CR이 있는 경우 이를 openshift-network-operator
네임스페이스로 이동해야 합니다.
- 설명
- MetalLB는 표준 라우팅 프로토콜을 사용하는 베어 메탈 Kubernetes 클러스터를 위한 로드 밸런서 구현입니다. Kubernetes 서비스는 클러스터의 호스트 네트워크에도 추가된 외부 IP 주소를 가져올 수 있습니다. MetalLB Operator는 클러스터에서 MetalLB 인스턴스의 수명 주기를 배포하고 관리합니다. 일부 사용 사례에서는 MetalLB에서 사용할 수 없는 기능(상태 저장 부하 분산 등)이 필요할 수 있습니다. 필요한 경우 외부 타사 로드 밸런서를 사용할 수 있습니다. 외부 로드 밸런서의 선택 및 구성은 이 사양의 범위를 벗어납니다. 외부 타사 로드 밸런서를 사용하는 경우 모든 성능 및 리소스 활용 요구 사항이 충족되는지 확인하기 위해 충분한 분석이 통합 작업에 포함되어야 합니다.
- 제한 및 요구사항
- MetalLB에서 상태 저장 로드 밸런싱을 지원하지 않습니다. 워크로드 CNF에 대한 요구 사항인 경우 대체 로드 밸런서 구현을 사용해야 합니다.
- 클러스터의 호스트 네트워크로 클라이언트에서 외부 IP 주소를 라우팅할 수 있는지 확인해야 합니다.
- 엔지니어링 고려 사항
- MetalLB는 통신사 핵심 사용 모델의 BGP 모드에서만 사용됩니다.
-
통신사 코어 사용 모델의 경우 MetalLB는 OVN-Kubernetes 네트워크 플러그인의
ovnKubernetesConfig.gatewayConfig
사양에서routingViaHost=true를
설정한 경우에만 지원됩니다. "클러스터 네트워크 운영자"에서routingViaHost를
참조하세요. MetalLB의 BGP 구성은 네트워크와 피어의 요구 사항에 따라 달라질 것으로 예상됩니다.
- 주소, 집계 길이, 자동 할당 등의 다양한 변수로 주소 풀을 구성할 수 있습니다.
-
MetalLB는 경로를 알리는 데만 BGP를 사용합니다. 이 모드에서는
transmitInterval
및minimumTtl
매개변수만 관련됩니다. BFD 프로필의 다른 매개변수는 기본값에 가깝게 유지되어야 합니다. 값이 짧으면 거짓 부정이 발생하고 성능에 영향을 미칠 수 있기 때문입니다.
3.8.3.3. SR-IOV 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- SR-IOV 운영자에 대해 리소스 인젝터에서 실패한 정책을 실패한 정책으로 이동하는 것을 지원합니다.
- 설명
- SR-IOV를 사용하면 물리적 기능(PF)을 여러 개의 가상 기능(VF)으로 나눌 수 있습니다. 그러면 Pod를 분리한 상태로 유지하면서 더 높은 처리량 성능을 달성하기 위해 VFS를 여러 Pod에 할당할 수 있습니다. SR-IOV Network Operator는 SR-IOV CNI, 네트워크 장치 플러그인 및 SR-IOV 스택의 기타 구성 요소를 프로비저닝하고 관리합니다.
- 제한 및 요구사항
- 특정 네트워크 인터페이스만 지원됩니다. 자세한 내용은 "지원되는 기기"를 참조하세요.
- SR-IOV 및 IOMMU 활성화: SR-IOV 네트워크 운영자는 커널 명령줄에서 IOMMU를 자동으로 활성화합니다.
- SR-IOV VF는 PF에서 링크 상태 업데이트를 수신하지 않습니다. 링크 다운 감지가 필요한 경우 프로토콜 수준에서 수행해야 합니다.
-
MultiNetworkPolicy
CR은netdevice
네트워크에만 적용할 수 있습니다. 이는 구현에서 vfio 인터페이스를 관리할 수 없는 iptables를 사용하기 때문입니다.
- 엔지니어링 고려 사항
-
vfio
모드의 SR-IOV 인터페이스는 일반적으로 처리량 또는 짧은 대기 시간이 필요한 애플리케이션의 추가 보조 네트워크를 활성화하는 데 사용됩니다. -
SriovOperatorConfig
CR은 명시적으로 생성되어야 합니다. 이 CR은 참조 구성 정책에 포함되어 있으므로 초기 배포 중에 생성됩니다. - UEFI 보안 부팅이나 커널 잠금을 통한 펌웨어 업데이트를 지원하지 않는 NIC는 애플리케이션 작업 부하에 필요한 VF(가상 기능) 수를 지원할 수 있도록 충분한 VF를 미리 구성해야 합니다. Mellanox NIC의 경우 SR-IOV 네트워크 운영자에서 Mellanox 공급업체 플러그인을 비활성화해야 합니다. 자세한 내용은 "SR-IOV 네트워크 장치 구성"을 참조하세요.
-
포드가 시작된 후 VF의 MTU 값을 변경하려면
SriovNetworkNodePolicy
MTU 필드를 구성하지 마세요. 대신 Kubernetes NMState Operator를 사용하여 관련 PF의 MTU를 설정하세요.
-
3.8.3.4. NMState Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- Kubernetes NMState Operator는 클러스터 노드 전체에서 상태 기반 네트워크 구성을 수행하기 위한 Kubernetes API를 제공합니다. 보조 인터페이스에서 네트워크 인터페이스 구성, 고정 IP 및 DNS, VLAN, 트렁크, 본딩, 정적 경로, MTU를 활성화하고 보조 인터페이스에서 무차별 모드를 활성화합니다. 클러스터 노드는 각 노드의 네트워크 인터페이스 상태를 API 서버에 정기적으로 보고합니다.
- 제한 및 요구사항
- 해당 없음
- 엔지니어링 고려 사항
-
초기 네트워킹 구성은 설치 CR의
NMStateConfig
콘텐츠를 사용하여 적용됩니다. NMState 연산자는 네트워크 업데이트에 필요할 때만 사용됩니다. -
SR-IOV 가상 기능이 호스트 네트워킹에 사용되는 경우 NMState 연산자(
nodeNetworkConfigurationPolicy
CR을 통해)를 사용하여 VLAN 및 MTU와 같은 VF 인터페이스를 구성합니다.
-
초기 네트워킹 구성은 설치 CR의
3.8.4. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- Cluster Logging Operator를 사용하면 원격 아카이브 및 분석을 위해 노드에서 로그를 수집하고 제공할 수 있습니다. 참조 구성에서는 Kafka를 사용하여 감사 및 인프라 로그를 원격 아카이브로 전송합니다.
- 제한 및 요구사항
- 해당 없음
- 엔지니어링 고려 사항
- 클러스터 CPU 사용 영향은 생성된 로그 수 또는 크기와 구성된 로그 필터링 양을 기반으로 합니다.
- 참조 구성에는 애플리케이션 로그 전달이 포함되어 있지 않습니다. 구성에 애플리케이션 로그를 포함하려면 애플리케이션 로깅 속도를 평가하고 예약된 세트에 충분한 추가 CPU 리소스를 할당해야 합니다.
3.8.5. 전원 관리 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- 성능 프로필을 사용하여 고전력 모드, 저전력 모드 또는 혼합 모드로 클러스터를 구성합니다. 전원 모드를 선택하는 것은 클러스터에서 실행되는 워크로드의 특성, 특히 대기 시간에 얼마나 민감한지에 따라 달라집니다. Pod별 전원 관리 C-states 기능을 사용하여 대기 시간이 짧은 Pod의 최대 대기 시간을 구성합니다.
- 제한 및 요구사항
- 전원 구성은 적절한 BIOS 구성을 사용합니다(예: C 상태 및 P-상태 활성화). 구성은 하드웨어 벤더마다 다릅니다.
- 엔지니어링 고려 사항
- 지연 시간: 지연 시간에 민감한 워크로드가 요구 사항을 충족하도록 하려면 고전력 또는 Pod별 전원 관리 구성이 필요합니다. 포드별 전원 관리 기능은 전용 고정 CPU가 있는 보장된 QoS 포드에만 사용할 수 있습니다.
3.8.6. 스토리지 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
클라우드 네이티브 스토리지 서비스는 OpenShift Data Foundation이나 다른 타사 솔루션을 통해 제공될 수 있습니다.
OpenShift Data Foundation은 컨테이너를 위한 Red Hat Ceph Storage 기반 소프트웨어 정의 스토리지 솔루션입니다. 이 솔루션은 영구적 및 비영구적 데이터 요구 사항에 맞게 동적으로 프로비저닝할 수 있는 블록 스토리지, 파일 시스템 스토리지, 온프레미스 개체 스토리지를 제공합니다. 통신 핵심 애플리케이션에는 영구 스토리지가 필요합니다.
참고모든 저장 데이터가 전송 중에 암호화되지 않을 수도 있습니다. 위험을 줄이려면 스토리지 네트워크를 다른 클러스터 네트워크와 분리합니다. 다른 클러스터 네트워크에서 스토리지 네트워크에 연결할 수 없거나 라우팅할 수 없어야 합니다. 스토리지 네트워크에 직접 연결된 노드만 액세스할 수 있어야 합니다.
3.8.6.1. OpenShift Data Foundation 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 내부 모드와 외부 모드 및 RDS 권장 사항에 대한 설명입니다.
- 설명
OpenShift Data Foundation은 컨테이너를 위한 소프트웨어 정의 스토리지 서비스입니다. OpenShift Data Foundation은 다음 두 가지 모드 중 하나로 배포할 수 있습니다. * 내부 모드: OpenShift Data Foundation 소프트웨어 구성 요소가 다른 컨테이너화된 애플리케이션과 함께 OpenShift Container Platform 클러스터 노드에 직접 소프트웨어 컨테이너로 배포됩니다. * 외부 모드에서는 OpenShift Data Foundation이 전용 스토리지 클러스터에 배포되는데, 이는 일반적으로 Red Hat Enterprise Linux(RHEL)에서 실행되는 별도의 Red Hat Ceph Storage 클러스터입니다. 이러한 스토리지 서비스는 애플리케이션 워크로드 클러스터 외부에서 실행됩니다.
통신사 코어 클러스터의 경우, 외부 모드에서 실행되는 OpenShift Data Foundation 스토리지 서비스가 여러 가지 이유로 스토리지 지원을 제공합니다.
- OpenShift Container Platform과 Ceph 작업 간의 종속성을 분리하면 OpenShift Container Platform과 OpenShift Data Foundation을 독립적으로 업데이트할 수 있습니다.
- 스토리지와 OpenShift 컨테이너 플랫폼 인프라 계층의 운영 기능을 분리하는 것은 통신사 핵심 사용 사례에 대한 일반적인 고객 요구 사항입니다.
- 외부 Red Hat Ceph Storage 클러스터는 동일한 지역에 배포된 여러 OpenShift Container Platform 클러스터에서 재사용될 수 있습니다.
OpenShift Data Foundation은 보조 CNI 네트워크를 사용하여 스토리지 트래픽 분리를 지원합니다.
- 제한 및 요구사항
- IPv4/IPv6 듀얼 스택 네트워킹 환경에서 OpenShift Data Foundation은 IPv4 주소를 사용합니다. 자세한 내용은 IPv6 지원을 참조하세요.
- 엔지니어링 고려 사항
- OpenShift Data Foundation 네트워크 트래픽은 예를 들어 VLAN 격리를 사용하여 전용 네트워크의 다른 트래픽과 격리해야 합니다.
- 충분한 처리량, 대역폭 및 성능 KPI를 보장하기 위해 여러 OpenShift Container Platform 클러스터를 외부 OpenShift Data Foundation 클러스터에 연결하기 전에 작업 부하 요구 사항의 범위를 정해야 합니다.
3.8.6.2. 추가 스토리지 솔루션 링크 복사링크가 클립보드에 복사되었습니다!
다른 스토리지 솔루션을 사용하여 통신사 코어 클러스터에 대한 영구 스토리지를 제공할 수 있습니다. 이러한 솔루션의 구성 및 통합은 참조 설계 사양(RDS)의 범위를 벗어납니다.
스토리지 솔루션을 통신사 핵심 클러스터에 통합하려면 스토리지가 전반적인 성능 및 리소스 사용 요구 사항을 충족하는지 확인하기 위해 적절한 크기 조정 및 성능 분석이 포함되어야 합니다.
3.8.7. 통신사 핵심 배포 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션에서는 Red Hat Advanced Cluster Management(RHACM)를 사용하여 허브 클러스터를 구성하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소와 구성에 대해 설명합니다.
3.8.7.1. Red Hat 고급 클러스터 관리 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 관리형 클러스터에 대한 정책을 관리하고 배포하려면 RHACM 및 PolicyGenerator CR을 사용하는 것이 권장됩니다. 이는 이 목적을 위해 PolicyGenTemplate CR을 사용하는 것을 대체합니다.
- 설명
RHACM은 배포된 클러스터에 대한 MCE(Multi Cluster Engine) 설치 및 지속적인 GitOps ZTP 수명 주기 관리를 제공합니다. 유지 관리 기간 동안 클러스터에
정책
사용자 정의 리소스(CR)를 적용하여 클러스터 구성과 업그레이드를 선언적으로 관리합니다.TALM에서 관리하는 RHACM 정책 컨트롤러를 사용하여 정책을 적용합니다. 구성, 업그레이드 및 클러스터 상태는 정책 컨트롤러를 통해 관리됩니다.
관리형 클러스터를 설치할 때 RHACM은 사용자 정의 디스크 분할, 역할 할당, 머신 구성 풀 할당을 지원하기 위해 개별 노드에 레이블과 초기 점화 구성을 적용합니다. 이러한 구성은
SiteConfig
또는ClusterInstance
CR을 사용하여 정의합니다.- 제한 및 요구사항
- 허브 클러스터 크기 조정은 클러스터 크기 조정 에서 설명합니다.
- RHACM 확장 한도는 성능 및 확장성에 설명되어 있습니다.
- 엔지니어링 고려 사항
- 설치, 사이트 또는 배포별로 고유한 콘텐츠가 있는 여러 클러스터를 관리하는 경우 RHACM 허브 템플릿을 사용하는 것이 좋습니다. RHACM 허브 템플릿을 사용하면 설치별로 고유한 값을 제공하는 동시에 클러스터에 일관된 정책 세트를 적용할 수 있습니다.
3.8.7.2. 토폴로지 인식 라이프사이클 관리자 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
TALM은 허브 클러스터에서만 실행되는 연산자입니다. TALM은 클러스터 및 운영자 업그레이드, 구성 등의 변경 사항이 네트워크의 관리형 클러스터에 어떻게 적용되는지 관리합니다. TALM의 핵심 기능은 다음과 같습니다.
- 클러스터 정책에 정의된 대로 클러스터 구성 및 업그레이드(OpenShift Container Platform 및 Operator)에 대한 순차적 업데이트를 제공합니다.
- 클러스터 업데이트의 지연된 적용을 제공합니다.
- 사용자가 구성할 수 있는 일괄 처리로 클러스터 세트에 대한 정책 업데이트의 점진적인 롤아웃을 지원합니다.
-
클러스터에
ztp-done
또는 비슷한 사용자 정의 레이블을 추가하여 클러스터별 작업이 가능합니다.
- 제한 및 요구사항
- 400개 배치로 동시 클러스터 배포 지원
- 엔지니어링 고려 사항
-
TALM은 클러스터를 처음 설치하는 동안
ran.openshift.io/ztp-deploy-wave
주석이 있는 정책만 적용합니다. -
모든 정책은 사용자가 생성한
ClusterGroupUpgrade
CR의 제어 하에 TALM을 통해 수정될 수 있습니다.
-
TALM은 클러스터를 처음 설치하는 동안
3.8.7.3. GitOps Operator 및 ZTP 플러그인 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
GitOps Operator는 클러스터 배포 및 구성을 관리하기 위한 GitOps 기반 인프라를 제공합니다. 클러스터 정의와 구성은 Git 저장소에서 관리됩니다.
ZTP 플러그인은
SiteConfig
CR에서설치
CR을 생성하고 RHACMPolicyGenerator
CR을 기반으로 정책에 구성 CR을 자동으로 래핑하는 기능을 지원합니다.SiteConfig Operator는
ClusterInstance
CR에서설치
CR을 생성하는 데 대한 지원을 개선했습니다.중요ZTP 플러그인 방식을 사용하는
SiteConfig
사용자 정의 리소스보다ClusterInstance
CR을 사용하여 클러스터를 설치하는 것이 더 좋습니다.SiteConfig
,ClusterInstance
,PolicyGenerator
,PolicyGenTemplate
및 지원 참조 CR과 같은 모든 필수 아티팩트를 포함하여 릴리스 버전에 따라 Git 저장소를 구성해야 합니다. 이를 통해 여러 버전의 OpenShift Container Platform과 구성 버전을 클러스터에 동시에 배포하고 관리할 수 있으며, 업그레이드를 통해서도 관리할 수 있습니다.권장되는 Git 구조는 참조 CR을 고객이나 파트너가 제공한 콘텐츠와 별도의 디렉토리에 보관합니다. 즉, 기존 콘텐츠를 덮어쓰기만 하면 참조 업데이트를 가져올 수 있습니다. 고객 또는 파트너가 제공한 CR은 생성된 구성 정책에 쉽게 포함할 수 있도록 참조 CR과 병렬 디렉토리에 제공될 수 있습니다.
- 제한 및 요구사항
- 각 ArgoCD 애플리케이션은 최대 1000개의 노드를 지원합니다. 여러 ArgoCD 애플리케이션을 사용하면 단일 허브 클러스터에서 지원하는 최대 클러스터 수를 달성할 수 있습니다.
SiteConfig
CR은extraManifests.searchPaths
필드를 사용하여 참조 매니페스트를 참조해야 합니다.참고OpenShift Container Platform 4.15부터
spec.extraManifestPath
필드는 더 이상 사용되지 않습니다.
- 엔지니어링 고려 사항
클러스터 업그레이드 유지 관리 기간 동안
MachineConfigPool
(MCP
) CR일시 중지
필드를 true로 설정하고maxUnavailable
필드를 허용 가능한 최대 값으로 설정합니다. 이렇게 하면 업그레이드하는 동안 여러 클러스터 노드가 재부팅되는 것을 방지할 수 있어 전체 업그레이드 시간이 단축됩니다.mcp
CR의 일시 중지를 해제하면 모든 구성 변경 사항이 한 번의 재부팅으로 적용됩니다.참고설치 중에 사용자 정의
MCP
CR을 일시 중지하고maxUnavailable을
100%로 설정하여 설치 시간을 개선할 수 있습니다.-
콘텐츠를 업데이트할 때 혼란이나 의도치 않은 덮어쓰기를 방지하려면 core-overlay 아래의
reference-crs/
디렉터리와 git의 추가 매니페스트에 사용자 지정 CR에 대해 고유하고 구별 가능한 이름을 사용해야 합니다. -
SiteConfig
CR을 사용하면 여러 추가 경로가 허용됩니다. 여러 디렉토리 경로에서 파일 이름이 겹치는 경우 디렉토리 순서 목록에서 마지막으로 발견된 파일이 우선권을 갖습니다.
3.8.7.4. 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
클러스터 모니터링 운영자(CMO)는 OpenShift Container Platform에 기본적으로 포함되어 있으며 플랫폼 구성 요소와 선택적으로 사용자 프로젝트에 대한 모니터링(메트릭, 대시보드, 알림)을 제공합니다.
기본 로그 보존 기간, 사용자 정의 알림 규칙 등을 사용자 정의할 수 있습니다.
업스트림 Kubernetes와 cAdvisor를 기반으로 하는 Pod CPU 및 메모리 메트릭의 기본 처리 방식은 메트릭 정확도보다 오래된 데이터를 선호하는 균형을 이룹니다. 이로 인해 보고가 급증하여 사용자가 지정한 임계값에 따라 잘못된 알림이 생성될 수 있습니다.
OpenShift Container Platform은 이러한 동작으로 인해 영향을 받지 않는 추가적인 Pod CPU 및 메모리 메트릭 세트를 생성하는 옵트인 전용 서비스 모니터 기능을 지원합니다. 자세한 내용은 Red Hat Knowledgebase 솔루션 Dedicated Service Monitors - Questions and Answers를 참조하세요.
기본 구성 외에도 다음 메트릭이 통신사 코어 클러스터에 대해 구성되어야 합니다.
- 사용자 워크로드에 대한 Pod CPU 및 메모리 메트릭 및 경고
- 제한 및 요구사항
- Pod 메트릭을 정확하게 표현하려면 전용 서비스 모니터 기능을 활성화해야 합니다.
- 엔지니어링 고려 사항
- Prometheus 보존 기간은 사용자가 지정합니다. 사용된 값은 CPU 및 스토리지 리소스에 대해 클러스터의 기록 데이터를 유지 관리하기 위한 운영 요구 사항 간의 절충입니다. 보존 기간이 길어지면 스토리지의 필요성이 증가하고 데이터 인덱싱을 관리하기 위해 추가 CPU가 필요합니다.
3.8.8. 스케줄링 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
스케줄러는 지정된 워크로드에 적합한 노드를 선택하는 클러스터 전체 구성 요소입니다. 이는 플랫폼의 핵심 부분이며 일반적인 배포 시나리오에서 특정 구성이 필요하지 않습니다. 그러나 다음 섹션에서 설명하는 몇 가지 특정 사용 사례가 있습니다.
NUMA 리소스 Operator를 통해 NUMA 인식 스케줄링을 활성화할 수 있습니다. 자세한 내용은 "NUMA 인식 워크로드 스케줄링"을 참조하세요.
- 제한 및 요구사항
기본 스케줄러는 워크로드의 NUMA 현지성을 인식하지 못합니다. 작업자 노드에서 사용 가능한 모든 리소스의 합계만 알고 있습니다. 이로 인해 토폴로지 관리자 정책이 단일 누마 노드 또는 제한으로 설정된 노드에 예약된 경우 작업 부하가 거부될 수 있습니다. 자세한 내용은 "토폴로지 관리자 정책"을 참조하세요.
예를 들어 Pod에서 6개의 CPU를 요청하고 NUMA 노드당 CPU가 4개인 빈 노드로 예약되는 것이 좋습니다. 노드에 할당 가능한 총 용량은 8개의 CPU입니다. 스케줄러는 빈 노드에 포드를 배치합니다. 각 NUMA 노드에서 사용 가능한 CPU가 4개만 있으므로 노드 로컬 승인이 실패합니다.
-
다중 NUMA 노드가 있는 모든 클러스터는 NUMA 리소스 연산자를 사용해야 합니다. 자세한 내용은 "NUMA 리소스 운영자 설치"를 참조하세요.
KubeletConfig
CR의machineConfigPoolSelector
필드를 사용하여 NUMA 정렬 스케줄링이 필요한 모든 노드를 선택합니다. - 모든 머신 구성 풀은 일관된 하드웨어 구성을 가져야 합니다. 예를 들어, 모든 노드는 동일한 NUMA 영역 수를 가져야 합니다.
- 엔지니어링 고려 사항
- Pod에 올바른 스케줄링 및 격리를 위한 주석이 필요할 수 있습니다. 주석에 대한 자세한 내용은 "CPU 파티셔닝 및 성능 튜닝"을 참조하세요.
-
SriovNetworkNodePolicy
CR의 excludeTopology 필드를 사용하여 스케줄링 중에 SR-IOV 가상 함수 NUMA 친화성이 무시되도록 구성할 수 있습니다.
3.8.9. 노드 구성 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 제한 및 요구사항
추가 커널 모듈을 분석하여 CPU 부하, 시스템 성능, KPI 달성 능력에 미치는 영향을 파악합니다.
Expand 표 3.1. 추가 커널 모듈 기능 설명 추가 커널 모듈
MachineConfig
CR을 사용하여 다음 커널 모듈을 설치하면 CNF에 확장된 커널 기능을 제공할 수 있습니다.- sctp
- ip_gre
- ip6_tables
- ip6t_REJECT
- ip6table_filter
- ip6table_mangle
- iptable_filter
- iptable_mangle
- iptable_nat
- xt_multiport
- xt_owner
- xt_REDIRECT
- xt_statistic
- xt_TCPMSS
컨테이너 마운트 네임스페이스 숨기기
CPU 사용량을 줄이려면 kubelet 하우스키핑 및 퇴거 모니터링 빈도를 줄이세요. 시스템 마운트 스캐닝 오버헤드를 줄이기 위해 kubelet/CRI-O에서 볼 수 있는 컨테이너 마운트 네임스페이스를 만듭니다.
Kdump 활성화
선택 구성(기본적으로 활성화됨)
3.8.10. 호스트 펌웨어 및 부트로더 구성 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 엔지니어링 고려 사항
보안 부팅을 활성화하는 것이 권장되는 구성입니다.
참고보안 부팅이 활성화되면 서명된 커널 모듈만 커널에 의해 로드됩니다. 트리 외부 드라이버는 지원되지 않습니다.
3.8.11. 연결이 끊긴 환경 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
통신 핵심 클러스터는 인터넷에 직접 액세스하지 않고 네트워크에 설치해야 합니다. 클러스터를 설치, 구성 및 운영하는 데 필요한 모든 컨테이너 이미지는 연결이 끊긴 레지스트리에서 사용할 수 있어야 합니다. 여기에는 OpenShift Container Platform 이미지, Day 2 OLM Operator 이미지, 애플리케이션 워크로드 이미지가 포함됩니다. 연결되지 않은 환경을 사용하면 다음을 포함한 여러 가지 이점이 있습니다.
- 보안 - 클러스터에 대한 액세스 제한
- 큐레이트된 콘텐츠 - 레지스트리는 클러스터에 대한 큐레이트되고 승인된 업데이트를 기반으로 채워집니다.
- 제한 및 요구사항
-
모든 사용자 정의
CatalogSource
리소스에는 고유한 이름이 필요합니다. 기본 카탈로그 이름을 재사용하지 마십시오.
-
모든 사용자 정의
- 엔지니어링 고려 사항
- 유효한 시간 소스는 클러스터 설치의 일부로 구성되어야 합니다.
3.8.12. 에이전트 기반 설치 프로그램 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
통신사 핵심 클러스터는 에이전트 기반 설치 프로그램을 사용하여 설치할 수 있습니다. 이 방법을 사용하면 설치 관리를 위한 추가 서버나 VM이 필요 없이 베어 메탈 서버에 OpenShift Container Platform을 설치할 수 있습니다. 에이전트 기반 설치 프로그램은 모든 시스템(예: 노트북)에서 실행되어 ISO 설치 이미지를 생성할 수 있습니다. ISO는 클러스터 감독자 노드의 설치 미디어로 사용됩니다. 네트워크로 연결되어 슈퍼바이저 노드의 API 인터페이스에 연결된 모든 시스템에서 에이전트 기반 설치 프로그램을 사용하여 진행 상황을 모니터링할 수 있습니다.
에이전트 기반 설치 프로그램은 다음을 지원합니다.
- 선언적 CR에서 설치.
- 연결이 끊긴 환경에 설치.
- 예를 들어, 배스천 노드를 사용하여 설치를 지원하는 추가 서버를 사용하지 않고 설치합니다.
- 제한 및 요구사항
- 연결 해제된 설치에는 모든 필수 콘텐츠가 미러링되어 설치된 호스트에서 접근 가능한 레지스트리가 필요합니다.
- 엔지니어링 고려 사항
- 네트워크 구성은 설치 중에 NMState 구성으로 적용되어야 합니다. NMState Operator를 사용한 2일차 네트워킹 구성은 지원되지 않습니다.
3.8.13. 보안 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
통신사 고객은 보안을 중시하며 여러 공격 벡터에 대비해 클러스터를 강화해야 합니다. OpenShift Container Platform에는 클러스터 보안을 담당하는 단일 구성 요소나 기능이 없습니다. 아래에는 통신사 핵심 RDS에 포함된 사용 모델에 대한 다양한 보안 지향 기능과 구성이 설명되어 있습니다.
-
SecurityContextConstraints(SCC) : 모든 워크로드 포드는
restricted-v2
또는제한된
SCC로 실행해야 합니다. -
Seccomp : 모든 Pod는
RuntimeDefault
(또는 더 강력한) seccomp 프로필로 실행해야 합니다. - rootless DPDK Pod: 많은 DPDK(사용자 플레인 네트워킹) CNF는 root 권한으로 Pod를 실행해야 합니다. 이 기능을 사용하면 root 권한 없이도 준수 DPDK Pod를 실행할 수 있습니다. rootless DPDK Pod는 DPDK 애플리케이션에서 커널로 트래픽을 삽입하는 rootless Pod에 탭 장치를 생성합니다.
- 스토리지: 스토리지 네트워크를 다른 클러스터 네트워크로 분리하고 라우팅할 수 없어야 합니다. 자세한 내용은 "스토리지" 섹션을 참조하십시오.
OpenShift Container Platform 클러스터 노드에서 사용자 정의 nftable 방화벽 규칙을 구현하는 데 지원되는 방법에 대해서는 Red Hat Knowledgebase 솔루션 문서 OpenShift의 사용자 정의 nftable 방화벽 규칙을 참조하세요. 이 문서는 OpenShift Container Platform 환경에서 네트워크 보안 정책을 관리하는 클러스터 관리자를 대상으로 합니다.
이 방법을 배포하기 전에 다음을 포함하여 운영상의 영향을 신중하게 고려하는 것이 중요합니다.
- 조기 적용 : 규칙은 네트워크가 완전히 작동하기 전, 부팅 시에 적용됩니다. 부팅 과정에서 필요한 필수 서비스가 규칙으로 인해 실수로 차단되지 않도록 주의하세요.
- 잘못된 구성으로 인한 위험 : 사용자 정의 규칙의 오류로 인해 의도치 않은 결과가 발생할 수 있으며, 잠재적으로 성능 저하가 발생하거나 정상적인 트래픽이 차단되거나 노드가 격리될 수 있습니다. 기본 클러스터에 배포하기 전에 비운영 환경에서 규칙을 철저히 테스트하세요.
- 외부 엔드포인트 : OpenShift Container Platform이 작동하려면 외부 엔드포인트에 액세스해야 합니다. 방화벽 허용 목록에 대한 자세한 내용은 "OpenShift Container Platform에 대한 방화벽 구성"을 참조하세요. 클러스터 노드가 해당 엔드포인트에 액세스할 수 있는지 확인하세요.
노드 재부팅 : 노드 중단 정책이 구성되어 있지 않은 경우, 필요한 방화벽 설정과 함께
MachineConfig
CR을 적용하면 노드가 재부팅됩니다. 이러한 영향을 인지하고 그에 따라 유지 관리 기간을 예약하세요. 자세한 내용은 "노드 중단 정책을 사용하여 머신 구성 변경으로 인한 중단을 최소화하기"를 참조하세요.참고노드 중단 정책은 OpenShift Container Platform 4.17 이상에서 사용할 수 있습니다.
- 네트워크 흐름 매트릭스 : 수신 트래픽 관리에 대한 자세한 내용은 OpenShift Container Platform 네트워크 흐름 매트릭스를 참조하세요. 네트워크 보안을 강화하기 위해 필수적인 흐름에만 유입 트래픽을 제한할 수 있습니다. 매트릭스는 기본 클러스터 서비스에 대한 통찰력을 제공하지만 Day-2 운영자가 생성한 트래픽은 제외합니다.
- 클러스터 버전 업데이트 및 업그레이드 : OpenShift Container Platform 클러스터를 업데이트하거나 업그레이드할 때는 주의하세요. 최근 플랫폼의 방화벽 요구 사항이 변경되어 네트워크 포트 권한을 조정해야 할 수도 있습니다. 문서에서는 지침을 제공하지만, 이러한 요구 사항은 시간이 지남에 따라 변경될 수 있다는 점에 유의하세요. 중단을 최소화하려면 프로덕션에 적용하기 전에 스테이징 환경에서 모든 업데이트나 업그레이드를 테스트해야 합니다. 이를 통해 방화벽 구성 변경과 관련된 잠재적인 호환성 문제를 식별하고 해결할 수 있습니다.
-
SecurityContextConstraints(SCC) : 모든 워크로드 포드는
- 제한 및 요구사항
루트리스 DPDK 포드에는 다음과 같은 추가 구성이 필요합니다.
-
탭 플러그인에 대한
container_t
SELinux 컨텍스트를 구성합니다. -
클러스터 호스트에 대해
container_use_devices
SELinux 부울을 활성화합니다.
-
탭 플러그인에 대한
- 엔지니어링 고려 사항
-
루트 없는 DPDK 포드 지원을 위해 호스트에서 SELinux
container_use_devices
부울 값을 활성화하여 탭 장치를 생성할 수 있도록 합니다. 이는 허용 가능한 보안 위험을 초래합니다.
-
루트 없는 DPDK 포드 지원을 위해 호스트에서 SELinux
3.8.14. 확장성 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
- "제한 및 요구 사항"에 설명된 대로 클러스터를 확장합니다. 워크로드 확장은 "애플리케이션 워크로드"에 설명되어 있습니다.
- 제한 및 요구사항
- 클러스터는 최소 120개 노드까지 확장 가능합니다.
3.9. 통신사 코어 참조 구성 CR 링크 복사링크가 클립보드에 복사되었습니다!
다음 CR(사용자 정의 리소스)을 사용하여 telco core 프로필로 OpenShift Container Platform 클러스터를 구성하고 배포합니다. 달리 표시되지 않는 한 모든 특정 사용 모델에 사용되는 공통 기준을 형성하려면 CR을 사용합니다.
3.9.1. telco 코어 참조 설계 구성 CR 추출 링크 복사링크가 클립보드에 복사되었습니다!
telco-core-rds-rhel9
컨테이너 이미지에서 telco core 프로필의 전체 CR(사용자 정의 리소스) 세트를 추출할 수 있습니다. 컨테이너 이미지에는 telco core 프로필에 대한 필수 CR과 선택적 CR이 모두 있습니다.
사전 요구 사항
-
podman
을 설치했습니다.
프로세스
다음 명령을 실행하여 자격 증명을 사용하여 컨테이너 이미지 레지스트리에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
telco-core-rds-rhel9
컨테이너 이미지에서 콘텐츠를 추출합니다.mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.19 | base64 -d | tar xv -C out
$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.19 | base64 -d | tar xv -C out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
out
디렉토리는 다음과 같은 디렉토리 구조를 가지고 있습니다. 다음 명령을 실행하면out/telco-core-rds/
디렉토리에서 Telco core CR을 볼 수 있습니다.tree -L 4
$ tree -L 4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
3.9.2. 통신사 코어 참조 구성과 클러스터 비교 링크 복사링크가 클립보드에 복사되었습니다!
통신사 코어 클러스터를 배포한 후 cluster-compare
플러그인을 사용하여 클러스터가 통신사 코어 참조 설계 사양(RDS)을 준수하는지 평가할 수 있습니다. 클러스터 비교
플러그인은 OpenShift CLI( oc
) 플러그인입니다. 이 플러그인은 텔코 코어 참조 구성을 사용하여 텔코 코어 사용자 정의 리소스(CR)로 클러스터를 검증합니다.
Telco Core에 대한 플러그인별 참조 구성은 Telco Core CR과 함께 컨테이너 이미지에 패키징되어 있습니다.
클러스터 비교
플러그인에 대한 자세한 내용은 "클러스터 비교 플러그인 이해"를 참조하세요.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
registry.redhat.io
컨테이너 이미지 레지스트리에 액세스할 수 있는 자격 증명이 있습니다. -
클러스터 비교
플러그인을 설치했습니다.
프로세스
다음 명령을 실행하여 자격 증명을 사용하여 컨테이너 이미지 레지스트리에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
telco-core-rds-rhel9
컨테이너 이미지에서 콘텐츠를 추출합니다.mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.19 | base64 -d | tar xv -C out
$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.19 | base64 -d | tar xv -C out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하면
out/telco-core-rds/configuration/reference-crs-kube-compare
디렉토리에서 참조 구성을 볼 수 있습니다.tree -L 2
$ tree -L 2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터 구성을 통신사 코어 참조 구성과 비교하세요.
oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml
$ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 비교 중인 CR입니다. 이 플러그인은 각 CR을 해당 템플릿과 다르게 표시합니다.
- 2
- 비교를 위한 CR과 일치하는 템플릿입니다.
- 3
- Linux diff 형식의 출력은 템플릿과 클러스터 CR의 차이점을 보여줍니다.
- 4
- 플러그인이 각 CR에 대한 줄 차이를 보고한 후, 차이점 요약이 보고됩니다.
- 5
- 해당 템플릿과의 차이점을 비교한 CR의 수입니다.
- 6
- 참조 구성에는 표현되었지만 라이브 클러스터에는 누락된 CR의 수입니다.
- 7
- 참조 구성에 표현되었지만 라이브 클러스터에는 없는 CR 목록입니다.
- 8
- 참조 구성의 해당 템플릿과 일치하지 않는 CR입니다.
- 9
- 메타데이터 해시는 참조 구성을 식별합니다.
- 10
- 패치된 CR 목록입니다.
3.9.3. 노드 구성 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
추가 커널 모듈 |
| 선택 사항입니다. 컨트롤 플레인 노드에 대한 커널 모듈을 구성합니다. | 없음 |
추가 커널 모듈 |
| 선택 사항입니다. 작업자 노드에서 SCTP 커널 모듈을 로드합니다. | 없음 |
추가 커널 모듈 |
| 선택 사항입니다. 작업자 노드에 대한 커널 모듈을 구성합니다. | 없음 |
컨테이너 마운트 네임스페이스 숨기기 |
| 컨트롤 플레인 노드에서 kubelet과 CRI-O 간에 컨테이너별 마운트를 공유하기 위해 마운트 네임스페이스를 구성합니다. | 없음 |
컨테이너 마운트 네임스페이스 숨기기 |
| 작업자 노드에서 kubelet과 CRI-O 간에 컨테이너별 마운트를 공유하기 위해 마운트 네임스페이스를 구성합니다. | 없음 |
kdump 활성화 |
| 마스터 노드에서 kdump 충돌 보고를 구성합니다. | 없음 |
kdump 활성화 |
| 작업자 노드에서 kdump 충돌 보고를 구성합니다. | 없음 |
3.9.4. 클러스터 인프라 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
클러스터 로깅 |
| 지정된 서비스 계정으로 로그 전달 인스턴스를 구성하고 구성이 유효한지 확인합니다. | 제공됨 |
클러스터 로깅 |
| 클러스터 로깅 네임스페이스를 구성합니다. | 제공됨 |
클러스터 로깅 |
| openshift-logging 네임스페이스에서 Operator 그룹을 생성하여 Cluster Logging Operator가 리소스를 감시하고 관리할 수 있습니다. | 제공됨 |
클러스터 로깅 |
| 클러스터 로깅 서비스 계정을 구성합니다. | 제공됨 |
클러스터 로깅 |
| collect-audit-logs 클러스터 역할을 logs 수집기 서비스 계정에 부여합니다. | 제공됨 |
클러스터 로깅 |
| 수집기 서비스 계정에서 인프라 리소스에서 로그를 수집할 수 있습니다. | 제공됨 |
클러스터 로깅 |
| 설치 계획에 대한 수동 승인을 사용하여 Cluster Logging Operator에 대한 서브스크립션 리소스를 생성합니다. | 제공됨 |
연결이 끊긴 구성 |
| 연결이 끊긴 Red Hat Operator 카탈로그를 정의합니다. | 없음 |
연결이 끊긴 구성 |
| 연결이 끊긴 레지스트리의 미러링된 저장소 다이제스트 목록을 정의합니다. | 없음 |
연결이 끊긴 구성 |
| 모든 기본 소스를 비활성화하는 OperatorHub 구성을 정의합니다. | 없음 |
모니터링 및 관찰 기능 |
| Prometheus 및 Alertmanager에 대한 스토리지 및 보존 구성. | 제공됨 |
전원 관리 |
| 선택한 노드의 성능 최적화를 위해 CPU 격리, hugepages 구성 및 워크로드 힌트를 지정하여 성능 프로필 리소스를 정의합니다. | 없음 |
3.9.5. 리소스 튜닝 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
시스템 예약 용량 |
| 선택 사항입니다. kubelet을 구성하여 컨트롤 플레인 노드 풀에 예약된 리소스를 자동으로 조정합니다. | 제공됨 |
3.9.6. 네트워킹 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
기준 |
| 호스트를 통한 라우팅과 같은 OVN Kubernetes 설정을 지정하여 기본 클러스터 네트워크를 구성합니다. 또한 사용자 정의 CNI 구성을 포함하여 추가 네트워크의 정의를 허용하고 여러 네트워크에서 네트워크 정책에 MultiNetworkPolicy CR을 사용할 수 있습니다. | 없음 |
기준 |
| 선택 사항입니다. 노드 선택기 및 CNI 구성과 같은 네트워크 구성 세부 정보를 지정하는 NetworkAttachmentDefinition 리소스를 정의합니다. | 제공됨 |
로드 밸런서 |
| 지정된 범위에서 IP의 동적 할당에 대해 자동 할당이 활성화된 IP 주소 풀을 관리하도록 MetalLB를 구성합니다. | 없음 |
로드 밸런서 |
| 보다 빠른 네트워크 오류 감지 및 로드 밸런싱 장애 조치를 위해 사용자 지정 간격, 감지 승수 및 모드를 사용하여 BFD(전방향 전달 감지)를 구성합니다. | 없음 |
로드 밸런서 |
| MetalLB에 대한 BGP 광고 리소스를 정의하여 IP 주소 풀이 BGP 피어에 광고되는 방법을 지정합니다. 이를 통해 트래픽 라우팅 및 공지를 세밀하게 제어할 수 있습니다. | 없음 |
로드 밸런서 |
| MetalLB에서 BGP 피어를 정의하고 동적 라우팅을 위한 BGP 인접을 나타냅니다. | 없음 |
로드 밸런서 |
| MetalLB 커뮤니티를 정의합니다. 이 커뮤니티는 이름이 지정된 리소스 아래에 하나 이상의 BGP 커뮤니티를 그룹화합니다. 커뮤니티는 BGP 알림에 적용하여 라우팅 정책을 제어하고 트래픽 라우팅을 변경할 수 있습니다. | 제공됨 |
로드 밸런서 |
| 클러스터에서 MetalLB 리소스를 정의합니다. | 없음 |
로드 밸런서 |
| 클러스터에서 metallb-system 네임스페이스를 정의합니다. | 없음 |
로드 밸런서 |
| MetalLB Operator의 Operator group을 정의합니다. | 없음 |
로드 밸런서 |
| 설치 계획에 대한 수동 승인을 사용하여 MetalLB Operator에 대한 서브스크립션 리소스를 생성합니다. | 없음 |
Multus - rootless DPDK Pod의 경우 Tap CNI |
| 작업자 노드에서 탭 CNI 플러그인에 대한 SELinux 부울을 설정하는 MachineConfig 리소스를 구성합니다. | 제공됨 |
NMState Operator |
| NMState Operator에서 노드 네트워크 구성을 관리하는 데 사용하는 NMState 리소스를 정의합니다. | 없음 |
NMState Operator |
| NMState Operator 네임스페이스를 생성합니다. | 없음 |
NMState Operator |
| openshift-nmstate 네임스페이스에 Operator group을 생성하여 NMState Operator에서 리소스를 감시하고 관리할 수 있습니다. | 없음 |
NMState Operator |
| OLM을 통해 관리되는 NMState Operator에 대한 구독을 생성합니다. | 없음 |
SR-IOV 네트워크 Operator |
| 네트워크 기능, IP 주소 관리(ipam), 관련 네트워크 네임스페이스 및 리소스를 지정하는 SR-IOV 네트워크를 정의합니다. | 없음 |
SR-IOV 네트워크 Operator |
| 특정 노드의 SR-IOV 장치에 대한 네트워크 정책을 구성합니다. 여기에는 장치 선택, VF 할당(numVfs), 노드별 설정(nodeSelector) 및 우선 순위의 사용자 정의가 포함됩니다. | 없음 |
SR-IOV 네트워크 Operator |
| SR-IOV Operator에 대한 다양한 설정을 구성합니다. 여기에는 인젝터 및 Operator 웹훅 활성화, Pod 드레이닝 비활성화, 구성 데몬에 대한 노드 선택기 정의 등이 포함됩니다. | 없음 |
SR-IOV 네트워크 Operator |
| OLM을 통해 관리되는 SR-IOV 네트워크 운영자에 대한 구독을 생성합니다. | 없음 |
SR-IOV 네트워크 Operator |
| SR-IOV 네트워크 운영자 구독 네임스페이스를 생성합니다. | 없음 |
SR-IOV 네트워크 Operator |
| SR-IOV 네트워크 운영자에 대한 운영자 그룹을 생성하여 대상 네임스페이스의 리소스를 감시하고 관리할 수 있도록 합니다. | 없음 |
3.9.7. 참조 CR 예약 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
NUMA 인식 스케줄러 |
| NUMA 리소스 운영자를 활성화하여 워크로드를 특정 NUMA 노드 구성에 맞춥니다. 다중 NUMA 노드가 있는 클러스터에 필요합니다. | 없음 |
NUMA 인식 스케줄러 |
| OLM을 통해 관리되는 NUMA 리소스 운영자에 대한 구독을 만듭니다. 다중 NUMA 노드가 있는 클러스터에 필요합니다. | 없음 |
NUMA 인식 스케줄러 |
| NUMA 리소스 운영자 구독 네임스페이스를 생성합니다. 다중 NUMA 노드가 있는 클러스터에 필요합니다. | 없음 |
NUMA 인식 스케줄러 |
| numaresources-operator 네임스페이스에 Operator 그룹을 생성하여 NUMA Resources Operator가 리소스를 감시하고 관리할 수 있도록 합니다. 다중 NUMA 노드가 있는 클러스터에 필요합니다. | 없음 |
NUMA 인식 스케줄러 |
| 노드 전체에 걸쳐 NUMA 인식 포드 스케줄링을 처리할 수 있는 클러스터 내 토폴로지 인식 스케줄러를 구성합니다. | 없음 |
NUMA 인식 스케줄러 |
| 작업 부하에 대해 제어 평면 노드를 예약 불가능으로 구성합니다. | 없음 |
3.9.8. 스토리지 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
외부 ODF 구성 |
| openshift-storage 네임스페이스의 외부 Ceph 클러스터에 대한 base64로 인코딩된 구성 데이터를 포함하는 비밀 리소스를 정의합니다. | 없음 |
외부 ODF 구성 |
| 클러스터가 외부 스토리지 백엔드를 사용하도록 구성하는 OpenShift Container Storage(OCS) 스토리지 리소스를 정의합니다. | 없음 |
외부 ODF 구성 |
| OpenShift Data Foundation Operator에 대한 모니터링되는 openshift-storage 네임스페이스를 생성합니다. | 없음 |
외부 ODF 구성 |
| openshift-storage 네임스페이스에 Operator 그룹을 생성하여 OpenShift Data Foundation Operator가 리소스를 감시하고 관리할 수 있도록 합니다. | 없음 |
3.10. Telco 코어 참조 구성 소프트웨어 사양 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Telco Core 4.19 솔루션은 OpenShift Container Platform 클러스터에 대해 다음 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.
Component | 소프트웨어 버전 |
---|---|
Red Hat 고급 클러스터 관리(RHACM) | 2.13 |
Red Hat OpenShift GitOps | 1.16 |
Cluster Logging Operator | 6.2 |
OpenShift Data Foundation | 4.19 |
SR-IOV 네트워크 Operator | 4.19 |
MetalLB | 4.19 |
NMState Operator | 4.19 |
NUMA 인식 스케줄러 | 4.19 |
4장. Telco RAN DU 참조 설계 사양 링크 복사링크가 클립보드에 복사되었습니다!
통신사 RAN DU 참조 설계 사양(RDS)은 무선 접속 네트워크(RAN)에서 5G 워크로드를 호스팅하기 위해 상용 하드웨어에서 실행되는 클러스터에 대한 구성을 설명합니다. Telco RAN DU 프로필을 실행하는 클러스터에 대해 안정적이고 반복 가능한 성능을 얻기 위해 권장, 테스트 및 지원되는 구성을 캡처합니다.
사용 모델과 시스템 수준 정보를 사용하여 관리형 단일 노드 OpenShift 클러스터에 대한 통신사 RAN DU 워크로드, 클러스터 리소스 및 최소 하드웨어 사양을 계획합니다.
개별 구성 요소에 대한 구체적인 제한, 요구 사항 및 엔지니어링 고려 사항은 각 섹션에 설명되어 있습니다.
4.1. 통신사 RAN DU 5G 배포를 위한 참조 설계 사양 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat과 인증 파트너는 OpenShift Container Platform 4.19 클러스터에서 통신 애플리케이션을 실행하는 데 필요한 네트워킹 및 운영 기능에 대한 심층적인 기술 전문 지식과 지원을 제공합니다.
Red Hat의 통신 파트너는 엔터프라이즈 5G 솔루션을 위해 대규모로 복제할 수 있는 잘 통합되고 테스트되고 안정적인 환경이 필요합니다. Telco 코어 및 RAN DU 참조 설계 사양(RDS)은 특정 OpenShift Container Platform 버전을 기반으로 하는 권장 솔루션 아키텍처를 간략하게 설명합니다. 각 RDS는 telco 코어 및 RAN DU 모델을 사용하기 위한 테스트되고 검증된 플랫폼 구성을 설명합니다. RDS는 통신 5G 코어 및 RAN DU에 대한 중요한 KPI 세트를 정의하여 애플리케이션을 실행할 때 최적의 환경을 보장합니다. RDS는 높은 심각도의 에스컬레이션을 최소화하고 애플리케이션 안정성을 향상시킵니다.
5G 사용 사례는 계속 증가하고 있으며 워크로드는 지속적으로 변하고 있습니다. Red Hat은 telco 코어 및 RAN DU RDS를 통해 고객 및 파트너 피드백을 기반으로 진화하는 요구 사항을 지원하기 위해 최선을 다하고 있습니다.
ARM 기반 플랫폼에 대한 지원은 현재 OpenShift Container Platform 4.19의 개발자 미리 보기 기능입니다. 모든 정보는 공개 시 변경될 수 있습니다. 자세한 내용은 다음 Red Hat 지식 기반 문서를 참조하세요: OpenShift 4.19 Telco RDS(개발자 미리 보기)에서 ARM 플랫폼 하드웨어를 사용하는 방법
참조 구성에는 먼 가장자리 클러스터와 허브 클러스터 구성 요소의 구성이 포함됩니다.
이 문서의 참조 구성은 다음 이미지에 표시된 것처럼 중앙에서 관리되는 허브 클러스터 인프라를 사용하여 배포됩니다.
그림 4.1. 통신사 RAN DU 배포 아키텍처
4.2. 참조 설계 범위 링크 복사링크가 클립보드에 복사되었습니다!
통신사 코어, 통신사 RAN 및 통신사 허브 참조 설계 사양(RDS)은 통신사 코어 및 통신사 RAN 프로필을 실행하는 클러스터에 대해 안정적이고 반복 가능한 성능을 얻기 위해 권장, 테스트 및 지원되는 구성을 담고 있습니다.
각 RDS에는 클러스터가 개별 프로필을 실행할 수 있도록 설계 및 검증되는 릴리스된 기능 및 지원되는 구성이 포함되어 있습니다. 이 구성은 기능 및 KPI 대상을 충족하는 기본 OpenShift Container Platform 설치를 제공합니다. 각 RDS는 개별 구성에 대해 예상되는 변형도 설명합니다. 각 RDS의 검증에는 긴 기간과 대규모 테스트가 포함되어 있습니다.
검증된 참조 구성은 OpenShift Container Platform의 각 주요 Y-stream 릴리스에 대해 업데이트됩니다. Z-stream 패치 릴리스는 참조 구성에 대해 주기적으로 다시 테스트됩니다.
4.3. 참조 설계의 편차 링크 복사링크가 클립보드에 복사되었습니다!
검증된 통신 코어, 통신 RAN DU 및 통신 허브 참조 설계 사양(RDS)에서 벗어나면 변경하는 특정 구성 요소나 기능 외에도 상당한 영향을 미칠 수 있습니다. 편차는 전체 솔루션의 맥락에서 분석 및 엔지니어링이 필요합니다.
RDS의 모든 편차는 명확한 작업 추적 정보로 분석 및 문서화되어야 합니다. 실사실은 파트너로부터 참조 설계에 맞춰 편차를 가져오는 방법을 이해할 것으로 예상됩니다. 이를 위해서는 파트너사가 Red Hat과 협력하여 플랫폼에서 최상의 결과를 얻을 수 있도록 활용 사례를 제공하기 위해 추가 리소스를 제공해야 할 수 있습니다. 이는 솔루션의 지원 가능성과 Red Hat 및 파트너 간의 조정을 보장하는 데 매우 중요합니다.
RDS의 편차는 다음과 같은 결과 중 일부 또는 모두를 가질 수 있습니다.
- 문제를 해결하는 데 시간이 더 걸릴 수 있습니다.
- 프로젝트 서비스 수준 계약(SLA), 프로젝트 기한, 최종 공급자 성능 요구 사항이 누락될 위험이 있습니다.
승인되지 않은 편차는 행정 수준에서 에스컬레이션이 필요할 수 있습니다.
참고Red Hat은 파트너 참여 우선 순위에 따라 편차 요청의 우선 순위를 지정합니다.
4.4. RAN DU 사용 모델에 대한 엔지니어링 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
RAN DU 사용 모델은 RAN 분산 단위(DU) 워크로드를 호스팅하기 위해 상용 하드웨어에서 실행되는 OpenShift 컨테이너 플랫폼 클러스터를 구성합니다. 모델 및 시스템 수준의 고려 사항은 아래와 같습니다. 개별 구성 요소에 대한 구체적인 제한, 요구 사항 및 엔지니어링 고려 사항은 이후 섹션에서 자세히 설명합니다.
통신사 RAN DU RDS KPI 테스트 결과에 대한 자세한 내용은 통신사 RAN DU 4.19 참조 설계 사양 KPI 테스트 결과를 참조하세요. 이 정보는 고객 및 파트너사만 사용할 수 있습니다.
- 클러스터 토폴로지
RAN DU 워크로드에 권장되는 토폴로지는 단일 노드 OpenShift입니다. DU 워크로드는 필요에 따라 3노드 컴팩트 클러스터, 고가용성(3개 제어 평면 + n개 작업자 노드) 또는 SNO+1과 같은 다른 클러스터 토폴로지에서 실행될 수 있습니다. SNO+1 토폴로지보다는 여러 개의 SNO 클러스터 또는 고가용성 3노드 컴팩트 클러스터가 권장됩니다.
원격 작업자 노드(RWN) 클러스터 토폴로지는 이 참조 설계 사양에 권장되거나 포함되지 않습니다. RAN DU와 같이 서비스 수준 계약 요구 사항이 높은 작업 부하의 경우 다음과 같은 단점으로 인해 RWN이 고려 대상에서 제외됩니다.
- 이미지 기반 업그레이드에 대한 지원이 없고, 더 빠른 업그레이드와 롤백 기능 등 해당 기능이 제공하는 이점도 없습니다.
- 2일차 운영자에 대한 업데이트는 롤링 업데이트를 수행할 수 없는 모든 RWN에 동시에 적용됩니다.
- 제어 평면이 손실되는 경우(재난 시나리오) 해당 제어 평면이 서비스를 제공하는 사이트 수가 많아져 전체 서비스 가용성에 훨씬 더 큰 영향을 미칩니다.
- 모니터링 유예 기간과 허용 시간 초과를 초과하는 기간 동안 RWN과 제어 평면 간의 네트워크 연결이 끊어지면 Pod가 추방되고 서비스가 중단될 수 있습니다.
- 컨테이너 이미지 사전 캐싱을 지원하지 않습니다.
- 작업 친화도의 추가적인 복잡성.
- 워크로드
- DU 워크로드는 Telco RAN DU 애플리케이션 워크로드 에 설명되어 있습니다.
- DU 워커 노드는 최대 성능을 위해 호스트 펌웨어가 조정된 Intel 3세대 Xeon(IceLake) 2.20GHz 이상입니다.
- Resources
- 애플리케이션 워크로드와 OpenShift Container Platform Pod를 포함하여 시스템에서 실행 가능한 Pod의 최대 수는 120개입니다.
- 리소스 사용률
OpenShift Container Platform 리소스 활용도는 다음과 같은 애플리케이션 워크로드 특성 등 여러 요인에 따라 달라집니다.
- Pod 수
- 프로브 유형 및 빈도
- 커널 네트워킹을 사용한 기본 또는 보조 CNI의 메시징 속도
- API 액세스 속도
- 로깅 속도
- 스토리지 IOPS
리소스 활용도는 다음과 같이 구성된 클러스터에 대해 측정됩니다.
- 클러스터는 단일 노드 OpenShift가 설치된 단일 호스트입니다.
- 클러스터는 "참조 애플리케이션 워크로드 특성"에 설명된 대표적인 애플리케이션 워크로드를 실행합니다.
- 클러스터는 "허브 클러스터 관리 특성"에 자세히 설명된 제약 조건에 따라 관리됩니다.
- 사용 모델 구성에서 "선택 사항"으로 표시된 구성 요소는 포함되지 않습니다.
참고이러한 기준을 충족하지 않는 RAN DU RDS 범위를 벗어나는 구성에는 리소스 활용도와 KPI 목표 달성 능력에 미치는 영향을 확인하기 위한 추가 분석이 필요합니다. 이러한 요구 사항을 충족하려면 추가 클러스터 리소스를 할당해야 할 수도 있습니다.
- 참조 애플리케이션 워크로드 특성
- 관리 및 제어 기능을 포함하여 vRAN 애플리케이션에 15개의 포드와 30개의 컨테이너를 사용합니다.
-
포드당 평균 2개의
ConfigMap
과 4개의Secret
CR을 사용합니다. - 10초 미만의 빈도로 최대 10 exec 프로브 사용
kube-apiserver의 증분 애플리케이션 로드는 클러스터 플랫폼 사용량의 10% 이하입니다.
참고플랫폼 지표에서 CPU 로드를 추출할 수 있습니다. 예를 들면 다음과 같습니다.
query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
$ query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 애플리케이션 로그는 플랫폼 로그 수집기에 의해 수집되지 않습니다.
- 기본 CNI의 총 트래픽은 8Mbps 미만입니다.
- hub 클러스터 관리 특성
RHACM은 권장되는 클러스터 관리 솔루션이며 다음과 같은 제한 사항에 따라 구성됩니다.
- 최대 10개의 RHACM 구성 정책을 사용하세요. 이 중에는 Red Hat에서 제공하는 정책 5개와 사용자 정의 구성 정책 최대 5개가 포함되며, 평가 간격은 최소 10분입니다.
- 클러스터 정책에서 관리되는 클러스터 템플릿을 최소 수(최대 10개)로 사용합니다. 허브 측 템플릿을 사용하세요.
-
policyController
를 제외한 RHACM 애드온을 비활성화하고 기본 구성으로 관찰성을 구성합니다.
다음 표는 참조 애플리케이션 부하 하의 리소스 활용도를 설명합니다.
Expand 표 4.1. 참조 애플리케이션 부하 하의 리소스 활용 지표 제한 참고 OpenShift 플랫폼 CPU 사용량
4000mc 미만 – 2코어(4HT)
플랫폼 CPU는 각 예약된 코어의 하이퍼스레드 모두를 포함하여 예약된 코어에 고정됩니다. 이 시스템은 주기적인 시스템 작업과 급증을 허용하기 위해 정상 상태에서 3개의 CPU(3000mc)로 설계되었습니다.
OpenShift 플랫폼 메모리
16G 미만
4.5. Telco RAN DU 애플리케이션 워크로드 링크 복사링크가 클립보드에 복사되었습니다!
다음 요구 사항과 제한 사항을 따르는 RAN DU 애플리케이션을 개발합니다.
- 설명 및 제한 사항
- Kubernetes를 위한 Red Hat 모범 사례 의 최신 버전을 준수하는 클라우드 기반 네트워크 기능(CNF)을 개발합니다.
- 고성능 네트워킹을 위해 SR-IOV를 사용합니다.
exec 프로브는 아껴서 사용하고 다른 적합한 옵션을 사용할 수 없는 경우에만 사용하세요.
-
CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오. 다른 프로브 구현(예:
httpGet
또는tcpSocket
)을 사용합니다. exec 프로브를 사용해야 하는 경우 exec 프로브 빈도 및 수량을 제한합니다. 최대 exec 프로브 수는 10초 미만으로 유지해야 하며 빈도를 10초 미만으로 설정하지 않아야 합니다. 실행 프로브는 프로세스 포킹이 필요하기 때문에 다른 프로브 유형에 비해 관리 코어에서 CPU 사용량이 훨씬 더 높습니다.
참고시작 프로브에는 지속적인 상태 작업 중에 최소한의 리소스가 필요합니다. exec 프로브의 제한은 주로 liveness 및 readiness 프로브에 적용됩니다.
-
CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오. 다른 프로브 구현(예:
참고이 사양에 설명된 참조 DU 애플리케이션 워크로드의 차원에 맞는 테스트 워크로드는 openshift-kni/du-test-workloads 에서 찾을 수 있습니다.
4.6. Telco RAN DU 참조 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션에서는 RAN DU 워크로드를 실행하기 위해 클러스터를 구성하고 배포하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.
그림 4.2. Telco RAN DU 참조 구성 요소
통신사 RAN DU 프로필에 지정되지 않은 추가 구성 요소가 작업 부하 애플리케이션에 할당된 CPU 리소스에 영향을 미치지 않는지 확인하세요.
트리 부족 드라이버는 지원되지 않습니다. 5G RAN 애플리케이션 구성 요소는 RAN DU 프로필에 포함되지 않으며 애플리케이션에 할당된 리소스(CPU)에 맞춰 엔지니어링되어야 합니다.
4.6.1. 호스트 펌웨어 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
초기 클러스터 배포 시 최적의 성능을 위해 호스트 펌웨어 설정을 조정합니다. 자세한 내용은 "vDU 애플리케이션 워크로드에 권장되는 단일 노드 OpenShift 클러스터 구성"을 참조하세요. 초기 배포 중에 호스트 펌웨어에 튜닝 설정을 적용합니다. 자세한 내용은 "GitOps ZTP를 사용하여 호스트 펌웨어 설정 관리"를 참조하세요. 관리형 클러스터 호스트 펌웨어 설정은
ClusterInstance
CR 및 GitOps ZTP를 사용하여 관리형 클러스터를 배포할 때 생성되는 개별BareMetalHost
사용자 지정 리소스(CR)로 허브 클러스터에서 사용할 수 있습니다.참고제공된 참조
example-sno.yaml
CR을 기반으로ClusterInstance
CR을 만듭니다.- 제한 및 요구사항
- 호스트 펌웨어 설정에서 하이퍼스레딩을 활성화해야 합니다.
- 엔지니어링 고려 사항
- 최대 성능을 위해 모든 펌웨어 설정을 조정하세요.
- 모든 설정은 전력 절감을 목적으로 하지 않는 한 최대 성능을 위한 것으로 예상됩니다.
- 필요에 따라 성능을 희생하고 전력을 절감하기 위해 호스트 펌웨어를 조정할 수 있습니다.
- 보안 부팅을 활성화합니다. 보안 부팅이 활성화되면 서명된 커널 모듈만 커널에 의해 로드됩니다. 트리 외부 드라이버는 지원되지 않습니다.
4.6.2. CPU 파티셔닝 및 성능 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
-
RAN DU 사용 모델에는 저지연 성능을 위한
PerformanceProfile
CR을 사용한 클러스터 성능 튜닝이 포함됩니다. RAN DU 사용 사례에서는 클러스터를 저지연 성능에 맞게 조정해야 합니다. 노드 튜닝 연산자는PerformanceProfile
CR을 조정합니다.PerformanceProfile
CR을 사용한 노드 튜닝에 대한 자세한 내용은 "성능 프로필을 사용하여 낮은 지연 시간을 위한 노드 튜닝"을 참조하세요. - 제한 및 요구사항
Node Tuning Operator는
PerformanceProfile
CR을 사용하여 클러스터를 구성합니다. 통신사 RAN DU 프로필PerformanceProfile
CR에서 다음 설정을 구성해야 합니다.다음 CPU 중 하나에 대해 4개 이상의 예약된
CPU 세트를
설정합니다. 이는 4개의 하이퍼 스레드(2개의 코어)와 같습니다.- 최대 성능을 위해 조정된 호스트 펌웨어가 있는 Intel 3세대 Xeon(IceLake) 2.20GHz 이상 CPU
AMD EPYC Zen 4 CPU(Genoa, Bergamo)
참고AMD EPYC Zen 4 CPU(제노아, 베르가모)가 완벽하게 지원됩니다. 전력 소비량 평가가 진행 중입니다. 성능에 미치는 잠재적 영향을 파악하기 위해 포드별 전원 관리 등의 기능을 평가하는 것이 좋습니다.
-
포함된 각 코어에 대해 하이퍼스레드 형제를 모두 포함하도록 예약된
cpuset을
설정합니다. 예약되지 않은 코어는 워크로드 예약에 할당 가능한 CPU로 사용할 수 있습니다. - 하이퍼스레드 형제가 예약된 코어와 격리된 코어에 분할되지 않도록 합니다.
- 예약되고 격리된 CPU에 CPU의 모든 코어에 대한 모든 스레드가 포함되어 있는지 확인하세요.
- 예약된 CPU 세트의 각 NUMA 노드에 Core 0을 포함합니다.
- 대규모 페이지 크기를 1G로 설정합니다.
- 기본적으로 관리 워크로드 파티션의 일부로 구성된 OpenShift Container Platform 포드만 예약된 코어에 고정합니다.
-
하드웨어 공급업체가 권장하는 경우
hardwareTuning
섹션을 사용하여 예약되고 격리된 CPU에 대한 최대 CPU 주파수를 설정합니다.
- 엔지니어링 고려 사항
- 모든 성능 지표를 충족하려면 RT 커널을 사용해야 합니다. 필요한 경우 성능에 영향을 미치는 비 RT 커널을 사용할 수 있습니다.
- 구성하는 대규모 페이지의 수는 애플리케이션 작업 부하 요구 사항에 따라 달라집니다. 이 매개변수의 변형은 예상되고 허용됩니다.
- 선택한 하드웨어 및 시스템에서 사용 중인 추가 구성 요소를 기반으로 예약 및 격리된 CPU 세트 구성에서 변동이 예상됩니다. 변화는 여전히 지정된 한도를 충족해야 합니다.
- IRQ 친화성 지원이 없는 하드웨어는 분리된 CPU에 영향을 미칩니다. 전체 CPU QoS가 보장된 포드가 할당된 CPU를 최대한 활용할 수 있도록 하려면 서버의 모든 하드웨어가 IRQ 친화성을 지원해야 합니다.
-
배포 중에
cpuPartitioningMode를
AllNodes
로 설정하여 워크로드 분할을 활성화하는 경우PerformanceProfile
CR을 사용하여 운영 체제, 인터럽트 및 OpenShift Container Platform 포드를 지원하기에 충분한 CPU를 할당해야 합니다. -
참조 성능 프로필에는
vfio_pci
에 대한 추가 커널 인수 설정이 포함되어 있습니다. 이러한 주장은 FEC 가속기와 같은 장치를 지원하기 위해 포함되었습니다. 업무에 필요하지 않다면 생략할 수 있습니다.
4.6.3. PTP Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- PTP 일반 클럭을 위한 듀얼 포트 NIC가 활성화되었습니다.
- PTP 이벤트 REST API v1 및 이벤트 소비자 애플리케이션 사이드카 지원이 제거되었습니다.
- 이제 T-GM에서는 최대 3개의 Westport 채널 NIC 구성이 지원됩니다.
- 설명
-
GPS를 이용한 그랜드마스터 클록(T-GM) 지원, 일반 클록(OC), 경계 클록(T-BC), 이중 경계 클록, 고가용성(HA) 및 HTTP를 통한 선택적
빠른
이벤트 알림과 같은 기능을 갖춘 RAN DU 사용 사례에 대한 PTPConfig CR을 사용하여 클러스터 노드에서 PTP를 구성합니다. PTP는 RAN 환경에서 정확한 타이밍과 안정성을 보장합니다. - 제한 및 요구사항
- 듀얼 NIC 및 HA가 있는 노드의 경우 경계 클록이 2개로 제한됨
- T-GM의 경우 3개의 Westport 채널 NIC 구성으로 제한됨
- 엔지니어링 고려 사항
- RAN DU RDS 구성은 일반 클록, 경계 클록, 그랜드마스터 클록 및 고가용성 듀얼 NIC 경계 클록에 대해 제공됩니다.
-
PTP 빠른 이벤트 알림은
ConfigMap
CR을 사용하여 구독자 세부 정보를 유지합니다. - O-RAN 사양에 설명된 계층적 이벤트 구독은 PTP 이벤트에서 지원되지 않습니다.
- PTP 빠른 이벤트 REST API v1의 지원이 종료되었습니다.
4.6.4. SR-IOV Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 설명
-
SR-IOV Operator는 SR-IOV CNI 및 장치 플러그인을 프로비저닝하고 구성합니다.
netdevice
(커널 VF)와vfio
(DPDK) 장치는 모두 RAN DU 사용 모델에 지원되고 적용할 수 있습니다. - 제한 및 요구사항
- OpenShift Container Platform에서 지원되는 장치를 사용하세요. 자세한 내용은 "지원되는 기기"를 참조하세요.
- 호스트 펌웨어 설정에서 SR-IOV 및 IOMMU 활성화: SR-IOV 네트워크 운영자는 커널 명령줄에서 자동으로 IOMMU를 활성화합니다.
- SR-IOV VF는 PF에서 링크 상태 업데이트를 수신하지 않습니다. 링크 다운 감지가 필요한 경우 프로토콜 수준에서 이를 구성해야 합니다.
- 엔지니어링 고려 사항
-
vfio
드라이버 유형의 SR-IOV 인터페이스는 일반적으로 높은 처리량 또는 짧은 대기 시간이 필요한 애플리케이션의 보조 네트워크를 활성화하는 데 사용됩니다. -
SriovNetwork
및SriovNetworkNodePolicy
고객 리소스 (CR)의 구성과 수에 대한 고객의 변화가 예상됩니다. -
IOMMU 커널 명령줄 설정은 설치 시
MachineConfig
CR에 적용됩니다. 이렇게 하면SriovOperator
CR에서 노드를 추가할 때 노드가 재부팅되지 않습니다. - 노드를 병렬로 드레이닝하는 SR-IOV 지원은 단일 노드 OpenShift 클러스터에는 적용되지 않습니다.
-
배포에
SriovOperatorConfig
CR을 포함해야 합니다. CR은 자동으로 생성되지 않습니다. 이 CR은 초기 배포 중에 적용되는 참조 구성 정책에 포함됩니다. - 워크로드를 특정 노드로 고정하거나 제한하는 시나리오에서는 SR-IOV 병렬 노드 드레이닝 기능으로 인해 Pod 일정이 변경되지 않습니다. 이러한 시나리오에서 SR-IOV Operator는 병렬 노드 드레이닝 기능을 비활성화합니다.
- 애플리케이션 워크로드에 필요한 VF 수를 지원하기 위해 보안 부팅 또는 커널 잠금을 통해 충분한 VF(가상 기능)에서 펌웨어 업데이트를 지원하지 않는 NIC를 미리 구성해야 합니다. Mellanox NIC의 경우 SR-IOV Network Operator에서 Mellanox 벤더 플러그인을 비활성화해야 합니다. 자세한 내용은 "보안 부팅이 활성화된 경우 Mellanox 카드에서 SR-IOV 네트워크 운영자 구성"을 참조하세요.
Pod가 시작된 후 가상 함수의 MTU 값을 변경하려면
SriovNetworkNodePolicy
CR에서 MTU 필드를 구성하지 마십시오. 대신 Network Manager를 구성하거나 사용자 지정systemd
스크립트를 사용하여 물리적 기능의 MTU를 적절한 값으로 설정합니다. 예를 들면 다음과 같습니다.ip link set dev <physical_function> mtu 9000
# ip link set dev <physical_function> mtu 9000
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
4.6.5. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- 로깅을 사용하여 원격 분석을 위해 far edge 노드에서 로그를 수집합니다. 권장되는 로그 수집기는 Vector입니다.
- 엔지니어링 고려 사항
- 예를 들어, 인프라 및 감사 로그 이외의 로그를 처리하려면 추가 로깅 속도를 기반으로 하는 추가 CPU 및 네트워크 대역폭이 필요합니다.
- OpenShift Container Platform 4.14부터 Vector는 참조 로그 수집기입니다. RAN 사용 모델에서 fluentd 사용은 더 이상 사용되지 않습니다.
4.6.6. SRIOV-FEC Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- SRIOV-FEC Operator는 FEC 액셀러레이터 하드웨어를 지원하는 선택적 타사 Certified Operator입니다.
- 제한 및 요구사항
FEC Operator v2.7.0부터 다음을 수행합니다.
- 보안 부팅 지원
-
PF를 위한 VFIO 드라이버에는 Pod에 삽입되는
vfio
-token
- 엔지니어링 고려 사항
- SRIOV-FEC Operator는 분리된 CPU 세트의 CPU 코어를 사용합니다.
- 예를 들어 검증 정책을 확장하여 FEC 준비 상태를 사전 점검의 일부로 검증할 수 있습니다.
4.6.7. 라이프사이클 에이전트 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- Lifecycle Agent는 단일 노드 OpenShift 클러스터의 이미지 기반 업그레이드를 위한 로컬 라이프사이클 관리 서비스를 제공합니다. 이미지 기반 업그레이드는 단일 노드 OpenShift 클러스터에 권장되는 업그레이드 방법입니다.
- 제한 및 요구사항
- Lifecycle Agent는 추가 작업자가 있는 다중 노드 클러스터 또는 단일 노드 OpenShift 클러스터에는 적용되지 않습니다.
- Lifecycle Agent에는 클러스터를 설치할 때 생성하는 영구 볼륨이 필요합니다.
파티션 요구 사항에 대한 자세한 내용은 "GitOps ZTP를 사용할 때 ostree stateroots 간에 공유 컨테이너 디렉터리 구성"을 참조하세요.
4.6.8. Local Storage Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
-
Local Storage Operator를 사용하여 애플리케이션에서
PVC
리소스로 사용할 수 있는 영구 볼륨을 생성할 수 있습니다. 생성하는PV
리소스의 수 및 유형은 요구 사항에 따라 다릅니다. - 엔지니어링 고려 사항
-
PV
를 생성하기 전에PV
CR에 대한 백업 스토리지를 생성합니다. 파티션, 로컬 볼륨, LVM 볼륨 또는 전체 디스크일 수 있습니다. -
각 장치에 액세스하는 데 사용되는 하드웨어 경로에서
LocalVolume
CR의 장치 목록을 참조하여 디스크 및 파티션의 올바른 할당(예:/dev/disk/by-path/<id
> )을 확인합니다. 논리 이름(예:/dev/sda
)은 노드를 재부팅해도 일관성이 보장되지 않습니다.
-
4.6.9. 논리 볼륨 관리자 스토리지 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
-
LVM(Logical Volume Manager) 스토리지는 선택적 구성 요소입니다. 애플리케이션에서 PVC(영구 볼륨 클레임) 리소스로 사용할 수 있는 로컬 장치에서 논리 볼륨을 생성하여 블록 및 파일 스토리지에 대한 동적 프로비저닝을 제공합니다. 볼륨 확장 및 스냅샷도 가능합니다. 구성의 예는
StorageLVMCluster.yaml
파일이 있는 RDS에 제공됩니다. - 제한 및 요구사항
- 단일 노드 OpenShift 클러스터에서 영구 스토리지는 둘 다 아닌 LVMS 또는 로컬 스토리지에서 제공해야 합니다.
- 볼륨 스냅샷은 참조 구성에서 제외됩니다.
- 엔지니어링 고려 사항
- LVM 스토리지는 RAN DU 사용 사례의 로컬 스토리지 구현으로 사용할 수 있습니다. LVM 스토리지를 스토리지 솔루션으로 사용하면 Local Storage Operator가 교체되고 필요한 CPU가 플랫폼 오버헤드로 관리 파티션에 할당됩니다. 참조 구성에는 이러한 스토리지 솔루션 중 하나가 포함되어야 하지만 둘 다 포함되지는 않습니다.
- 스토리지 요구 사항에 충분한 디스크 또는 파티션을 사용할 수 있는지 확인합니다.
4.6.10. 워크로드 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
-
워크로드 파티셔닝은 DU 프로파일의 일부인 OpenShift 플랫폼과 Day 2 Operator Pod를 예약된 cpuset 에 고정하고 노드 회계에서 예약된 CPU를 제거합니다. 이렇게 하면 사용자 워크로드에서 예약되지 않은 모든 CPU 코어를 사용할 수 있습니다. 이렇게 하면 사용자 워크로드에서 예약되지 않은 모든 CPU 코어를 사용할 수 있습니다. 워크로드 파티셔닝은 설치 매개변수에 설정된 기능을 통해 활성화됩니다:
cpu CryostatingMode: AllNodes
. 관리 파티션 코어 세트는PerformanceProfile
CR에서 구성한 예약된 CPU 세트로 설정됩니다. - 제한 및 요구사항
-
Pod
를 관리 파티션에 적용할 수 있도록네임스페이스
및 Pod CR에 주석을 달 수 있어야 합니다. - CPU 제한이 있는 Pod는 파티션에 할당할 수 없습니다. 변경으로 Pod QoS를 변경할 수 있기 때문입니다.
- 관리 파티션에 할당할 수 있는 최소 CPU 수에 대한 자세한 내용은 Node Tuning Operator 를 참조하십시오.
-
- 엔지니어링 고려 사항
- 워크로드 파티셔닝은 모든 관리 Pod를 예약된 코어에 고정합니다. 워크로드 시작, 노드 재부팅 또는 기타 시스템 이벤트가 발생할 때 발생하는 CPU 사용 급증을 고려하여 예약된 세트에 코어 수를 할당해야 합니다.
4.6.11. 클러스터 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- 클러스터 기능 기능을 사용하여 비활성화할 수 있는 구성 요소의 전체 목록은 "클러스터 기능"을 참조하세요.
- 제한 및 요구사항
- 설치 관리자가 프로비저닝한 설치 방법에서는 클러스터 기능을 사용할 수 없습니다.
다음 표에는 필요한 플랫폼 튜닝 구성이 나열되어 있습니다.
기능 | 설명 |
---|---|
선택적 클러스터 기능 제거 | 단일 노드 OpenShift 클러스터에서만 선택적 클러스터 Operator를 비활성화하여 OpenShift Container Platform 풋프린트를 줄입니다.
|
클러스터 모니터링 구성 | 다음을 수행하여 공간 절약을 위해 모니터링 스택을 구성합니다.
|
네트워킹 진단 비활성화 | 필요하지 않으므로 단일 노드 OpenShift에 대한 네트워킹 진단을 비활성화합니다. |
단일 OperatorHub 카탈로그 소스 구성 |
RAN DU 배포에 필요한 Operator만 포함하는 단일 카탈로그 소스를 사용하도록 클러스터를 구성합니다. 각 카탈로그 소스는 클러스터에서 CPU 사용을 늘립니다. 단일 |
콘솔 운영자 비활성화 |
콘솔이 비활성화된 상태로 클러스터가 배포된 경우 |
- 엔지니어링 고려 사항
- OpenShift Container Platform 4.19부터 cgroup v1은 더 이상 지원되지 않으며 제거되었습니다. 이제 모든 워크로드는 cgroup v2와 호환되어야 합니다. 자세한 내용은 Red Hat OpenShift 워크로드 컨텍스트에서 Red Hat Enterprise Linux 9의 변경 사항을 참조하세요.
4.6.12. 머신 구성 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 제한 및 요구사항
-
CRI-O 삭제 비활성화
MachineConfig
CR은 정의된 유지 관리 창의 예약된 유지 관리 기간 외에는 디스크의 이미지가 정적이라고 가정합니다. 이미지가 정적임을 확인하려면 PodimagePullPolicy
필드를Always
로 설정하지 마십시오. - 달리 명시하지 않는 한, 이 표의 구성 CR은 필수 구성 요소입니다.
-
CRI-O 삭제 비활성화
기능 | 설명 |
---|---|
컨테이너 런타임 |
모든 노드 역할에 대해 컨테이너 런타임을 |
Kubelet 구성 및 컨테이너 마운트 네임스페이스 숨기기 | kubelet 하우스키핑 및 퇴거 모니터링 빈도를 줄여 CPU 사용량을 줄입니다. |
SCTP | 선택 구성(기본적으로 활성화됨) |
Kdump | 선택적 설정(기본적으로 사용)을 사용하면 커널 패닉이 발생할 때 kdump에서 디버그 정보를 캡처할 수 있습니다. kdump를 활성화하는 참조 CR은 참조 구성에 포함된 드라이버 및 커널 모듈 세트를 기반으로 메모리 예약이 늘어납니다. |
CRI-O 제거 비활성화 | 부정확한 종료 후 CRI-O 이미지 캐시의 자동 삭제를 비활성화합니다. |
SR-IOV 관련 커널 인수 | 커널 명령줄에 추가 SR-IOV 관련 인수를 포함합니다. |
RCU Normal 설정 |
시스템 시작이 완료된 후 |
일회성 시간 동기화 | 제어 평면 또는 작업자 노드에 대한 일회성 NTP 시스템 시간 동기화 작업을 실행합니다. |
4.7. 통신사 RAN DU 배포 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
다음 섹션에서는 RHACM으로 허브 클러스터를 구성하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소와 구성에 대해 설명합니다.
4.7.1. Red Hat 고급 클러스터 관리 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
RHACM은 배포된 클러스터에 대한 MCE(Multi Cluster Engine) 설치 및 지속적인 라이프사이클 관리 기능을 제공합니다. 유지 관리 기간 동안 클러스터에
정책
사용자 정의 리소스(CR)를 적용하여 클러스터 구성과 업그레이드를 선언적으로 관리합니다.RHACM은 다음과 같은 기능을 제공합니다.
- RHACM의 MCE 구성 요소를 사용하여 클러스터의 제로 터치 프로비저닝(ZTP)을 수행합니다.
- RHACM 정책 컨트롤러를 통한 구성, 업그레이드 및 클러스터 상태.
-
관리형 클러스터 설치 중에 RHACM은
ClusterInstance
CR을 통해 구성된 대로 개별 노드에 레이블을 적용할 수 있습니다.
단일 노드 OpenShift 클러스터 설치에 권장되는 방법은 MCE에서 사용 가능한 이미지 기반 설치 방식으로, 클러스터 정의를 위해
ClusterInstance
CR을 사용하는 것입니다.단일 노드 OpenShift 클러스터 업그레이드에 권장되는 방법은 이미지 기반 업그레이드 방법입니다.
- 제한 및 요구사항
-
단일 허브 클러스터는 5
Policy
CR이 각 클러스터에 바인딩된 최대 3500개의 배포된 단일 노드 OpenShift 클러스터를 지원합니다.
-
단일 허브 클러스터는 5
- 엔지니어링 고려 사항
- RHACM 정책 허브 측 템플릿을 사용하여 클러스터 구성을 보다 효과적으로 확장할 수 있습니다. 단일 그룹 정책 또는 그룹과 클러스터별 값이 템플릿으로 대체되는 일반 그룹 정책 수를 사용하여 정책 수를 크게 줄일 수 있습니다.
-
클러스터별 구성: 관리 클러스터에는 일반적으로 개별 클러스터에 고유한 몇 가지 구성 값이 있습니다. 이러한 구성은 클러스터 이름을 기반으로
ConfigMap
CR에서 가져온 값을 사용하여 RHACM 정책 허브 쪽 템플릿을 사용하여 관리해야 합니다. - 관리 클러스터에 CPU 리소스를 저장하려면 클러스터의 GitOps ZTP 설치 후 정적 구성을 적용하는 정책을 관리 클러스터에서 바인딩해야 합니다.
4.7.2. SiteConfig Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
SiteConfig Operator는 다양한 설치 방법을 통해 클러스터를 프로비저닝하도록 설계된 템플릿 기반 솔루션입니다. 더 이상 사용되지 않는
SiteConfig
API를 대체하는 통합ClusterInstance
API가 도입되었습니다. SiteConfig Operator는ClusterInstance
API를 활용하여 다음을 제공하여 클러스터 프로비저닝을 개선합니다.- 설치 방법에서 정의를 더 잘 분리
- Git 및 non-Git 워크플로 통합
- 설치 방법 전반에 걸쳐 일관된 API
- 향상된 확장성
- 사용자 정의 설치 템플릿으로 유연성 향상
- 배포 문제 해결을 위한 귀중한 통찰력
SiteConfig Operator는 Assisted Installer와 Image-based Installer 프로비저닝 방법을 통해 클러스터 배포를 용이하게 하기 위해 검증된 기본 설치 템플릿을 제공합니다.
- Assisted Installer는 사전 정의된 구성과 검증된 호스트 설정을 활용하여 OpenShift Container Platform 클러스터의 배포를 자동화합니다. 이는 대상 인프라가 OpenShift Container Platform 요구 사항을 충족하는지 확인합니다. 지원 설치 프로그램은 수동 설치에 비해 시간과 복잡성을 최소화하면서 설치 과정을 간소화합니다.
- 이미지 기반 설치 프로그램은 사전 구성되고 검증된 OpenShift Container Platform 시드 이미지를 활용하여 단일 노드 OpenShift 클러스터의 배포를 신속하게 진행합니다. 시드 이미지는 대상 호스트에 미리 설치되어 있어 빠른 재구성과 배포가 가능합니다. 이미지 기반 설치 프로그램은 클러스터 생성 프로세스를 단순화하고 배포 시간을 크게 줄여주므로 원격 환경이나 연결이 끊긴 환경에 특히 적합합니다.
- 제한 및 요구사항
- 단일 허브 클러스터는 최대 3500개의 배포된 단일 노드 OpenShift 클러스터를 지원합니다.
4.7.3. 토폴로지 인식 라이프사이클 관리자 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
TALM은 클러스터 업그레이드, 운영자 업그레이드, 클러스터 구성 등의 변경 사항이 네트워크에 어떻게 적용되는지 관리하기 위해 허브 클러스터에서만 실행되는 운영자입니다. TALM은 다음 기능을 지원합니다.
- 사용자가 구성할 수 있는 일괄 처리 방식으로 클러스터 플릿에 대한 정책 업데이트를 점진적으로 출시합니다.
-
클러스터별 작업은 관리되는 클러스터의 구성 변경에 따라
ztp-done
레이블이나 사용자가 구성 가능한 다른 레이블을 추가합니다. 단일 노드 OpenShift 클러스터 이미지 사전 캐싱: TALM은 업그레이드를 시작하기 전에 단일 노드 OpenShift 클러스터에 OpenShift, OLM Operator 및 추가 사용자 이미지를 사전 캐싱하는 옵션을 지원합니다. 단일 노드 OpenShift 클러스터를 업그레이드하는 데 권장되는 이미지 기반 업그레이드 방법을 사용하는 경우 사전 캐싱 기능은 적용할 수 없습니다.
-
PreCachingConfig
CR을 사용하여 선택적 사전 캐싱 구성을 지정합니다. 자세한 내용은 샘플 참조PreCachingConfig
CR을 검토하세요. - 구성 가능한 필터링을 사용하여 사용하지 않는 이미지를 제외합니다.
- 구성 가능한 공간 필요 매개변수를 사용하여 사전 캐싱 전과 후에 저장 공간 검증을 활성화합니다.
-
- 제한 및 요구사항
- 400개 배치로 동시 클러스터 배포 지원
- 사전 캐싱 및 백업은 단일 노드 OpenShift 클러스터에만 제한됩니다.
- 엔지니어링 고려 사항
-
PreCachingConfig
CR은 선택 사항이며 플랫폼 관련 OpenShift 및 OLM 운영자 이미지만 사전 캐싱해야 하는 경우 만들 필요가 없습니다. -
PreCachingConfig
CR은ClusterGroupUpgrade
CR에서 참조하기 전에 적용해야 합니다. -
클러스터 설치 중에 TALM은
ran.openshift.io/ztp-deploy-wave
주석이 있는 정책만 자동으로 적용합니다. -
모든 정책은 사용자가 생성한
ClusterGroupUpgrade
CR의 제어 하에 TALM을 통해 수정될 수 있습니다.
-
4.7.4. GitOps Operator 및 GitOps ZTP 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 설명
GitOps Operator와 GitOps ZTP는 클러스터 배포 및 구성을 관리하기 위한 GitOps 기반 인프라를 제공합니다. 클러스터 정의 및 구성은 Git에서 선언적 상태로 유지됩니다.
SiteConfig
Operator가 이를 설치 CR로 렌더링하는 허브 클러스터에ClusterInstance
CR을 적용할 수 있습니다. 이전 릴리스에서는 GitOps ZTP 플러그인이SiteConfig
CR에서 설치 CR을 생성하는 기능을 지원했습니다. 이 플러그인은 더 이상 사용되지 않습니다.PolicyGenerator
또는PolicyGenTemplate
CR을 기반으로 하는 정책에 구성 CR을 자동으로 래핑하는 기능을 제공하는 별도의 GitOps ZTP 플러그인을 사용할 수 있습니다.기준 참조 구성 CR을 사용하여 관리형 클러스터에서 여러 버전의 OpenShift Container Platform을 배포하고 관리할 수 있습니다. 기준 CR과 함께 사용자 정의 CR을 사용할 수 있습니다. 여러 버전별 정책을 동시에 유지하려면 Git에서
PolicyGenerator
또는PolicyGenTemplate
CR을 사용하여 소스 및 정책 CR의 버전을 관리합니다. RHACMPolicyGenerator
는 OpenShift Container Platform 4.19 릴리스부터 권장되는 생성기 플러그인입니다.- 제한 및 요구사항
-
ArgoCD 애플리케이션당 1000개의
ClusterInstance
CR. 여러 애플리케이션을 사용하여 단일 허브 클러스터에서 지원하는 최대 클러스터 수를 달성할 수 있습니다. -
Git의
source-crs/
디렉토리에 있는 콘텐츠는 ZTP 플러그인 컨테이너에 제공된 콘텐츠보다 우선합니다. Git이 검색 경로에서 우선하기 때문입니다. -
source-crs/
디렉토리는PolicyGenerator
CR을 생성기로 포함하는kustomization.yaml
파일과 같은 디렉토리에 있어야 합니다. 이 컨텍스트에서는source-crs/
디렉토리의 대체 위치가 지원되지 않습니다.
-
ArgoCD 애플리케이션당 1000개의
- 엔지니어링 고려 사항
-
다중 노드 클러스터 업그레이드의 경우,
일시 중지
필드를true
로 설정하여 유지 관리 기간 동안MachineConfigPool
(MCP
) CR을 일시 중지할 수 있습니다.MCP
CR에서maxUnavailable
설정을 구성하면MCP
CR당 동시에 업데이트되는 노드 수를 늘릴 수 있습니다.MaxUnavailable
필드는MachineConfig
업데이트 중에 동시에 사용할 수 없는 풀의 노드 비율을 정의합니다.maxUnavailable을
허용 가능한 최대값으로 설정합니다. 이렇게 하면 업그레이드 중에 클러스터의 재부팅 횟수가 줄어들어 업그레이드 시간이 단축됩니다. 마침내MCP
CR의 일시 중지를 해제하면 변경된 모든 구성이 한 번의 재부팅으로 적용됩니다. -
클러스터 설치 중에 paused 필드를 true로 설정하고
maxUnavailable을
100%로 설정하여 사용자 지정 MCP CR을 일시 중지하면 설치 시간을 개선할 수 있습니다. 참조 CR과 사용자 지정 CR을 서로 다른 디렉터리에 보관하세요. 이렇게 하면 사용자 정의 CR을 건드리지 않고 모든 디렉토리 내용을 간단히 바꿔서 참조 CR을 패치하고 업데이트할 수 있습니다. 여러 버전을 관리할 때 권장되는 모범 사례는 다음과 같습니다.
- 각 OpenShift Container Platform 버전에 대한 정책이 Git의 콘텐츠에만 기반하여 일관되게 생성되도록 모든 소스 CR과 정책 생성 CR을 Git 저장소에 보관합니다.
- 참조 소스 CR을 사용자 정의 CR과 별도의 디렉토리에 보관하세요. 이를 통해 필요에 따라 참조 CR을 쉽게 업데이트할 수 있습니다.
-
콘텐츠를 업데이트할 때 혼란이나 의도치 않은 덮어쓰기를 방지하려면
source-crs/
디렉터리의 사용자 지정 CR과 Git의 추가 매니페스트에 고유하고 구별 가능한 이름을 사용하는 것이 좋습니다. -
추가 설치 매니페스트는
ConfigMap
CR을 통해ClusterInstance
CR에서 참조됩니다.ConfigMap
CR은ClusterInstance
CR과 함께 Git에 저장되어야 하며, 클러스터에 대한 단일 진실의 원천 역할을 해야 합니다. 필요한 경우ConfigMap
생성기를 사용하여ConfigMap
CR을 생성할 수 있습니다.
-
다중 노드 클러스터 업그레이드의 경우,
4.7.5. 에이전트 기반 설치 프로그램 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- 선택적인 에이전트 기반 설치 프로그램 구성 요소는 중앙 집중식 인프라 없이도 설치 기능을 제공합니다. 설치 프로그램은 서버에 마운트하는 ISO 이미지를 생성합니다. 서버를 부팅하면 OpenShift Container Platform을 설치하고 추가 매니페스트를 제공했습니다. 에이전트 기반 설치 프로그램을 사용하면 허브 클러스터 없이 OpenShift Container Platform을 설치할 수 있습니다. 클러스터 설치에는 컨테이너 이미지 레지스트리가 필요합니다.
- 제한 및 요구사항
- 설치 시 제한된 추가 매니페스트 세트를 제공할 수 있습니다.
-
RAN DU 사용 사례에 필요한
MachineConfiguration
CR을 포함해야 합니다.
- 엔지니어링 고려 사항
- 에이전트 기반 설치 프로그램은 OpenShift Container Platform의 기본 설치를 제공합니다.
- 설치 후 Day 2 Operator 및 RAN DU 사용 사례 구성을 설치합니다.
4.8. 통신사 RAN DU 참조 구성 CR 링크 복사링크가 클립보드에 복사되었습니다!
다음 CR(사용자 정의 리소스)을 사용하여 telco RAN DU 프로필을 사용하여 OpenShift Container Platform 클러스터를 구성하고 배포합니다. 달리 표시되지 않는 한 모든 특정 사용 모델에 사용되는 공통 기준을 형성하려면 CR을 사용합니다.
ztp-site-generate
컨테이너 이미지에서 RAN DU CR의 전체 세트를 추출할 수 있습니다. 자세한 내용은 GitOps ZTP 사이트 구성 저장소 준비를 참조하세요.
4.8.1. 클러스터 튜닝 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
클러스터 기능 |
| RAN DU 프로필을 사용하여 단일 노드 OpenShift를 설치하기 위한 대표 SiteConfig CR | 없음 |
콘솔 비활성화 |
| 콘솔 운영자를 비활성화합니다. | 없음 |
연결이 끊긴 레지스트리 |
| OpenShift Operator Marketplace를 관리하기 위한 전용 네임스페이스를 정의합니다. | 없음 |
연결이 끊긴 레지스트리 |
| 연결이 끊긴 레지스트리에 대한 카탈로그 소스를 구성합니다. | 없음 |
연결이 끊긴 레지스트리 |
| OLM에 대한 성과 프로파일링을 비활성화합니다. | 없음 |
연결이 끊긴 레지스트리 |
| 연결이 끊긴 레지스트리 이미지 콘텐츠 소스 정책을 구성합니다. | 없음 |
연결이 끊긴 레지스트리 |
| 선택 사항이며 다중 노드 클러스터에만 해당됩니다. OpenShift에서 OperatorHub를 구성하고 모든 기본 Operator 소스를 비활성화합니다. 마켓플레이스 기능이 비활성화된 단일 노드 OpenShift 설치에는 필요하지 않습니다. | 없음 |
모니터링 구성 |
| Alertmanager 및 Telemeter를 비활성화하여 모니터링 공간을 줄이고 Prometheus 보존 기간을 24시간으로 설정합니다. | 없음 |
네트워크 진단 비활성화 |
| 내장된 네트워크 문제 해결 및 진단 기능을 비활성화하기 위해 클러스터 네트워크 설정을 구성합니다. | 없음 |
4.8.2. 2일차 Operator 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
Cluster Logging Operator |
| 클러스터에 대한 로그 전달을 구성합니다. | 없음 |
Cluster Logging Operator |
| 클러스터 로깅을 위한 네임스페이스를 구성합니다. | 없음 |
Cluster Logging Operator |
| 클러스터 로깅을 위한 운영자 그룹을 구성합니다. | 없음 |
Cluster Logging Operator |
| 클러스터 로깅 서비스 계정을 구성합니다. | 없음 |
Cluster Logging Operator |
| 클러스터 로깅 서비스 계정을 구성합니다. | 없음 |
Cluster Logging Operator |
| 클러스터 로깅 서비스 계정을 구성합니다. | 없음 |
Cluster Logging Operator |
| 클러스터 로깅 운영자의 설치 및 업데이트를 관리합니다. | 없음 |
라이프사이클 에이전트 |
| OpenShift에서 이미지 기반 업그레이드 프로세스를 관리합니다. | 제공됨 |
라이프사이클 에이전트 |
| LCA 운영자의 설치 및 업데이트를 관리합니다. | 제공됨 |
라이프사이클 에이전트 |
| LCA 구독을 위한 네임스페이스를 구성합니다. | 제공됨 |
라이프사이클 에이전트 |
| LCA 구독에 대한 운영자 그룹을 구성합니다. | 제공됨 |
Local Storage Operator |
| 클러스터에서 동적 프로비저닝이 없고 삭제 회수 정책이 있는 스토리지 클래스를 정의합니다. | 없음 |
Local Storage Operator |
| openshift-local-storage 네임스페이스의 example-storage-class에 대한 로컬 저장 장치를 구성하고 장치 경로와 파일 시스템 유형을 지정합니다. | 없음 |
Local Storage Operator |
| 로컬 스토리지 운영자의 워크로드 관리 및 배포 웨이브에 대한 주석이 포함된 네임스페이스를 만듭니다. | 없음 |
Local Storage Operator |
| 로컬 스토리지 운영자에 대한 운영자 그룹을 생성합니다. | 없음 |
Local Storage Operator |
| 워크로드 관리 및 배포 웨이브에 대한 주석을 사용하여 로컬 스토리지 운영자에 대한 네임스페이스를 만듭니다. | 없음 |
LVM 운영자 |
| LVM 스토리지 운영자의 설치 또는 업그레이드를 확인합니다. | 제공됨 |
LVM 운영자 |
| 저장 장치 클래스와 볼륨 그룹 설정에 대한 플레이스홀더를 사용하여 LVM 클러스터 구성을 정의합니다. 로컬 스토리지 운영자를 대체하는 선택적 솔루션입니다. | 없음 |
LVM 운영자 |
| LVMS 운영자의 설치 및 업데이트를 관리합니다. 로컬 스토리지 운영자를 대체하는 선택적 솔루션입니다. | 없음 |
LVM 운영자 |
| 클러스터 모니터링 및 작업 부하 관리를 위한 레이블과 주석이 있는 LVMS 운영자의 네임스페이스를 만듭니다. 로컬 스토리지 운영자를 대체하는 선택적 솔루션입니다. | 없음 |
LVM 운영자 |
| LVMS 운영자에 대한 대상 네임스페이스를 정의합니다. 로컬 스토리지 운영자를 대체하는 선택적 솔루션입니다. | 없음 |
Node Tuning Operator |
| OpenShift 클러스터에서 노드 성능 설정을 구성하여 낮은 지연 시간과 실시간 작업 부하를 최적화합니다. | 없음 |
Node Tuning Operator |
| 특정 네임스페이스의 노드에 대한 스케줄러 그룹 및 서비스 구성을 포함한 성능 튜닝 설정을 적용합니다. | 없음 |
PTP 빠른 이벤트 알림 |
| 이벤트 동기화를 위한 추가 옵션과 함께 PTP 경계 클록에 대한 PTP 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP 빠른 이벤트 알림 |
| 추가적인 PTP 빠른 이벤트 설정을 통해 고가용성 경계 클록에 대한 PTP를 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP 빠른 이벤트 알림 |
| 추가적인 PTP 고속 이벤트 설정을 사용하여 PTP 그랜드마스터 클록에 대한 PTP를 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP 빠른 이벤트 알림 |
| 추가적인 PTP 빠른 이벤트 설정을 사용하여 PTP 일반 클록에 대한 PTP를 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP 빠른 이벤트 알림 |
| 기본 OperatorConfig를 재정의합니다. openshift-ptp 네임스페이스에서 PTP 데몬을 실행하기 위한 노드 선택 기준을 지정하여 PTP 운영자를 구성합니다. | 없음 |
PTP Operator |
| PTP 경계 클록에 대한 PTP 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP Operator |
| 듀얼 NIC가 있는 호스트에 대한 PTP 그랜드마스터 클록 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP Operator |
| 3개의 NIC가 있는 호스트에 대한 PTP 그랜드마스터 클록 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP Operator |
| 단일 NIC가 있는 호스트에 대한 PTP 그랜드마스터 클록 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP Operator |
| PTP 일반 시계에 대한 PTP 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP Operator |
| 활성/대기 구성에서 2개의 인터페이스가 있는 PTP 일반 클록에 대한 PTP 설정을 구성합니다. 클러스터 역할에 따라 다릅니다. | 없음 |
PTP Operator |
| openshift-ptp 네임스페이스에서 PTP 데몬을 실행하기 위한 노드 선택 기준을 지정하여 PTP Operator 설정을 구성합니다. | 없음 |
PTP Operator |
| openshift-ptp 네임스페이스에서 PTP Operator의 설치 및 업데이트를 관리합니다. | 없음 |
PTP Operator |
| PTP Operator의 네임스페이스를 구성합니다. | 없음 |
PTP Operator |
| PTP Operator에 대한 Operator 그룹을 구성합니다. | 없음 |
PTP Operator(고가용성) |
| 고가용성 PTP 경계 클록에 대한 PTP 설정을 구성합니다. | 없음 |
PTP Operator(고가용성) |
| 고가용성 PTP 경계 클록에 대한 PTP 설정을 구성합니다. | 없음 |
SR-IOV FEC Operator |
| VRAN 가속 Operator의 네임스페이스를 구성합니다. 애플리케이션 워크로드의 선택적 부분입니다. | 제공됨 |
SR-IOV FEC Operator |
| VRAN 가속 Operator에 대한 Operator 그룹을 구성합니다. 애플리케이션 워크로드의 선택적 부분입니다. | 제공됨 |
SR-IOV FEC Operator |
| VRAN 가속 Operator의 설치 및 업데이트를 관리합니다. 애플리케이션 워크로드의 선택적 부분입니다. | 제공됨 |
SR-IOV FEC Operator |
| 노드의 SR-IOV Cryostat 이더넷 컨트롤러(FEC) 설정을 구성하여 드라이버, VF 양 및 노드 선택을 지정합니다. | 제공됨 |
SR-IOV Operator |
| 다양한 네트워크 설정에 대한 자리 표시자를 사용하여 SR-IOV 네트워크 구성을 정의합니다. | 없음 |
SR-IOV Operator |
| 장치 유형, RDMA 지원, 물리적 기능 이름 및 가상 기능 수를 포함하여 특정 노드에 대한 SR-IOV 네트워크 설정을 구성합니다. | 없음 |
SR-IOV Operator |
| 노드 선택, 인젝터 및 웹 후크 옵션을 포함하여 SR-IOV Network Operator 설정을 구성합니다. | 없음 |
SR-IOV Operator |
| openshift-sriov-network-operator 네임스페이스에서 노드 선택, 인젝터, Webhook 옵션 및 비활성화를 포함하여 SNO(Single Node OpenShift)에 대한 SR-IOV Network Operator 설정을 구성합니다. | 없음 |
SR-IOV Operator |
| SR-IOV Network Operator의 설치 및 업데이트를 관리합니다. | 없음 |
SR-IOV Operator |
| 워크로드 관리 및 배포파에 대한 특정 주석을 사용하여 SR-IOV Network Operator의 네임스페이스를 생성합니다. | 없음 |
SR-IOV Operator |
| SR-IOV Network Operator의 대상 네임스페이스를 정의하여 이 네임스페이스 내에서 관리 및 배포를 활성화합니다. | 없음 |
4.8.3. 머신 구성 참조 CR 링크 복사링크가 클립보드에 복사되었습니다!
Component | 참조 CR | 설명 | 선택 사항 |
---|---|---|---|
컨테이너 런타임(crun) |
| 컨트롤 플레인 노드의 컨테이너 런타임(crun)을 구성합니다. | 없음 |
컨테이너 런타임(crun) |
| 작업자 노드의 컨테이너 런타임(crun)을 구성합니다. | 없음 |
CRI-O 제거 비활성화 |
| 컨트롤 플레인 노드에서 재부팅한 후 자동 CRI-O 캐시 지우를 비활성화합니다. | 없음 |
CRI-O 제거 비활성화 |
| 작업자 노드에서 재부팅한 후 자동 CRI-O 캐시 지우를 비활성화합니다. | 없음 |
kdump 활성화 |
| 컨트롤 플레인 노드에서 kdump 충돌 보고를 구성합니다. | 없음 |
kdump 활성화 |
| 작업자 노드에서 kdump 충돌 보고를 구성합니다. | 없음 |
kubelet 구성 및 컨테이너 마운트 숨기기 |
| 컨트롤 플레인 노드에서 kubelet과 CRI-O 간에 컨테이너별 마운트를 공유하기 위해 마운트 네임스페이스를 구성합니다. | 없음 |
kubelet 구성 및 컨테이너 마운트 숨기기 |
| 작업자 노드에서 kubelet과 CRI-O 간에 컨테이너별 마운트를 공유하기 위해 마운트 네임스페이스를 구성합니다. | 없음 |
일회성 시간 동기화 |
| 컨트롤 플레인 노드에서 시간을 한 번 동기화합니다. | 없음 |
일회성 시간 동기화 |
| 작업자 노드에서 시간을 한 번 동기화합니다. | 없음 |
SCTP |
| 컨트롤 플레인 노드에서 SCTP 커널 모듈을 로드합니다. | 제공됨 |
SCTP |
| 작업자 노드에서 SCTP 커널 모듈을 로드합니다. | 제공됨 |
RCU Normal 설정 |
| 컨트롤 플레인 노드가 부팅된 후 rcu_normal를 설정하여 rcu_expedited를 비활성화합니다. | 없음 |
RCU Normal 설정 |
| 작업자 노드가 부팅된 후 rcu_normal를 설정하여 rcu_expedited를 비활성화합니다. | 없음 |
SR-IOV 관련 커널 인수 |
| 컨트롤 플레인 노드에서 SR-IOV 지원을 활성화합니다. | 없음 |
SR-IOV 관련 커널 인수 |
| 작업자 노드에서 SR-IOV 지원을 활성화합니다. | 없음 |
4.9. 클러스터와 telco RAN DU 참조 구성 비교 링크 복사링크가 클립보드에 복사되었습니다!
telco RAN DU 클러스터를 배포한 후 cluster-compare
플러그인을 사용하여 telco RAN DU 참조 설계 사양(RDS) 준수를 평가할 수 있습니다. cluster-compare
플러그인은 OpenShift CLI(oc
) 플러그인입니다. 플러그인은 telco RAN DU 참조 구성을 사용하여 telco RAN DU CR(사용자 정의 리소스)을 사용하여 클러스터를 검증합니다.
telco RAN DU의 플러그인별 참조 구성은 telco RAN DU CR을 사용하여 컨테이너 이미지에 패키지됩니다.
cluster-compare
플러그인에 대한 자세한 내용은 "Cluster-compare 플러그인 이해"를 참조하십시오.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
registry.redhat.io
컨테이너 이미지 레지스트리에 액세스하기 위한 인증 정보가 있어야 합니다. -
cluster-compare
플러그인이 설치되어 있어야 합니다.
프로세스
다음 명령을 실행하여 인증 정보를 사용하여 컨테이너 이미지 레지스트리에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ztp-site-generate-rhel8
컨테이너 이미지에서 콘텐츠를 추출합니다.podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.19
$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.19
Copy to Clipboard Copied! Toggle word wrap Toggle overflow mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.19 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.19 extract /home/ztp --tar | tar x -C ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터의 구성을 참조 구성과 비교합니다.
oc cluster-compare -r out/reference/metadata.yaml
$ oc cluster-compare -r out/reference/metadata.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 비교 중인 CR입니다. 플러그인은 해당 템플릿과 차이가 있는 각 CR을 표시합니다.
- 2
- 비교를 위해 CR과 일치하는 템플릿입니다.
- 3
- Linux diff 형식의 출력은 템플릿과 클러스터 CR의 차이점을 보여줍니다.
- 4
- 플러그인이 각 CR에 대한 줄 diffs를 보고하면 차이점에 대한 요약이 보고됩니다.
- 5
- 해당 템플릿의 차이점과 비교한 CR 수입니다.
- 6
- 참조 구성에 표시되지만 실시간 클러스터에서 누락된 CR 수입니다.
- 7
- 참조 구성에 표시되지만 실시간 클러스터에서 누락된 CR 목록입니다.
- 8
- 참조 구성에서 해당 템플릿과 일치하지 않는 CR입니다.
- 9
- 메타데이터 해시는 참조 구성을 식별합니다.
- 10
- 패치된 CR 목록입니다.
4.10. Telco RAN DU 4.16 검증 소프트웨어 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat telco RAN DU 4.16 솔루션은 다음과 같은 OpenShift Container Platform 관리 클러스터 및 허브 클러스터에 대해 다음과 같은 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.
Component | 소프트웨어 버전 |
---|---|
관리형 클러스터 버전 | 4.19 |
Cluster Logging Operator | 6.21 |
Local Storage Operator | 4.19 |
OADP(OpenShift API for Data Protection) | 1.5 |
PTP Operator | 4.19 |
SR-IOV Operator | 4.19 |
SRIOV-FEC Operator | 2.11 |
라이프사이클 에이전트 | 4.19 |
[1] 이 표는 aligned Cluster Logging Operator 버전 6.3이 릴리스될 때 업데이트됩니다.
4.11. Telco RAN DU 4.19 hub cluster validated software components 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat telco RAN 4.19 솔루션은 다음 OpenShift Container Platform 허브 클러스터용 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.
Component | 소프트웨어 버전 |
---|---|
hub 클러스터 버전 | 4.19 |
Red Hat Advanced Cluster Management(RHACM) | 2.13 |
Red Hat OpenShift GitOps | 1.16 |
GitOps ZTP 사이트 생성 플러그인 | 4.19 |
토폴로지 인식 라이프사이클 관리자(TALM) | 4.19 |
5장. Telco Hub 참조 설계 사양 링크 복사링크가 클립보드에 복사되었습니다!
RDS(telco hub reference design specification)는 통신 환경에서 OpenShift Container Platform 클러스터의 플릿을 배포 및 운영하는 허브 클러스터의 구성을 설명합니다.
5.1. 참조 설계 범위 링크 복사링크가 클립보드에 복사되었습니다!
Telco core 및 telco RAN 참조 설계 사양(RDS)은 권장, 테스트 및 지원되는 구성을 캡처하여 Telco core 및 telco RAN 프로필을 실행하는 클러스터에 대해 안정적이고 반복 가능한 성능을 제공합니다.
각 RDS에는 클러스터가 개별 프로필을 실행할 수 있도록 설계 및 검증되는 릴리스된 기능 및 지원되는 구성이 포함되어 있습니다. 이 구성은 기능 및 KPI 대상을 충족하는 기본 OpenShift Container Platform 설치를 제공합니다. 각 RDS는 개별 구성에 대해 예상되는 변형도 설명합니다. 각 RDS의 검증에는 긴 기간과 대규모 테스트가 포함되어 있습니다.
검증된 참조 구성은 OpenShift Container Platform의 각 주요 Y-stream 릴리스에 대해 업데이트됩니다. Z-stream 패치 릴리스는 참조 구성에 대해 주기적으로 다시 테스트됩니다.
5.2. 참조 설계의 편차 링크 복사링크가 클립보드에 복사되었습니다!
검증된 Telco 코어 및 telco RAN DU 참조 설계 사양(RDS)을 벗어나면 변경되는 특정 구성 요소 또는 기능 이외의 중요한 영향을 미칠 수 있습니다. 편차는 전체 솔루션의 맥락에서 분석 및 엔지니어링이 필요합니다.
RDS의 모든 편차는 명확한 작업 추적 정보로 분석 및 문서화되어야 합니다. 실사실은 파트너로부터 참조 설계에 맞춰 편차를 가져오는 방법을 이해할 것으로 예상됩니다. 이를 위해서는 파트너사가 Red Hat과 협력하여 플랫폼에서 최상의 결과를 얻을 수 있도록 활용 사례를 제공하기 위해 추가 리소스를 제공해야 할 수 있습니다. 이는 솔루션의 지원 가능성과 Red Hat 및 파트너 간의 조정을 보장하는 데 매우 중요합니다.
RDS의 편차는 다음과 같은 결과 중 일부 또는 모두를 가질 수 있습니다.
- 문제를 해결하는 데 시간이 더 걸릴 수 있습니다.
- 프로젝트 서비스 수준 계약(SLA), 프로젝트 기한, 최종 공급자 성능 요구 사항이 누락될 위험이 있습니다.
승인되지 않은 편차는 행정 수준에서 에스컬레이션이 필요할 수 있습니다.
참고Red Hat은 파트너 참여 우선 순위에 따라 편차 요청의 우선 순위를 지정합니다.
5.3. hub 클러스터 아키텍처 개요 링크 복사링크가 클립보드에 복사되었습니다!
관리 허브 클러스터에서 실행되는 기능 및 구성 요소를 사용하여 hub-and-spoke 토폴로지의 다른 여러 클러스터를 관리합니다. 허브 클러스터는 배포된 클러스터의 구성, 라이프사이클 및 관찰 기능을 관리하기 위한 고가용성 및 중앙 집중식 인터페이스를 제공합니다.
모든 관리 허브 기능은 전용 OpenShift Container Platform 클러스터 또는 기존 클러스터에 공존하는 애플리케이션으로 배포할 수 있습니다.
- 관리형 클러스터 라이프사이클
- hub 클러스터는 Day 2 Operator의 조합을 사용하여 GitOps 방법론을 사용하여 클러스터 플릿을 배포하고 구성하는 데 필요한 인프라를 제공합니다. 배포된 클러스터의 수명 동안 추가 업그레이드 관리, 클러스터 수 확장, 노드 교체 및 기타 라이프사이클 관리 기능을 선언적으로 정의하고 롤아웃할 수 있습니다. 함대 전반에 걸쳐 롤아웃의 타이밍 및 진행 상황을 제어할 수 있습니다.
- 모니터링
- hub 클러스터는 RHACM Operator의 Observability 알약을 통해 관리 클러스터에 대한 모니터링 및 상태 보고를 제공합니다. 여기에는 Governance 정책 프레임워크를 통한 집계 지표, 경고 및 규정 준수 모니터링이 포함됩니다.
Telco 관리 허브 참조 설계 사양(RDS) 및 관련 참조 사용자 정의 리소스(CR)는 통신 관리 클러스터 인프라의 라이프사이클 배포, 구성 및 관리를 위한 통신 엔지니어링 및 QE 검증 방법을 설명합니다. 참조 구성에는 OpenShift Container Platform 상단에 허브 클러스터 구성 요소의 설치 및 구성이 포함됩니다.
그림 5.1. Hub 클러스터 참조 설계 구성 요소
그림 5.2. hub 클러스터 참조 설계 아키텍처
5.4. Telco 관리 허브 클러스터 모델 사용 링크 복사링크가 클립보드에 복사되었습니다!
허브 클러스터는 통신 애플리케이션 및 워크로드 클러스터에 대한 관리형 클러스터 설치, 구성, 관찰 기능 및 지속적인 라이프사이클 관리를 제공합니다.
5.5. hub 클러스터 스케일링 대상 링크 복사링크가 클립보드에 복사되었습니다!
허브 클러스터의 리소스 요구 사항은 허브에서 관리하는 클러스터 수, 각 관리 클러스터에 사용되는 정책 수, RHACM(Red Hat Advanced Cluster Management)에 구성된 기능 세트에 따라 달라집니다.
허브 클러스터 참조 구성은 다음 조건에서 최대 3500개의 관리형 단일 노드 OpenShift 클러스터를 지원할 수 있습니다.
- hub-side templatelating이 10분 평가 간격으로 구성된 각 클러스터에 대한 정책 5개입니다.
다음 RHACM 애드온만 활성화됩니다.
- 정책 컨트롤러
- 기본 구성으로 관찰 가능
- 한 번에 최대 500개의 클러스터 배치로 GitOps ZTP를 사용하여 관리되는 클러스터를 배포합니다.
또한 참조 구성은 관리되는 클러스터 토폴로지 혼합 배포 및 관리를 위해 검증됩니다. 특정 제한은 클러스터 토폴로지의 혼합, 활성화된 RHACM 기능 등에 따라 다릅니다. 혼합 토폴로지 시나리오에서 참조 허브 구성은 1200개의 단일 노드 OpenShift 클러스터, 400개의 컴팩트 클러스터(컨트롤 플레인 및 컴퓨팅 노드를 결합한 3개의 노드) 및 230 표준 클러스터 (3개의 컨트롤 플레인 및 2 작업자 노드)의 조합으로 검증됩니다.
이 참조 사양을 준수하는 허브 클러스터는 각 ArgoCD 애플리케이션에 대해 1000개의 단일 노드 ClusterInstance
CR 동기화를 지원할 수 있습니다. 여러 애플리케이션을 사용하여 단일 허브 클러스터에서 지원하는 최대 클러스터 수를 달성할 수 있습니다.
특정 차원 요구 사항은 클러스터 토폴로지 및 워크로드에 따라 다릅니다. 자세한 내용은 "스토리지 요구 사항"을 참조하십시오. 관리되는 클러스터의 특정 특성에 맞게 클러스터의 크기를 조정합니다.
5.6. hub 클러스터 리소스 사용률 링크 복사링크가 클립보드에 복사되었습니다!
리소스 사용률은 다음 시나리오에서 허브 클러스터를 배포하기 위해 측정되었습니다.
- 참조 로드에서 3500개의 단일 노드 OpenShift 클러스터 관리.
- 듀얼 소켓 베어 메탈 서버에서 실행되는 관리 허브를 위한 3-노드 컴팩트 클러스터.
- 50ms 라운드트립 대기 시간, 100Mbps 대역폭 제한 및 0.02% 패킷 손실의 네트워크 손상
- 관찰 기능이 활성화되지 않았습니다.
- 로컬 스토리지만 사용되었습니다.
지표 | Peak Measurement |
---|---|
OpenShift Platform CPU | 106 코어(노드당 최대 50개 코어) |
OpenShift Platform 메모리 | 504G (노드당 168G) |
5.7. hub 클러스터 토폴로지 링크 복사링크가 클립보드에 복사되었습니다!
프로덕션 환경에서 관리 기능의 고가용성을 유지하려면 OpenShift Container Platform 허브 클러스터가 고가용성이어야 합니다.
- 제한 및 요구사항
hub 클러스터에 고가용성 클러스터 토폴로지를 사용합니다. 예를 들면 다음과 같습니다.
- 컴팩트 (3개의 노드가 컨트롤 플레인 및 컴퓨팅 노드를 결합함)
- 표준 (3개의 컨트롤 플레인 노드 + 컴퓨팅 노드)
- 엔지니어링 고려 사항
- 프로덕션 환경 이외의 환경에서는 단일 노드 OpenShift 클러스터를 제한된 허브 클러스터 기능에 사용할 수 있습니다.
- 예를 들어 Red Hat OpenShift Data Foundation과 같은 특정 기능은 단일 노드 OpenShift에서 지원되지 않습니다. 이 구성에서는 일부 허브 클러스터 기능을 사용할 수 없을 수 있습니다.
- 특정 사용 사례의 크기에 따라 선택적 컴퓨팅 노드의 수는 다를 수 있습니다.
- 필요에 따라 컴퓨팅 노드를 나중에 추가할 수 있습니다.
5.8. hub 클러스터 네트워킹 링크 복사링크가 클립보드에 복사되었습니다!
참조 허브 클러스터는 인터넷에 직접 액세스할 수 없는 연결이 끊긴 네트워킹 환경에서 작동하도록 설계되었습니다. 모든 OpenShift Container Platform 클러스터와 마찬가지로 허브 클러스터는 모든 OpenShift 및 Day 2 OLM(Operator Lifecycle Manager) 이미지를 호스팅하는 이미지 레지스트리에 액세스해야 합니다.
hub 클러스터는 IPv6 및 IPv4 네트워크에 대한 이중 스택 네트워킹 지원을 지원합니다. IPv6는 엣지 또는 원거리 네트워크 세그먼트에서 일반적인 반면 IPv4는 데이터 센터의 기존 장비와 함께 사용하는 것이 더 일반적입니다.
- 제한 및 요구사항
설치 방법에 관계없이 hub 클러스터에 대해 다음 네트워크 유형을 구성해야 합니다.
-
clusterNetwork
-
serviceNetwork
-
machineNetwork
-
hub 클러스터에 대해 다음 IP 주소를 구성해야 합니다.
-
apiVIP
-
ingressVIP
-
참고위의 네트워킹 구성의 경우 일부 값이 필요하거나 선택한 아키텍처 및 DHCP 구성에 따라 자동으로 할당될 수 있습니다.
- 기본 OpenShift Container Platform 네트워크 공급자 OVN-Kubernetes를 사용해야 합니다.
관리형 클러스터와 허브 클러스터 간의 네트워킹은 RHACM(Red Hat Advanced Cluster Management) 설명서의 네트워킹 요구 사항을 충족해야 합니다. 예를 들면 다음과 같습니다.
- 관리된 클러스터 API 서비스, Ironic Python 에이전트 및 BMC(Baseboard Management Controller) 포트에 대한 Hub 클러스터 액세스.
- 허브 클러스터 API 서비스, 수신 IP 및 컨트롤 플레인 노드 IP 주소에 대한 관리형 클러스터 액세스.
- 허브 클러스터 컨트롤 플레인 노드 IP 주소에 대한 관리형 클러스터 BMC 액세스.
허브 클러스터의 수명 동안 이미지 레지스트리에 액세스할 수 있어야 합니다.
- 필요한 모든 컨테이너 이미지를 연결 해제된 레지스트리에 미러링해야 합니다.
- 연결 해제된 레지스트리를 사용하도록 hub 클러스터를 구성해야 합니다.
- 허브 클러스터는 자체 이미지 레지스트리를 호스팅할 수 없습니다. 예를 들어 정전이 모든 클러스터 노드에 영향을 미치는 시나리오에서는 레지스트리를 사용할 수 있어야 합니다.
- 엔지니어링 고려 사항
- 허브 클러스터를 배포할 때 적절한 크기의 CIDR 범위 정의를 정의해야 합니다.
5.9. hub 클러스터 메모리 및 CPU 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
hub 클러스터의 메모리 및 CPU 요구 사항은 hub 클러스터 구성, 클러스터의 리소스 수 및 관리 클러스터 수에 따라 다릅니다.
- 제한 및 요구사항
- hub 클러스터가 OpenShift Container Platform 및 RHACM(Red Hat Advanced Cluster Management)의 기본 메모리 및 CPU 요구 사항을 충족하는지 확인합니다.
- 엔지니어링 고려 사항
- telco hub 클러스터를 배포하기 전에 클러스터 호스트가 클러스터 요구 사항을 충족하는지 확인합니다.
관리되는 클러스터 수 스케일링에 대한 자세한 내용은 "Hub cluster scaling target"을 참조하십시오.
5.10. hub 클러스터 스토리지 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
관리 허브 클러스터에 필요한 총 스토리지 양은 클러스터에 배포된 각 애플리케이션의 스토리지 요구 사항에 따라 달라집니다. 고가용성 PersistentVolume
리소스를 통한 스토리지가 필요한 주요 구성 요소는 다음 섹션에 설명되어 있습니다.
기본 OpenShift Container Platform 설치에 필요한 스토리지는 이러한 요구 사항과 다릅니다.
5.10.1. 지원 서비스 링크 복사링크가 클립보드에 복사되었습니다!
지원 서비스는 다중 클러스터 엔진 및 RHACM(Red Hat Advanced Cluster Management)과 함께 배포됩니다.
영구 볼륨 리소스 | 크기(GB) |
---|---|
| 50 |
| 700 |
| 20 |
5.10.2. RHACM Observability 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 Observability는 다중 클러스터 엔진 및 RHACM(Red Hat Advanced Cluster Management)에서 제공합니다.
-
관찰성 스토리지에는 메트릭을 장기 보존하기 위해 여러
PV
리소스와 S3 호환 버킷 스토리지가 필요합니다. -
스토리지 요구 사항 계산은 복잡하고 관리 클러스터의 특정 워크로드 및 특성에 따라 달라집니다.
PV
리소스 및 S3 버킷에 대한 요구 사항은 데이터 보존, 관리 클러스터 수, 관리형 클러스터 워크로드 등 다양한 측면에 따라 다릅니다. - RHACM 용량 계획 리포지토리에서 관찰 기능 크기 계산기를 사용하여 관찰 기능에 필요한 스토리지를 추정합니다. 계산기를 사용하여 관찰 스토리지 요구 사항을 추정하는 방법에 대한 설명은 통신 환경에서 MultiClusterHub Observability의 스토리지 요구 사항 계산 문서를 참조하십시오. 아래 표에서는 telco RAN DU RDS에서 파생된 입력과 hub cluster RDS를 대표 값으로 사용합니다.
다음 숫자가 추정됩니다. 보다 정확한 결과를 위해 값을 조정합니다. 잠재적인 추정 부정확성을 고려하여 엔지니어링 마진(예: +20%)을 결과에 추가합니다.
용량 플래너 입력 | 데이터 소스 | 예시 값 |
---|---|---|
컨트롤 플레인 노드 수 | Hub 클러스터 RDS(scale) 및 telco RAN DU RDS(topology) | 3500 |
추가 작업자 노드 수 | Hub 클러스터 RDS(scale) 및 telco RAN DU RDS(topology) | 0 |
데이터 저장 일수 | Hub 클러스터 RDS | 15 |
클러스터당 총 Pod 수 | Ttelco RAN DU RDS | 120 |
네임스페이스 수(OpenShift Container Platform 제외) | Ttelco RAN DU RDS | 4 |
시간당 메트릭 샘플 수 | 기본값 | 12 |
수신자 PV(영구 볼륨)의 보존 시간 수 | 기본값 | 24 |
이러한 입력 값을 사용하면 Red Hat 지식 베이스 문서에 설명된 크기 계산기 문서 통신 환경의 MultiClusterHub Observability의 스토리지 요구 사항에 따라 다음과 같은 스토리지 요구 사항이 표시됩니다.
Alertmanager PV | Thanos 수신 PV | Thanos 컴팩트 PV | |||
---|---|---|---|---|---|
복제본당 | 합계 | 복제본당 | 합계 | 합계 | |
20GiB | 20GiB | 20GiB | 20GiB | 20GiB |
Thanos 규칙 PV | Thanos 저장소 PV | 오브젝트 버킷[1] | |||
---|---|---|---|---|---|
복제본당 | 합계 | 복제본당 | 합계 | 일당 | 합계 |
20GiB | 20GiB | 20GiB | 20GiB | 20GiB | 20GiB |
[1] 오브젝트 버킷의 경우 다운스트림이 비활성화된 것으로 간주되므로 스토리지 요구 사항에 따라 원시 데이터만 계산됩니다.
5.10.3. 스토리지 고려 사항 링크 복사링크가 클립보드에 복사되었습니다!
- 제한 및 요구사항
- 최소 OpenShift Container Platform 및 RHACM(Red Hat Advanced Cluster Management) 제한이 적용됩니다.
- 고가용성은 스토리지 백엔드를 통해 제공해야 합니다. hub 클러스터 참조 구성은 Red Hat OpenShift Data Foundation을 통해 스토리지를 제공합니다.
- 오브젝트 버킷 스토리지는 OpenShift Data Foundation을 통해 제공됩니다.
- 엔지니어링 고려 사항
- 대기 시간이 짧고 etcd 스토리지의 처리량이 높은 SSD 또는 NVMe 디스크를 사용합니다.
통신 허브 클러스터용 스토리지 솔루션은 OpenShift Data Foundation입니다.
- Local Storage Operator는 OpenShift Data Foundation에서 허브 클러스터의 다른 구성 요소에 필요한 대로 블록, 파일 및 오브젝트 스토리지를 제공하는 데 사용하는 스토리지 클래스를 지원합니다.
-
Local Storage Operator
LocalVolume
구성에는 OpenShift Data Foundation이 이전에 사용된 허브 클러스터 노드의 재설치를 지원하기 위해forceWipeDevicesAndDestroyAllData: true
설정이 포함됩니다.
5.10.4. Git 리포지토리 링크 복사링크가 클립보드에 복사되었습니다!
통신 관리 허브 클러스터는 다양한 통신 애플리케이션의 OpenShift 클러스터 구성을 설치하고 관리하기 위한 GitOps 중심 방법론을 지원합니다. 이 방법론에는 클러스터 정의 및 구성 아티팩트에 대해 권한 있는 정보 소스 역할을 하는 액세스 가능한 Git 리포지토리가 필요합니다.
Red Hat은 상업적으로 지원되는 Git 서버를 제공하지 않습니다. 프로덕션 환경에 제공된 기존 Git 서버를 사용할 수 있습니다. Gitea 및 Gogs는 사용할 수 있는 자체 호스팅 Git 서버의 예입니다.
Git 리포지토리는 일반적으로 hub 클러스터 외부에 있는 production 네트워크에 제공됩니다. 대규모 배포에서 여러 허브 클러스터는 동일한 Git 리포지토리를 사용하여 관리되는 클러스터 정의를 유지 관리할 수 있습니다. 이 방법을 사용하면 전체 네트워크의 상태를 쉽게 검토할 수 있습니다. 클러스터 정의의 정보 소스로서 Git 리포지토리는 고가용성이어야 하며 재해 시나리오에서 복구할 수 있어야 합니다.
재해 복구 및 다중 허브 고려 사항의 경우 허브 클러스터와 별도로 Git 리포지토리를 실행합니다.
- 제한 및 요구사항
- 관리 클러스터의 설치, 구성 및 라이프사이클 관리를 포함하여 허브 클러스터의 GitOps ZTP 기능을 지원하는 Git 리포지토리가 필요합니다.
- Git 리포지토리는 관리 클러스터에서 액세스할 수 있어야 합니다.
- 엔지니어링 고려 사항
- Git 리포지토리는 GitOps Operator에서 사용하여 적용된 구성에 대한 지속적인 배포 및 단일 정보 소스를 보장합니다.
5.11. hub 클러스터에 OpenShift Container Platform 설치 링크 복사링크가 클립보드에 복사되었습니다!
- 설명
허브 클러스터용 OpenShift Container Platform을 설치하는 참조 방법은 에이전트 기반 설치 관리자를 사용하는 것입니다.
에이전트 기반 설치 관리자는 추가 중앙 집중식 인프라 없이 설치 기능을 제공합니다. 에이전트 기반 설치 프로그램은 설치할 서버에 마운트되는 ISO 이미지를 생성합니다. 서버를 부팅할 때 OpenShift Container Platform은 선택적으로 제공된 추가 매니페스트(예: Red Hat OpenShift GitOps Operator)와 함께 설치됩니다.
참고다른 설치 방법을 사용하여 hub 클러스터에 OpenShift Container Platform을 설치할 수도 있습니다.
허브 클러스터 기능이 기존 OpenShift Container Platform 클러스터에 적용되는 경우 에이전트 기반 설치 관리자 설치가 필요하지 않습니다. Day 2 Operator를 설치하고 이러한 기능에 맞게 클러스터를 구성하는 나머지 단계는 동일하게 유지됩니다. OpenShift Container Platform 설치가 완료되면 추가 Operator 세트와 해당 구성이 hub 클러스터에 설치되어 있어야 합니다.
참조 구성에는 수동으로 적용할 수 있는 이러한 모든 사용자 정의 리소스(CR)가 포함됩니다. 예를 들면 다음과 같습니다.
oc apply -f <reference_cr>
$ oc apply -f <reference_cr>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git 리포지토리에 참조 구성을 추가하고 ArgoCD를 사용하여 적용할 수도 있습니다.
참고CR을 수동으로 적용하는 경우 CR을 종속 항목 순서대로 적용해야 합니다. 예를 들어 Operator 앞에 네임스페이스를 적용하고 구성 전에 Operator를 적용합니다.
- 제한 및 요구사항
- 에이전트 기반 설치 관리자에는 필요한 모든 OpenShift Container Platform 및 Day 2 Operator 이미지가 포함된 액세스 가능한 이미지 리포지토리가 필요합니다.
- 에이전트 기반 설치 프로그램은 특정 OpenShift 릴리스 및 특정 클러스터 세부 정보를 기반으로 ISO 이미지를 빌드합니다. 두 번째 허브를 설치하려면 별도의 ISO 이미지를 빌드해야 합니다.
- 엔지니어링 고려 사항
- 에이전트 기반 설치 프로그램은 기본 OpenShift Container Platform 설치를 제공합니다. 클러스터를 설치한 후 Day 2 Operator 및 기타 구성 CR을 적용합니다.
- 참조 구성은 연결이 끊긴 환경에서 에이전트 기반 설치 관리자를 지원합니다.
- 제한된 추가 매니페스트 세트를 설치 시 제공할 수 있습니다.
5.12. 허브 클러스터의 2일 Operator 링크 복사링크가 클립보드에 복사되었습니다!
관리 허브 클러스터는 중요한 관리 서비스 및 인프라를 제공하기 위해 Day 2 Operator 세트를 사용합니다. 플릿에서 관리되는 클러스터 버전 세트와 일치하는 Operator 버전을 사용합니다.
OLM(Operator Lifecycle Manager) 및 Subscription
CR(사용자 정의 리소스)을 사용하여 Day 2 Operator를 설치합니다. Subscription
CR은 설치할 특정 Day 2 Operator, Operator가 있는 카탈로그 및 Operator에 적합한 버전 채널을 식별합니다. 기본적으로 OLM은 채널에서 사용 가능한 최신 z-stream 버전으로 Operator를 업데이트한 상태로 유지합니다. 기본적으로 모든 서브스크립션은 installPlanApproval: 자동
값을 사용하여 설정됩니다. 이 모드에서 OLM은 카탈로그 및 채널에서 사용할 수 있을 때 새 Operator 버전을 자동으로 설치합니다.
installPlanApproval
을 자동으로 설정하면 카탈로그 인덱스가 최신 Operator 버전을 포함하도록 업데이트되는 경우 Operator가 정의된 유지 관리 기간 외부에서 업데이트될 위험이 발생합니다. 카탈로그에서 선별된 Operator 및 버전 세트를 빌드하고 유지 관리하는 연결이 끊긴 환경에서는 업데이트된 버전에 대한 새 카탈로그 인덱스 생성 전략에 따라 Operator가 실수로 업데이트될 위험이 크게 제거됩니다. 그러나 이 위험을 추가로 종료하려는 경우 Subscription
CR을 installPlanApproval: Manual
로 설정하여 Operator가 명시적 관리자 승인 없이 업데이트되지 않도록 할 수 있습니다.
- 제한 및 요구사항
- telco hub 클러스터를 업그레이드할 때 OpenShift Container Platform 및 Operator 버전은 모든 관련 호환성 매트릭스의 요구사항을 충족해야 합니다.
5.13. 가시성 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management) 다중 클러스터 엔진 Observability 구성 요소는 모든 관리 클러스터에 대한 지표 및 경고의 중앙 집중식 집계 및 시각화를 제공합니다. 성능 및 데이터 분석을 밸런싱하기 위해 모니터링 서비스는 다운샘플링된 간격으로 수집된 집계 지표의 하위 집합 목록을 유지 관리합니다. 다양한 사전 구성된 대시보드 세트를 통해 허브에서 메트릭에 액세스할 수 있습니다.
- 관찰 기능 설치
Observability 서비스를 활성화하고 구성하는 기본 CR은 다음 설정을 정의하는
MulticlusterObservability
CR입니다. 기본 사용자 정의 리소스(CR)는 다음 설정을 정의하는MulticlusterObservability
CR입니다.- 구성 가능한 보존 설정입니다.
-
다른 구성 요소의 스토리지:
thanos는 ,
.thanos 컴팩트
,thanos 규칙
,thanos 저장소
샤딩,alertmanager
를 수신합니다 관리 클러스터에서 모니터링 구성을 조정할 수 있는
metadata.annotations.mco-disable-alerting="true"
주석입니다.참고이 설정이 없으면 Observability 구성 요소가 관리되는 클러스터 모니터링 구성을 구성하려고 합니다. 이 값 세트를 사용하면 관리형 클러스터 모니터링
ConfigMap
오브젝트로 경고 전달의 필요한 Observability 구성과 원하는 구성을 병합할 수 있습니다. Observability 서비스가 활성화된 RHACM은 각 관리 클러스터에 배포되며 로컬 모니터링에 의해 생성된 지표 및 경고를 허브 클러스터로 푸시하기 위한 워크로드가 배포됩니다. 관리 클러스터에서 허브로 전달할 메트릭 및 경고는open-cluster-management-addon-observability
네임스페이스의ConfigMap
CR에 의해 정의됩니다. 사용자 지정 메트릭을 지정할 수도 있습니다. 자세한 내용은 사용자 정의 메트릭 추가 를 참조하십시오.
- Alertmananger 구성
- 허브 클러스터는 외부 시스템에 경고를 푸시하도록 구성할 수 있는 Observability Alertmanager를 제공합니다(예: 이메일). Alertmanager는 기본적으로 활성화되어 있습니다.
- 경고 전달을 구성해야 합니다.
- Alertmanager가 활성화되어 있지만 구성되지 않은 경우 hub Alertmanager는 경고를 외부로 전달하지 않습니다.
- Observability가 활성화되면 hub Alertmanager를 포함한 모든 엔드포인트에 경고를 전송하도록 관리 클러스터를 구성할 수 있습니다.
- 관리 클러스터가 외부 소스에 경고를 전달하도록 구성되면 hub 클러스터 Alertmanager를 통해 경고가 라우팅되지 않습니다.
- 경고 상태는 지표로 사용할 수 있습니다.
- 관찰 기능을 활성화하면 관리 클러스터 경고 상태가 허브 클러스터로 전달된 지표 서브 세트에 포함되며 Observability 대시보드를 통해 사용할 수 있습니다.
- 제한 및 요구사항
- 관찰 기능을 사용하려면 장기 메트릭을 위해 영구 오브젝트 스토리지가 필요합니다. 자세한 내용은 "스토리지 요구 사항"을 참조하십시오.
- 엔지니어링 고려 사항
-
메트릭의 전달은 전체 메트릭 데이터의 하위 집합입니다.
observability-metrics-allowlist
구성 맵에 정의된 지표와 사용자가 추가한 사용자 정의 메트릭만 포함합니다. -
메트릭은 downsampled 속도로 전달됩니다. 메트릭은 5분 간격(또는
MultiClusterObservability
CR 구성에 정의된)으로 최신 데이터 포인트를 가져와 전달됩니다. - 네트워크 중단으로 인해 해당 간격 동안 허브 클러스터로 전달되는 지표가 손실될 수 있습니다. 관리 클러스터에서 공급자 네트워크의 외부 지표 수집기로 메트릭을 직접 전달하는 경우 이를 완화할 수 있습니다. 전체 해결 메트릭은 관리 클러스터에서 사용할 수 있습니다.
- 허브의 기본 메트릭 대시보드 외에도 사용자는 사용자 지정 대시보드를 정의할 수 있습니다.
- 참조 구성은 3500개의 단일 노드 OpenShift 클러스터의 허브 클러스터에 의해 15일의 메트릭 스토리지를 기반으로 조정됩니다. 보존 또는 기타 관리 클러스터 토폴로지 또는 크기 조정이 더 긴 경우 스토리지 계산을 업데이트하고 충분한 스토리지 용량을 유지해야 합니다. 새 값을 계산하는 방법에 대한 자세한 내용은 "스토리지 요구 사항"을 참조하십시오.
-
메트릭의 전달은 전체 메트릭 데이터의 하위 집합입니다.
5.14. 관리형 클러스터 라이프사이클 관리 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 에지에서 사이트를 프로비저닝하고 관리하려면 단일 허브 클러스터가 많은 관리 클러스터를 관리하는 hub-and-spoke 아키텍처에서 GitOps ZTP를 사용합니다.
스프린드 클러스터의 라이프사이클 관리는 OpenShift Container Platform 설치를 포함한 클러스터 배포 및 클러스터 구성의 두 단계로 나눌 수 있습니다.
5.14.1. 관리형 클러스터 배포 링크 복사링크가 클립보드에 복사되었습니다!
- 설명
-
RHACM(Red Hat Advanced Cluster Management) 2.12부터 siteConfig Operator를 사용하는 것이 관리 클러스터를 배포하는 데 권장되는 방법입니다. SiteConfig Operator에는 배포된 방식에서 클러스터를 정의하는 매개변수를 분리하는 통합 ClusterInstance API가 도입되었습니다. SiteConfig Operator는
ClusterInstance
CR(사용자 정의 리소스)의 데이터를 사용하여 인스턴스화되는 클러스터 템플릿 세트를 사용하여 설치 매니페스트를 동적으로 생성합니다. GitOps 방법론에 따라ClusterInstance
CR은 ArgoCD를 통해 Git 리포지토리에서 가져옵니다.ClusterInstance
CR은 지원 설치 관리자 또는 다중 클러스터 엔진에서 사용할 수 있는 이미지 기반 설치를 사용하여 클러스터 설치를 시작할 수 있습니다. - 제한 및 요구사항
-
SiteConfig
CR을 처리하는 siteConfig ArgoCD 플러그인은 OpenShift Container Platform 4.18에서 더 이상 사용되지 않습니다.
-
- 엔지니어링 고려 사항
-
BMC(클러스터 베이스 보드 관리 컨트롤러)의 로그인 정보를 사용하여
Secret
CR을 생성해야 합니다. 그런 다음 이Secret
CR은 siteConfig CR에서
참조됩니다. Vault와 같은 시크릿 저장소와의 통합을 사용하여 시크릿을 관리할 수 있습니다. - Git 및 비Git 워크플로우의 배포 방법 분리 및 통합 기능을 제공하는 것 외에도 SiteConfig Operator는 개선된 확장성, 사용자 지정 템플릿을 사용하여 유연성을 높이며 문제 해결 환경을 개선할 수 있습니다.
-
BMC(클러스터 베이스 보드 관리 컨트롤러)의 로그인 정보를 사용하여
5.14.2. 관리형 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
- 설명
업그레이드할 클러스터를 대상으로 하는
Policy
CR(사용자 정의 리소스)에 필요한 버전을 선언하여 OpenShift Container Platform, Day 2 Operator 및 관리형 클러스터 구성을 업그레이드할 수 있습니다.정책 컨트롤러는 정책 준수를 주기적으로 확인합니다. 결과가 음수이면 위반 보고서가 생성됩니다. 정책 수정 작업이 업데이트된 정책에 따라 위반을
적용
하도록 설정된 경우 정책 수정 작업이 알림을 위해 설정된 경우 프로세스는 비준수 상태 보고서로 종료되고 업그레이드를 시작하는 책임은 사용자에게 적절한 유지 관리 기간 중에 수행할 수 있습니다.Topology Aware Lifecycle Manager(TALM)는 클러스터 라이프사이클 전반에 걸쳐 업그레이드 또는 구성 롤아웃을 관리할 수 있는 기능을 통해 RHACM(Red Hat Advanced Cluster Management)을 확장합니다. 점진적으로 제한된 크기의 클러스터 배치에서 작동합니다. OpenShift Container Platform 또는 Day 2 Operator로 업그레이드할 때 TALM은 정책 세트를 단계별로 수행하고 구성을 관리 클러스터로 푸시하기 위해 "enforce" 정책으로 전환하여 업데이트를 점진적으로 롤아웃합니다.
TALM에서 수정 계획을 빌드하는 데 사용하는 CR(사용자 정의 리소스)은
ClusterGroupUpgrade
CR입니다.Lifecycle Agent와 함께 이미지 기반 업그레이드(IBU)를 단일 노드 OpenShift 클러스터 플랫폼 버전의 대체 업그레이드 경로로 사용할 수 있습니다. IBU는 전용 시드 클러스터에서 생성된 OCI 이미지를 사용하여 대상 클러스터에 단일 노드 OpenShift를 설치합니다.
TALM은
ImageBasedGroupUpgrade
CR을 사용하여 식별된 클러스터 세트에 이미지 기반 업그레이드를 롤아웃합니다.- 제한 및 요구사항
-
OpenShift Container Platform <4.y>의 이미지 기반 업그레이드를 사용하여 단일 노드 OpenShift 클러스터에 대한 직접 업그레이드를 <
4.y
+2>로, <4.y
.z>로 <
>까지 직접 업그레이드할 수 있습니다.4.y.z
+n - 이미지 기반 업그레이드는 클러스터가 실행 중인 하드웨어 플랫폼과 관련된 사용자 지정 이미지를 사용합니다. 다른 하드웨어 플랫폼에는 별도의 시드 이미지가 필요합니다.
-
OpenShift Container Platform <4.y>의 이미지 기반 업그레이드를 사용하여 단일 노드 OpenShift 클러스터에 대한 직접 업그레이드를 <
- 엔지니어링 고려 사항
-
에지 배포에서 변경 사항의 타이밍 및 롤아웃을 관리하여 관리되는 클러스터에 대한 중단을 최소화할 수 있습니다. 자동 적용을 트리거하지 않고 규정 준수를 모니터링하도록 모든 정책을 설정합니다.
마찬가지로 예약된 유지 관리 기간 외부에서 업데이트가 발생하지 않도록 수동 2일 Operator 서브스크립션을 구성합니다.
- 단일 노드 OpenShift 클러스터에 권장되는 업그레이드는 이미지 기반 업그레이드입니다.
멀티 노드 클러스터 업그레이드의 경우 다음
MachineConfigPool
CR 구성을 고려하여 업그레이드 시간을 줄입니다.-
paused
필드를true
로 설정하여 유지 관리 기간 동안 노드에 대한 구성 배포를 일시 중지합니다. -
maxUnavailable
필드를 조정하여 풀의 노드 수를 동시에 업데이트할 수 있습니다.MaxUnavailable
필드는MachineConfig
오브젝트 업데이트 중에 동시에 사용할 수 없는 풀의 노드 백분율을 정의합니다.maxUnavailable
을 최대 허용 가능한 값으로 설정합니다. 이렇게 하면 업그레이드 중에 클러스터의 재부팅 횟수가 줄어들어 업그레이드 시간이 단축됩니다. -
paused
필드를false
로 설정하여 구성 배포를 다시 시작합니다. 구성 변경 사항은 단일 재부팅에 적용됩니다.
-
-
클러스터 설치 중에
paused
필드를true
로 설정하고maxUnavailable
을 100%로 설정하여 설치 시간을 단축할 수 있습니다.
-
에지 배포에서 변경 사항의 타이밍 및 롤아웃을 관리하여 관리되는 클러스터에 대한 중단을 최소화할 수 있습니다. 자동 적용을 트리거하지 않고 규정 준수를 모니터링하도록 모든 정책을 설정합니다.
5.15. hub 클러스터 재해 복구 링크 복사링크가 클립보드에 복사되었습니다!
허브 클러스터 손실은 일반적으로 관리 클러스터에서 서비스 중단을 생성하지 않습니다. hub 클러스터에서 제공하는 기능(예: hub 클러스터를 통해 구동되는 관찰 기능, 구성, 라이프사이클 관리 업데이트 등)이 손실됩니다.
- 제한 및 요구사항
- OADP(OpenShift API for Data Protection) Operator에 따라 백업, 복원 및 재해 복구가 클러스터 백업 및 복원 Operator에서 제공합니다.
- 엔지니어링 고려 사항
- 구성에 따라 허브 클러스터의 타사 리소스로 클러스터 백업 및 복원 운영자를 확장할 수 있습니다.
- Red Hat Advanced Cluster Management(RHACM)에서는 클러스터 백업 및 복원 운영자가 기본적으로 활성화되어 있지 않습니다. 참조 구성은 이 기능을 활성화합니다.
5.16. 허브 클러스터 구성 요소 링크 복사링크가 클립보드에 복사되었습니다!
5.16.1. Red Hat 고급 클러스터 관리(RHACM) 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
Red Hat Advanced Cluster Management(RHACM)는 배포된 클러스터에 대한 멀티클러스터 엔진 설치 및 지속적인 수명 주기 관리 기능을 제공합니다. 유지 관리 기간 동안 클러스터에
정책
사용자 정의 리소스(CR)를 적용하여 클러스터 구성과 업그레이드를 선언적으로 관리할 수 있습니다.RHACM은 다음과 같은 기능을 제공합니다.
- RHACM의 멀티클러스터 엔진 구성 요소를 사용하여 클러스터의 제로터치 프로비저닝(ZTP) 및 지속적인 확장을 수행합니다.
- RHACM 정책 컨트롤러를 통한 구성, 업그레이드 및 클러스터 상태.
-
관리형 클러스터 설치 중에 RHACM은
ClusterInstance
CR을 통해 구성된 대로 개별 노드에 레이블을 적용할 수 있습니다. - RHACM의 Topology Aware Lifecycle Manager 구성 요소는 관리되는 클러스터에 대한 구성 변경 사항의 단계적 롤아웃을 제공합니다.
- RHACM 멀티클러스터 엔진 Observability 구성 요소는 선택적 모니터링, 대시보드, 알림 및 메트릭을 제공합니다.
단일 노드 OpenShift 클러스터 설치에 권장되는 방법은 클러스터 정의를 위해
ClusterInstance
CR을 사용하는 멀티클러스터 엔진의 이미지 기반 설치 방법입니다.단일 노드 OpenShift 업그레이드에 권장되는 방법은 이미지 기반 업그레이드 방법입니다.
참고RHACM 멀티클러스터 엔진의 Observability 구성 요소는 모든 관리 클러스터의 상태를 중앙에서 볼 수 있는 기능을 제공합니다. 기본적으로 모든 관리형 클러스터는 클러스터 모니터링 운영자(CMO)가 생성한 메트릭과 알림을 Observability로 다시 보낼 수 있습니다. 자세한 내용은 "관찰성"을 참조하세요.
- 제한 및 요구사항
- 단일 허브 클러스터가 관리하는 클러스터 수 제한에 대한 자세한 내용은 "통신사 관리 허브 클러스터 사용 모델"을 참조하세요.
허브에서 효과적으로 관리할 수 있는 관리형 클러스터의 수는 다음을 포함한 다양한 요소에 따라 달라집니다.
- 각 관리 클러스터의 리소스 가용성
- 정책 복잡성 및 클러스터 크기
- 네트워크 활용도
- 작업량 요구 및 분배
- 허브와 관리되는 클러스터는 충분한 양방향 연결을 유지해야 합니다.
- 엔지니어링 고려 사항
- 클러스터 백업 및 복원 운영자를 구성하여 타사 리소스를 포함할 수 있습니다.
- 정책을 통해 구성을 정의할 때 RHACM 허브 측 템플릿을 사용하는 것이 좋습니다. 이 기능을 사용하면 클러스터별 또는 그룹별로 정책을 활성화하여 함대를 관리하는 데 필요한 정책 수를 줄일 수 있습니다. 예를 들어, 정책에 템플릿으로 지정하고 클러스터나 그룹 기준으로 대체할 지역 또는 하드웨어 유형 콘텐츠입니다.
-
관리형 클러스터에는 일반적으로 개별 클러스터에 특정한 여러 개의 구성 값이 있습니다. 이러한 항목은 클러스터 이름을 기반으로
ConfigMap
CR에서 가져온 값을 사용하는 RHACM 정책 허브 측 템플릿을 사용하여 관리해야 합니다.
5.16.2. 토폴로지 인식 라이프사이클 관리자 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이번 릴리스에는 참조 디자인 업데이트가 없습니다.
- 설명
TALM은 클러스터 업그레이드, 운영자 업그레이드, 클러스터 구성 등의 변경 사항이 네트워크에 어떻게 적용되는지 관리하기 위해 허브 클러스터에서만 실행되는 운영자입니다. TALM은 다음 기능을 지원합니다.
- 사용자가 구성할 수 있는 일괄 처리 방식으로 클러스터 플릿에 대한 정책 업데이트를 점진적으로 출시합니다.
-
클러스터별 작업은 관리되는 클러스터의 구성 변경에 따라
ztp-done
레이블이나 사용자가 구성 가능한 다른 레이블을 추가합니다. TALM은 업그레이드를 시작하기 전에 OpenShift Container Platform, OLM Operator 및 추가 이미지를 단일 노드 OpenShift 클러스터에 사전 캐싱하는 옵션을 지원합니다. 단일 노드 OpenShift 클러스터를 업그레이드하는 데 권장되는 이미지 기반 업그레이드 방법을 사용하는 경우 사전 캐싱 기능은 적용할 수 없습니다.
-
PreCachingConfig
CR을 사용하여 선택적 사전 캐싱 구성을 지정합니다. - 사용하지 않는 콘텐츠를 제외하기 위한 구성 가능한 이미지 필터링.
- 정의된 공간 요구 사항 매개변수를 사용하여 사전 캐싱 전후에 저장소 유효성 검사를 수행합니다.
-
- 제한 및 요구사항
- TALM은 500개 배치 단위로 동시 클러스터 업그레이드를 지원합니다.
- 사전 캐싱은 단일 노드 OpenShift 클러스터 토폴로지로 제한됩니다.
- 엔지니어링 고려 사항
-
PreCachingConfig
사용자 정의 리소스(CR)는 선택 사항입니다. OpenShift Container Platform 및 OLM과 같이 플랫폼 관련 이미지만 사전 캐싱하려는 경우에는 생성할 필요가 없습니다. - TALM은 Red Hat Advanced Cluster Management 정책과 함께 허브 측 템플릿 사용을 지원합니다.
-
5.16.3. GitOps Operator 및 GitOps ZTP 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
GitOps Operator와 GitOps ZTP는 클러스터 배포 및 구성을 관리하기 위한 GitOps 기반 인프라를 제공합니다. 클러스터 정의 및 구성은 Git에서 선언적 상태로 유지됩니다.
SiteConfig
Operator가 이를 설치 CR로 렌더링하는 허브 클러스터에ClusterInstance
사용자 정의 리소스(CR)를 적용할 수 있습니다. 이전 릴리스에서는 GitOps ZTP 플러그인이SiteConfig
CR에서 설치 CR을 생성하는 기능을 지원했습니다. 이 플러그인은 더 이상 사용되지 않습니다.PolicyGenerator
또는PolicyGenTemplate
CR을 기반으로 하는 정책에 구성 CR을 자동으로 래핑하는 기능을 제공하는 별도의 GitOps ZTP 플러그인을 사용할 수 있습니다.기준 참조 구성 CR을 사용하면 관리형 클러스터에 여러 버전의 OpenShift Container Platform을 배포하고 관리할 수 있습니다. 기준 CR과 함께 사용자 정의 CR을 사용할 수 있습니다. 여러 버전별 정책을 동시에 유지하려면 Git에서
PolicyGenerator
또는PolicyGenTemplate
CR을 사용하여 소스 및 정책 CR의 버전을 관리합니다.- 제한 및 요구사항
- 클러스터 또는 노드 삭제 중에 관리되는 클러스터와 관련 리소스를 일관되고 완벽하게 정리하려면 ArgoCD가 백그라운드 삭제 모드를 사용하도록 구성해야 합니다.
- 엔지니어링 고려 사항
-
콘텐츠를 업데이트할 때 혼란이나 의도치 않은 덮어쓰기를 방지하려면
source-crs
디렉터리와 추가 매니페스트에서 사용자 지정 CR에 고유하고 구별 가능한 이름을 사용하세요. - 참조 소스 CR을 사용자 정의 CR과 별도의 디렉토리에 보관하세요. 이를 통해 필요에 따라 참조 CR을 쉽게 업데이트할 수 있습니다.
- 여러 버전을 지원하려면 모든 소스 CR과 정책 생성 CR을 버전이 지정된 Git 저장소에 보관하여 각 OpenShift Container Platform 버전에 대한 정책이 일관되게 생성되도록 합니다.
-
콘텐츠를 업데이트할 때 혼란이나 의도치 않은 덮어쓰기를 방지하려면
5.16.4. Local Storage Operator 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
-
Local Storage Operator를 사용하여 애플리케이션에서
PVC
리소스로 사용할 수 있는 영구 볼륨을 생성할 수 있습니다. 생성하는PV
리소스의 수 및 유형은 요구 사항에 따라 다릅니다. - 엔지니어링 고려 사항
-
영구 볼륨을 생성하기 전에
PV
CR에 대한 백업 스토리지를 생성합니다. 파티션, 로컬 볼륨, LVM 볼륨 또는 전체 디스크일 수 있습니다. -
디스크와 파티션이 올바르게 할당되었는지 확인하려면 각 장치에 액세스하는 데 사용된 하드웨어 경로에 따라
LocalVolume
CR의 장치 목록을 참조하세요(예:/dev/disk/by-path/<id>
). 논리 이름(예:/dev/sda
)은 노드를 재부팅해도 일관성이 보장되지 않습니다.
-
영구 볼륨을 생성하기 전에
5.16.5. Red Hat OpenShift Data Foundation 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- Red Hat OpenShift Data Foundation은 허브 클러스터에 파일, 블록 및 개체 스토리지 서비스를 제공합니다.
- 제한 및 요구사항
- 내부 모드의 Red Hat OpenShift Data Foundation(ODF)에서는 로컬 스토리지 운영자가 필요한 기본 스토리지를 제공하는 스토리지 클래스를 정의해야 합니다.
- 통신사 관리 클러스터를 계획할 때 ODF 인프라와 네트워킹 요구 사항을 고려하세요.
- 듀얼 스택 지원은 제한적입니다. ODF IPv4는 듀얼 스택 클러스터에서 지원됩니다.
- 엔지니어링 고려 사항
- 저장 용량이 고갈되면 복구가 어려울 수 있으므로 용량 경고를 신속하게 처리합니다. 용량 계획을 참조하세요.
5.16.6. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
- 클러스터 로깅 운영자를 사용하여 원격 보관 및 분석을 위해 노드에서 로그를 수집하고 전송합니다. 참조 구성에서는 Kafka를 사용하여 감사 및 인프라 로그를 원격 아카이브로 전송합니다.
- 제한 및 요구사항
- 참조 구성에는 로컬 로그 저장소가 포함되지 않습니다.
- 참조 구성에는 허브 클러스터에서 관리되는 클러스터 로그를 집계하는 기능이 포함되지 않습니다.
- 엔지니어링 고려 사항
- 클러스터 CPU 사용 영향은 생성된 로그 수 또는 크기와 구성된 로그 필터링 양을 기반으로 합니다.
- 참조 구성에는 애플리케이션 로그 전달이 포함되어 있지 않습니다. 구성에 애플리케이션 로그를 포함하려면 애플리케이션 로깅 속도를 평가하고 예약된 세트에 충분한 추가 CPU 리소스를 할당해야 합니다.
5.16.7. 데이터 보호를 위한 OpenShift API 링크 복사링크가 클립보드에 복사되었습니다!
- 이번 릴리스의 새로운 기능
- 이 릴리스에는 참조 디자인 업데이트가 없습니다
- 설명
백업 기능이 활성화되면 OADP(OpenShift API for Data Protection) Operator는 Red Hat Advanced Cluster Management(RHACM)에 의해 자동으로 설치되고 관리됩니다.
OADP 운영자는 OpenShift Container Platform 클러스터에서 워크로드의 백업과 복원을 용이하게 합니다. 업스트림 오픈소스 프로젝트인 Velero를 기반으로, 영구 볼륨을 포함하여 주어진 프로젝트의 모든 Kubernetes 리소스를 백업하고 복원할 수 있습니다.
허브 클러스터에 반드시 있어야 하는 것은 아니지만, 허브 클러스터의 클러스터 백업, 재해 복구 및 고가용성 아키텍처를 위해서는 이를 적극 권장합니다. OADP 운영자는 RHACM에 대한 재해 복구 솔루션을 사용할 수 있어야 합니다. 참조 구성은 RHACM 운영자가 제공하는
MultiClusterHub
사용자 정의 리소스(CR)를 통해 백업(OADP)을 활성화합니다.- 제한 및 요구사항
- 클러스터에는 OADP 버전이 하나만 설치될 수 있습니다. RHACM 재해 복구 기능에는 RHACM이 설치한 버전을 사용해야 합니다.
- 엔지니어링 고려 사항
- 이번 릴리스에는 엔지니어링 고려 사항 업데이트가 없습니다.
5.17. 허브 클러스터 참조 구성 CR 링크 복사링크가 클립보드에 복사되었습니다!
다음은 4.19의 통신사 관리 허브 참조 구성에 대한 모든 사용자 정의 리소스(CR)에 대한 전체 YAML 참조입니다.
5.17.1. RHACM 참조 YAML 링크 복사링크가 클립보드에 복사되었습니다!
acmAgentServiceConfig.yaml
acmMCH.yaml
acmMirrorRegistryCM.yaml
acmNS.yaml
acmOperGroup.yaml
acmPerfSearch.yaml
acmProvisioning.yaml
acmSubscription.yaml
observabilityMCO.yaml
observabilityNS.yaml
observabilityOBC.yaml
observabilitySecret.yaml
thanosSecret.yaml
talmSubscription.yaml
5.17.2. 스토리지 참조 YAML 링크 복사링크가 클립보드에 복사되었습니다!
lsoLocalVolume.yaml
lsoNS.yaml
lsoOperatorgroup.yaml
lsoSubscription.yaml
odfNS.yaml
odfOperatorGroup.yaml
odfSubscription.yaml
storageCluster.yaml
5.17.3. GitOps Operator 및 GitOps ZTP 참조 YAML 링크 복사링크가 클립보드에 복사되었습니다!
argocd-ssh-known-hosts-cm.yaml
gitopsNS.yaml
gitopsOperatorGroup.yaml
gitopsSubscription.yaml
ztp-repo.yaml
app-project.yaml
clusters-app.yaml
gitops-cluster-rolebinding.yaml
gitops-policy-rolebinding.yaml
kustomization.yaml
policies-app-project.yaml
policies-app.yaml
5.17.4. 로깅 참조 YAML 링크 복사링크가 클립보드에 복사되었습니다!
clusterLogNS.yaml
clusterLogOperGroup.yaml
clusterLogSubscription.yaml
5.17.5. 설치 참조 YAML 링크 복사링크가 클립보드에 복사되었습니다!
agent-config.yaml
install-config.yaml
5.18. Telco 허브 참조 구성 소프트웨어 사양 링크 복사링크가 클립보드에 복사되었습니다!
Telco Hub 4.19 솔루션은 OpenShift Container Platform 클러스터용 다음 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.
Component | 소프트웨어 버전 |
---|---|
OpenShift Container Platform | 4.19 |
Local Storage Operator | 4.19 |
Red Hat OpenShift 데이터 파운데이션(ODF) | 4.18 |
Red Hat 고급 클러스터 관리(RHACM) | 2.13 |
Red Hat OpenShift GitOps | 1.16 |
GitOps Zero Touch Provisioning(ZTP) 플러그인 | 4.19 |
멀티클러스터 엔진 Operator PolicyGenerator 플러그인 | 2.13 |
토폴로지 인식 라이프사이클 관리자(TALM) | 4.19 |
Cluster Logging Operator | 6.2 |
데이터 보호를 위한 OpenShift API(OADP) | 해당 버전은 RHACM 릴리스와 일치합니다. |
6장. 클러스터 구성 비교 링크 복사링크가 클립보드에 복사되었습니다!
6.1. 클러스터 비교 플러그인 이해 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 비교
플러그인은 클러스터 구성을 참조 구성과 비교하는 OpenShift CLI( oc
) 플러그인입니다. 이 플러그인은 구성 가능한 검증 규칙과 템플릿을 사용하여 예상되는 변형을 억제하는 동시에 구성 차이점을 보고합니다.
개발, 운영 및 지원 시나리오에서 클러스터 비교
플러그인을 사용하여 참조 구성에 대한 클러스터 준수성을 보장하고 관련 구성 차이점을 빠르게 식별하여 문제를 해결합니다.
6.1.1. 클러스터 비교 플러그인 개요 링크 복사링크가 클립보드에 복사되었습니다!
대규모로 배포된 클러스터는 일반적으로 검증된 기준 사용자 정의 리소스(CR) 세트를 사용하여 클러스터를 구성하여 사용 사례 요구 사항을 충족하고 다양한 환경에 배포할 때 일관성을 보장합니다.
실시간 클러스터에서는 검증된 CR 세트와 다소 차이가 있을 것으로 예상됩니다. 예를 들어, 변수 대체, 선택적 구성 요소 또는 하드웨어별 필드로 인해 구성이 달라질 수 있습니다. 이러한 변화로 인해 클러스터가 기준 구성을 준수하는지 정확하게 평가하기 어렵습니다.
oc
명령과 함께 cluster-compare
플러그인을 사용하면 라이브 클러스터의 구성을 참조 구성과 비교할 수 있습니다. 참조 구성은 기준 구성을 나타내지만 다양한 플러그인 기능을 사용하여 비교 중에 예상되는 변동을 억제합니다. 예를 들어, 유효성 검사 규칙을 적용하고, 선택적 리소스와 필수 리소스를 지정하고, 리소스 간의 관계를 정의할 수 있습니다. 이 플러그인은 관련 없는 차이점을 줄임으로써 기준 구성과 환경 전반에 걸쳐 클러스터 규정 준수를 평가하기 쉽게 해줍니다.
클러스터의 구성을 참조 구성과 지능적으로 비교하는 기능에는 다음과 같은 예시 사용 사례가 있습니다.
프로덕션: 서비스 업데이트, 업그레이드 및 참조 구성 변경 전반에 걸쳐 참조 구성의 규정 준수를 보장합니다.
개발: 테스트 파이프라인에서 참조 구성 준수를 보장합니다.
설계: 일관성을 보장하기 위해 파트너 연구소 참조 구성과 구성을 비교합니다.
지원: 구성 문제를 해결하기 위해 라이브 클러스터에서 수집해야 하는
데이터와 참조 구성을 비교합니다.
그림 6.1. 클러스터 비교 플러그인 개요
6.1.2. 참조 구성 이해 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 비교
플러그인은 참조 구성을 사용하여 라이브 클러스터의 구성을 검증합니다. 참조 구성은 기준 구성을 나타내는 템플릿 세트를 참조하는 metadata.yaml
이라는 YAML 파일로 구성됩니다.
참조 구성을 위한 디렉토리 구조 예
비교하는 동안 플러그인은 각 템플릿을 클러스터의 구성 리소스와 일치시킵니다. 이 플러그인은 Golang 템플릿 구문 및 인라인 정규 표현식 검증과 같은 기능을 사용하여 템플릿의 선택 필드 또는 필수 필드를 평가합니다. metadata.yaml
파일은 템플릿이 선택 사항인지 필수 사항인지 결정하기 위해 추가적인 검증 규칙을 적용하고 템플릿 종속성 관계를 평가합니다.
이러한 기능을 사용하여 플러그인은 클러스터와 참조 구성 간의 관련 구성 차이점을 식별합니다. 예를 들어, 플러그인은 일치하지 않는 필드 값, 누락된 리소스, 추가 리소스, 필드 유형 불일치 또는 버전 불일치를 강조 표시할 수 있습니다.
참조 구성을 구성하는 방법에 대한 자세한 내용은 "참조 구성 만들기"를 참조하세요.
6.2. 클러스터 비교 플러그인 설치 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat 컨테이너 카탈로그의 컨테이너 이미지에서 cluster-compare
플러그인을 추출하여 oc
명령의 플러그인으로 사용할 수 있습니다.
6.2.1. 클러스터 비교 플러그인 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 비교
플러그인을 설치하여 참조 구성을 라이브 클러스터 또는 필수 수집
데이터의 클러스터 구성과 비교합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
podman을
설치했습니다. - Red Hat 컨테이너 카탈로그에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 Red Hat 컨테이너 카탈로그에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
클러스터 비교
이미지에 대한 컨테이너를 만듭니다.podman create --name cca registry.redhat.io/openshift4/kube-compare-artifacts-rhel9:latest
$ podman create --name cca registry.redhat.io/openshift4/kube-compare-artifacts-rhel9:latest
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
cluster-compare
플러그인을PATH
환경 변수에 포함된 디렉토리에 복사합니다.podman cp cca:/usr/share/openshift/<arch>/kube-compare.<rhel_version> <directory_on_path>/kubectl-cluster_compare
$ podman cp cca:/usr/share/openshift/<arch>/kube-compare.<rhel_version> <directory_on_path>/kubectl-cluster_compare
Copy to Clipboard Copied! Toggle word wrap Toggle overflow arch
는 머신의 아키텍처입니다. 유효한 값은 다음과 같습니다.-
linux_amd64
-
linux_arm64
-
linux_ppc64le
-
linux_s390x
-
-
<rhel_version>
은 컴퓨터의 RHEL 버전입니다. 유효한 값은rhel8
또는rhel9
입니다. -
<directory_on_path>
는PATH
환경 변수에 포함된 디렉토리 경로입니다.
검증
다음 명령을 실행하여 플러그인에 대한 도움말을 확인하세요.
oc cluster-compare -h
$ oc cluster-compare -h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.3. 클러스터 비교 플러그인 사용 링크 복사링크가 클립보드에 복사되었습니다!
cluster-compare
플러그인을 사용하면 참조 구성을 라이브 클러스터 또는 필수 수집
데이터의 구성과 비교할 수 있습니다.
6.3.1. 라이브 클러스터와 함께 클러스터 비교 플러그인 사용 링크 복사링크가 클립보드에 복사되었습니다!
cluster-compare
플러그인을 사용하면 참조 구성과 라이브 클러스터의 구성 사용자 정의 리소스(CR)를 비교할 수 있습니다.
설계, 개발 또는 테스트 시나리오에서 참조 구성을 준수하는지 확인하기 위해 라이브 클러스터 구성을 검증합니다.
비운영 환경에서는 라이브 클러스터에만 cluster-compare
플러그인을 사용하세요. 프로덕션 환경에서는 필수 데이터 수집
플러그인을 사용하세요.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
클러스터 비교
플러그인을 다운로드하여PATH
환경 변수에 포함했습니다. - 참조 구성에 액세스할 수 있습니다.
프로세스
다음 명령을 사용하여
cluster-compare
플러그인을 실행합니다.oc cluster-compare -r <path_to_reference_config>/metadata.yaml
$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -r은
참조 구성의metadata.yaml
파일에 대한 경로를 지정합니다. 로컬 디렉토리나 URI를 지정할 수 있습니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 비교 중인 CR입니다. 이 플러그인은 각 CR을 해당 템플릿과 다르게 표시합니다.
- 2
- 비교를 위한 CR과 일치하는 템플릿입니다.
- 3
- Linux diff 형식의 출력은 템플릿과 클러스터 CR의 차이점을 보여줍니다.
- 4
- 플러그인이 각 CR에 대한 줄 차이를 보고한 후, 차이점 요약이 보고됩니다.
- 5
- 해당 템플릿과의 차이점을 비교한 CR의 수입니다.
- 6
- 참조 구성에는 표현되었지만 라이브 클러스터에는 누락된 CR의 수입니다.
- 7
- 참조 구성에 표현되었지만 라이브 클러스터에는 없는 CR 목록입니다.
- 8
- 참조 구성의 해당 템플릿과 일치하지 않는 CR입니다.
- 9
- 메타데이터 해시는 참조 구성을 식별합니다.
- 10
- 패치된 CR 목록입니다.
명령에 -o junit을
추가하면 junit
형식으로 출력을 얻을 수 있습니다. 예를 들면 다음과 같습니다.
oc cluster-compare -r <path_to_reference_config>/metadata.yaml -o junit
$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -o junit
junit
출력에는 다음과 같은 결과 유형이 포함됩니다.
- 완전히 일치된 각 템플릿에 대한 통과 결과입니다.
- 필수 사용자 정의 리소스(CR)가 발견되지 않았거나 누락되어 실패한 결과입니다.
- 사용자 재정의 메커니즘을 사용하여 패치된 차이점에 대한 건너뛴 결과입니다.
6.3.2. 필수 수집 데이터와 함께 클러스터 비교 플러그인 사용 링크 복사링크가 클립보드에 복사되었습니다!
cluster-compare
플러그인을 사용하면 참조 구성을 필수 수집
데이터의 구성 사용자 정의 리소스(CR)와 비교할 수 있습니다.
생산 환경에서 구성 문제를 해결하기 위해 반드시 수집해야 하는
데이터를 사용하여 클러스터 구성을 검증합니다.
프로덕션 환경의 경우 필수 수집
데이터만 포함하는 cluster-compare
플러그인을 사용하세요.
-
대상 클러스터에서
반드시 수집해야 할
데이터에 액세스할 수 있습니다. -
OpenShift CLI(
oc
)를 설치합니다. -
클러스터 비교
플러그인을 다운로드하여PATH
환경 변수에 포함했습니다. - 참조 구성에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여
수집해야 할
데이터를 참조 구성과 비교합니다.oc cluster-compare -r <path_to_reference_config>/metadata.yaml -f "must-gather*/*/cluster-scoped-resources","must-gather*/*/namespaces" -R
$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -f "must-gather*/*/cluster-scoped-resources","must-gather*/*/namespaces" -R
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
-r은
참조 구성의metadata.yaml
파일에 대한 경로를 지정합니다. 로컬 디렉토리나 URI를 지정할 수 있습니다. -
-f는
필수 수집
데이터 디렉토리의 경로를 지정합니다. 로컬 디렉토리나 URI를 지정할 수 있습니다. 이 예제에서는 비교를 관련 클러스터 구성 디렉토리로 제한합니다. -R은
대상 디렉토리를 재귀적으로 검색합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 비교 중인 CR입니다. 이 플러그인은 각 CR을 해당 템플릿과 다르게 표시합니다.
- 2
- 비교를 위한 CR과 일치하는 템플릿입니다.
- 3
- Linux diff 형식의 출력은 템플릿과 클러스터 CR의 차이점을 보여줍니다.
- 4
- 플러그인이 각 CR에 대한 줄 차이를 보고한 후, 차이점 요약이 보고됩니다.
- 5
- 해당 템플릿과의 차이점을 비교한 CR의 수입니다.
- 6
- 참조 구성에는 표현되었지만 라이브 클러스터에는 누락된 CR의 수입니다.
- 7
- 참조 구성에 표현되었지만 라이브 클러스터에는 없는 CR 목록입니다.
- 8
- 참조 구성의 해당 템플릿과 일치하지 않는 CR입니다.
- 9
- 메타데이터 해시는 참조 구성을 식별합니다.
- 10
- 패치된 CR 목록입니다.
-
명령에 -o junit을
추가하면 junit
형식으로 출력을 얻을 수 있습니다. 예를 들면 다음과 같습니다.
oc cluster-compare -r <path_to_reference_config>/metadata.yaml -f "must-gather*/*/cluster-scoped-resources","must-gather*/*/namespaces" -R -o junit
$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -f "must-gather*/*/cluster-scoped-resources","must-gather*/*/namespaces" -R -o junit
junit
출력에는 다음과 같은 결과 유형이 포함됩니다.
- 완전히 일치된 각 템플릿에 대한 통과 결과입니다.
- 필수 사용자 정의 리소스(CR)가 발견되지 않았거나 누락되어 실패한 결과입니다.
- 사용자 재정의 메커니즘을 사용하여 패치된 차이점에 대한 건너뛴 결과입니다.
6.3.3. 참조 클러스터 비교 플러그인 옵션 링크 복사링크가 클립보드에 복사되었습니다!
다음 내용은 클러스터 비교
플러그인의 옵션을 설명합니다.
옵션 | 설명 |
---|---|
| 라이브 클러스터와 함께 사용하는 경우 참조 구성의 유형과 일치하는 클러스터의 모든 리소스를 일치시키려고 시도합니다. 로컬 파일과 함께 사용하는 경우 참조 구성의 유형과 일치하는 로컬 파일의 모든 리소스를 일치시키려고 시도합니다. |
|
라이브 버전의 리소스와 비교할 때 병렬로 처리할 템플릿 수에 대한 정수 값을 지정합니다. 숫자가 클수록 속도는 빨라지지만 해당 기간 동안 메모리, I/O, CPU 사용량도 늘어납니다. 기본값은 |
| 사용자 구성 파일의 경로를 지정합니다. |
| 참조 구성과 비교하는 데 사용할 구성 사용자 정의 리소스에 대한 파일 이름, 디렉토리 또는 URL을 지정합니다. |
| 패치가 필요한 템플릿의 경로를 지정합니다. |
| 사용 가능한 템플릿 기능을 표시합니다. 참고
|
| 도움말 정보를 표시합니다. |
|
|
|
출력 형식을 지정합니다. 옵션에는 |
| 덮어쓰기를 생성하는 이유를 지정합니다. |
| 참조 구성에 대한 패치 덮어쓰기 파일의 경로를 지정합니다. |
|
|
|
참조 구성 |
|
비교에 관리 필드를 포함하려면 |
| 플러그인 출력의 상세 수준을 늘립니다. |
6.3.4. 예: telco 코어 참조 구성으로 클러스터 비교 링크 복사링크가 클립보드에 복사되었습니다!
cluster-compare
플러그인을 사용하여 참조 구성을 라이브 클러스터 또는 must-gather
데이터의 구성과 비교할 수 있습니다.
이 예에서는 라이브 클러스터의 구성을 telco 코어 참조 구성과 비교합니다. 통신 핵심 참조 구성은 telco 코어 참조 사양(RDS)에서 파생됩니다. Telco 코어 RDS는 컨트롤 플레인 및 일부 중앙 집중식 데이터 플레인 기능을 포함한 대규모 통신 애플리케이션을 지원하기 위해 클러스터용으로 설계되었습니다.
참조 구성은 telco core RDS를 사용하여 컨테이너 이미지에 패키지됩니다.
telco core 및 telco RAN distributed unit(DU) 프로필과 함께 cluster-compare
플러그인을 사용하는 추가 예제는 "추가 리소스" 섹션을 참조하십시오.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
registry.redhat.io
컨테이너 이미지 레지스트리에 액세스하기 위한 인증 정보가 있어야 합니다. -
cluster-compare
플러그인이 설치되어 있어야 합니다.
프로세스
다음 명령을 실행하여 인증 정보를 사용하여 컨테이너 이미지 레지스트리에 로그인합니다.
podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
telco-core-rds-rhel9
컨테이너 이미지에서 콘텐츠를 추출합니다.mkdir -p ./out
$ mkdir -p ./out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out
$ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.18 | base64 -d | tar xv -C out
Copy to Clipboard Copied! Toggle word wrap Toggle overflow reference-crs-kube-compare/
디렉터리에서 참조 구성을 볼 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터의 구성을 telco 코어 참조 구성과 비교합니다.
oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml
$ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 비교 중인 CR입니다. 플러그인은 해당 템플릿과 차이가 있는 각 CR을 표시합니다.
- 2
- 비교를 위해 CR과 일치하는 템플릿입니다.
- 3
- Linux diff 형식의 출력은 템플릿과 클러스터 CR의 차이점을 보여줍니다.
- 4
- 플러그인이 각 CR에 대한 줄 diffs를 보고하면 차이점에 대한 요약이 보고됩니다.
- 5
- 해당 템플릿의 차이점과 비교한 CR 수입니다.
- 6
- 참조 구성에 표시되지만 실시간 클러스터에서 누락된 CR 수입니다.
- 7
- 참조 구성에 표시되지만 실시간 클러스터에서 누락된 CR 목록입니다.
- 8
- 참조 구성에서 해당 템플릿과 일치하지 않는 CR입니다.
- 9
- 메타데이터 해시는 참조 구성을 식별합니다.
- 10
- 패치된 CR 목록입니다.
명령에 -o
을 추가하여 junit 형식으로 출력을 가져옵니다. 예를 들면 다음과 같습니다.
junit
oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml -o junit
$ oc cluster-compare -r out/telco-core-rds/configuration/reference-crs-kube-compare/metadata.yaml -o junit
junit
출력에는 다음 결과 유형이 포함됩니다.
- 완전히 일치하는 각 템플릿에 대한 결과를 전달합니다.
- 차이점에 대한 실패한 결과 발견 또는 누락된 CR(사용자 정의 리소스)입니다.
- 사용자 덮어쓰기 메커니즘을 사용하여 패치된 차이에 대해 건너뛰었습니다.
6.4. 참조 구성 생성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터의 구성 리소스의 유효성을 검사하도록 참조 구성을 구성합니다.
6.4.1. metadata.yaml 파일의 구조 링크 복사링크가 클립보드에 복사되었습니다!
metadata.yaml
파일은 참조 구성에서 템플릿을 정의하고 구성하는 중앙 구성 지점을 제공합니다. 파일에는 파트
및 구성 요소의
계층 구조가 있습니다. 파트
는 구성 요소
그룹이며 구성 요소는
템플릿 그룹입니다. 각 구성 요소에서 템플릿 종속 항목, 유효성 검사 규칙을 구성하고 설명 메타데이터를 추가할 수 있습니다.
metadata.yaml 파일의 예
6.4.2. 템플릿 관계 구성 링크 복사링크가 클립보드에 복사되었습니다!
참조 구성에서 템플릿 간의 관계를 정의하면 복잡한 종속 항목이 있는 사용 사례를 지원할 수 있습니다. 예를 들어 특정 템플릿이 필요하거나 그룹에서 하나의 템플릿이 필요하거나 그룹의 템플릿을 허용하도록 구성 요소를 구성할 수 있습니다.
프로세스
사용 사례와 일치시킬
metadata.yaml
파일을 생성합니다. 다음 구조를 예로 사용합니다.metadata.yaml 파일의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 필수 템플릿을 지정합니다.
- 2
- 모든 필수 또는 모든 선택 사항인 템플릿 그룹을 지정합니다. 해당 CR(사용자 정의 리소스)이 클러스터에 있는 경우 해당 CR이 모두 클러스터에 있어야 합니다.
- 3
- 선택적 템플릿을 지정합니다.
- 4
- 제외할 템플릿을 지정합니다. 해당 CR이 클러스터에 있는 경우 플러그인은 검증 오류를 반환합니다.
- 5
- 하나만 있을 수 있는 템플릿을 지정합니다. 해당 CR이 클러스터에 존재하지 않거나 둘 이상의 CR이 있는 경우 플러그인은 검증 오류를 반환합니다.
- 6
- 클러스터에 하나만 있을 수 있는 템플릿을 지정합니다. 해당 CR 중 두 개 이상이 클러스터에 있는 경우 플러그인은 검증 오류를 반환합니다.
6.4.3. 템플릿에서 예상되는 변형 구성 링크 복사링크가 클립보드에 복사되었습니다!
Golang 템플릿 구문을 사용하여 템플릿 내에서 변수 콘텐츠를 처리할 수 있습니다. 이 구문을 사용하면 템플릿 내에서 선택적, 필수 및 조건부 콘텐츠를 처리하는 검증 논리를 구성할 수 있습니다.
-
cluster-compare
플러그인을 사용하려면 모든 템플릿이 유효한 YAML로 렌더링되어야 합니다. 누락된 필드에 대한 오류를 구문 분석하지 않으려면 템플릿 구문을 구현할 때{{- if .spec.<optional_field> }}
와 같은 조건부 템플릿 구문을 사용합니다. 이 조건부 논리를 사용하면 템플릿이 누락된 필드를 정상적으로 처리하고 유효한 YAML 형식을 유지 관리합니다. - 복잡한 사용 사례에 대해 사용자 정의 및 기본 제공 함수와 함께 Golang 템플릿 구문을 사용할 수 있습니다. 모든 Golang 내장 함수는 Sprig 라이브러리의 함수를 포함하여 지원됩니다.
프로세스
사용 사례와 일치시킬
metadata.yaml
파일을 생성합니다. 다음 구조를 예로 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.3.1. 참조 템플릿 기능 링크 복사링크가 클립보드에 복사되었습니다!
cluster-compare
플러그인은 env
및 expandenv
함수를 제외한 모든 sprig
라이브러리 기능을 지원합니다. sprig
라이브러리 함수의 전체 목록은 "Sprig Function Documentation"을 참조하십시오.
다음 표에서는 클러스터
호환 플러그인의 추가 템플릿 기능을 설명합니다.
함수 | 설명 | 예 |
---|---|---|
| 들어오는 문자열을 구조화된 JSON 오브젝트로 구문 분석합니다. |
|
| 들어오는 문자열을 구조화된 JSON 배열로 구문 분석합니다. |
|
| 들어오는 문자열을 구조화된 YAML 오브젝트로 구문 분석합니다. |
|
| 들어오는 문자열을 구조화된 YAML 배열로 구문 분석합니다. |
|
| 오브젝트 유형을 유지하면서 들어오는 데이터를 JSON으로 렌더링합니다. |
|
| 들어오는 문자열을 구조화된 TOML 데이터로 렌더링합니다. |
|
| 오브젝트 유형을 유지하면서 들어오는 데이터를 YAML로 렌더링합니다. |
간단한 스칼라 값의 경우:
목록 또는 사전의 경우: |
|
일반적으로 일치하는 경우에도 템플릿이 클러스터 리소스와 일치하지 않습니다. 템플릿 내에서 이 함수를 사용하여 상관관계에서 특정 리소스를 조건부로 제외할 수 있습니다.
이 기능은 템플릿에서 고정된 이름 또는 네임스페이스를 지정하지 않는 경우 특히 유용합니다. 이러한 경우 |
|
|
지정된 매개 변수와 일치하는 개체 배열을 반환합니다. 예:
| - |
|
매개 변수와 일치하는 단일 오브젝트를 반환합니다. 여러 오브젝트가 일치하면 함수는 아무것도 반환하지 않습니다. 이 함수는 | - |
다음 예제에서는 lookupCRs
함수를 사용하여 일치하는 여러 리소스에서 값을 검색하고 렌더링하는 방법을 보여줍니다.
lookupCR
을 사용하는 구성 맵 예
다음 예제에서는 lookupCR
함수를 사용하여 일치하는 단일 리소스에서 특정 값을 검색하고 사용하는 방법을 보여줍니다.
lookupCR
을 사용하는 구성 맵 예
6.4.4. 템플릿 필드를 제외하도록 metadata.yaml 파일 구성 링크 복사링크가 클립보드에 복사되었습니다!
비교에서 필드를 제외하도록 metadata.yaml
파일을 구성할 수 있습니다. 비교와 관련이 없는 필드(예: 클러스터 구성과 일치하지 않는 주석 또는 레이블)를 제외합니다.
다음과 같은 방법으로 metadata.yaml
파일에서 제외를 구성할 수 있습니다.
- 템플릿에 지정되지 않은 사용자 정의 리소스의 모든 필드를 제외합니다.
pathToKey
필드를 사용하여 정의한 특정 필드를 제외합니다.참고pathToKey
는 점으로 구분된 경로입니다. 마침표를 포함하는 키 값을 이스케이프하려면 따옴표를 사용합니다.
6.4.4.1. 템플릿에 지정되지 않은 모든 필드 제외 링크 복사링크가 클립보드에 복사되었습니다!
비교 프로세스 중에 cluster-compare
플러그인은 해당 CR(사용자 정의 리소스)에서 필드를 병합하여 템플릿을 렌더링합니다. ignore-unspecified-fields
를 true
로 구성하는 경우 CR에 존재하지만 템플릿에는 없는 모든 필드가 병합에서 제외됩니다. 템플릿에 지정된 필드에만 비교하려는 경우 이 방법을 사용합니다.
프로세스
사용 사례와 일치시킬
metadata.yaml
파일을 생성합니다. 다음 구조를 예로 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 해당
namespace.yaml
템플릿에 명시적으로 구성되지 않은 CR의 모든 필드를 비교에서 제외하려면true
를 지정합니다.
6.4.4.2. 기본 제외 필드를 설정하여 특정 필드 제외 링크 복사링크가 클립보드에 복사되었습니다!
defaultOmitRef
필드에서 field ToOmitRefs의 기본값을 정의하여 필드를
제외할 수 있습니다. 이 기본 제외는 특정 템플릿에 대한 config.fieldsToOmitRefs
필드에 의해 재정의되지 않는 한 모든 템플릿에 적용됩니다.
6.4.4.3. 특정 필드 제외 링크 복사링크가 클립보드에 복사되었습니다!
필드의 경로를 정의한 다음 템플릿의 config
섹션에서 정의를 참조하여 제외할 필드를 지정할 수 있습니다.
6.4.4.4. 기본 제외 그룹을 설정하여 특정 필드 제외 링크 복사링크가 클립보드에 복사되었습니다!
제외할 기본 필드 그룹을 생성할 수 있습니다. 제외 그룹은 제외를 정의할 때 복제를 방지하기 위해 다른 그룹을 참조할 수 있습니다.
프로세스
사용 사례와 일치시킬
metadata.yaml
파일을 생성합니다. 다음 구조를 예로 사용합니다.metadata.yaml 파일의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
공통
그룹은 default 그룹에 포함됩니다.
6.4.5. 템플릿 필드에 대한 인라인 검증 구성 링크 복사링크가 클립보드에 복사되었습니다!
인라인 정규식을 활성화하여 템플릿 필드의 유효성을 검증할 수 있습니다. 특히 Golang 템플릿 작성 구문이 유지 관리하거나 지나치게 복잡한 시나리오에서 가능합니다. 인라인 정규식을 사용하면 템플릿을 단순화하고 가독성을 높이며 고급 검증 논리를 허용합니다.
cluster-compare
플러그인은 인라인 검증을 위해 다음 두 가지 기능을 제공합니다.
-
regex
: 정규식을 사용하여 필드의 콘텐츠를 검증합니다. -
capturegroups
: 캡처되지 않은 그룹 텍스트를 정확한 일치로 처리하고, 이름이 지정된 캡처 그룹 내에서만 일치하는 정규식을 적용하고, 반복된 캡처 그룹에 대한 일관성을 보장하여 여러 줄의 텍스트를 비교합니다.
인라인 검증에 regex
또는 capturegroups
함수를 사용하는 경우 cluster-compare
플러그인은 템플릿 내의 여러 필드에서 동일한 이름을 지정하는 캡처 그룹의 값이 동일한 값을 갖습니다. 즉, (?<username>[a-z0-9]+
와 같이 이름이 지정된 캡처 그룹이 여러 필드에 표시되면 해당 그룹의 값이 템플릿 전체에서 일관되게 표시되어야 합니다.
6.4.5.1. regex 함수를 사용하여 인라인 검증 구성 링크 복사링크가 클립보드에 복사되었습니다!
regex
인라인 함수를 사용하여 정규식을 사용하여 필드의 유효성을 검사합니다.
6.4.5.2. 캡처 그룹 함수를 사용하여 인라인 검증 구성 링크 복사링크가 클립보드에 복사되었습니다!
여러 줄 문자열이 포함된 필드를 보다 정확하게 확인하려면 캡처 그룹
인라인 함수를 사용합니다. 이 함수는 또한 이름이 동일한 캡처 그룹이 여러 필드에서 동일한 값을 갖도록 합니다.
프로세스
사용 사례와 일치시킬
metadata.yaml
파일을 생성합니다. 다음 구조를 예로 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 정규식을 사용하여 연결된 템플릿의 필드의 유효성을 검사합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
data.username
필드의 username 값과big CryostatBlock
에서 캡처된 값이 일치하지 않는 경우cluster-compare
플러그인은 일관되지 않은 일치에 대해 경고합니다.
일관성 없는 일치에 대한 경고가 있는 출력 예:
WARNING: Capturegroup (?<username>…) matched multiple values: « mismatchuser | exampleuser »
WARNING: Capturegroup (?<username>…) matched multiple values: « mismatchuser | exampleuser »
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.4.6. 출력에 대한 설명 구성 링크 복사링크가 클립보드에 복사되었습니다!
각 부분, 구성 요소 또는 템플릿에는 추가 컨텍스트, 지침 또는 문서 링크를 제공하는 설명이 포함될 수 있습니다. 이러한 설명은 특정 템플릿 또는 구조가 필요한 이유를 전달하는 데 유용합니다.
프로세스
사용 사례와 일치시킬
metadata.yaml
파일을 생성합니다. 다음 구조를 예로 사용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.5. 고급 참조 구성 사용자 정의 수행 링크 복사링크가 클립보드에 복사되었습니다!
참조 설계에서 임시 편차를 허용하려는 시나리오의 경우 고급 사용자 지정을 적용할 수 있습니다.
이러한 사용자 정의에서는 비교 중에 cluster-compare
플러그인이 사용하는 기본 일치 프로세스를 재정의합니다. 이러한 고급 사용자 정의를 적용할 때는 클러스터 비교에서 결과 정보가 제외되는 등 의도하지 않은 결과가 발생할 수 있으므로 주의해야 합니다.
참조 구성을 동적으로 사용자 지정하는 일부 고급 작업에는 다음이 포함됩니다.
- 수동 일치: 클러스터의 사용자 지정 리소스가 참조 구성의 템플릿으로 수동으로 일치하도록 사용자 구성 파일을 구성합니다.
-
reference :
cluster-compare
명령과 함께 patch 옵션을 사용하여 참조 구성을 구성하기 위한 참조 패치 를 패치합니다.
6.5.1. CR과 템플릿 간의 수동 일치 구성 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 cluster-compare
플러그인의 기본 일치가 예상대로 작동하지 않을 수 있습니다. 사용자 구성 파일을 사용하여 CR(사용자 정의 리소스)이 템플릿에 매핑하는 방법을 수동으로 정의할 수 있습니다.
기본적으로 플러그인은 apiversion
,kind
,name
, namespace
필드를 기반으로 CR을 템플릿에 매핑합니다. 그러나 여러 템플릿이 단일 CR과 일치할 수 있습니다. 예를 들어 다음과 같은 시나리오에서 이러한 문제가 발생할 수 있습니다.
-
동일한
apiversion
,kind
,name
및namespace
필드가 있는 여러 템플릿이 있습니다. -
템플릿은
네임스페이스
또는이름에
관계없이 특정apiversion
및kind
와 모든 CR과 일치합니다.
CR이 여러 템플릿과 일치하면 플러그인은 가장 작은 차이로 템플릿을 선택하는 묶는 메커니즘을 사용합니다. 플러그인이 선택한 템플릿을 명시적으로 제어하려면 수동 일치 규칙을 정의하는 사용자 구성 YAML 파일을 생성할 수 있습니다. 이 구성 파일을 cluster-compare
명령에 전달하여 필요한 템플릿 선택을 적용할 수 있습니다.
프로세스
사용자 구성 파일을 생성하여 수동 일치 기준을 정의합니다.
user-config.yaml
파일 예correlationSettings: manualCorrelation: correlationPairs: ptp.openshift.io/v1_PtpConfig_openshift-ptp_grandmaster: optional/ptp-config/PtpOperatorConfig.yaml ptp.openshift.io/v1_PtpOperatorConfig_openshift-ptp_default: optional/ptp-config/PtpOperatorConfig.yaml
correlationSettings:
1 manualCorrelation:
2 correlationPairs:
3 ptp.openshift.io/v1_PtpConfig_openshift-ptp_grandmaster: optional/ptp-config/PtpOperatorConfig.yaml
4 ptp.openshift.io/v1_PtpOperatorConfig_openshift-ptp_default: optional/ptp-config/PtpOperatorConfig.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
correlationSettings
섹션에는 수동 상관 관계가 있습니다.- 2
manualCorrelation
섹션에서는 수동 상관 관계가 활성화되도록 지정합니다.- 3
correlationPairs
섹션에는 수동으로 일치시킬 CR 및 템플릿 쌍이 나열됩니다.- 4
- 일치시킬 CR과 템플릿 쌍을 지정합니다. CR 사양은 다음 형식을 사용합니다:
<apiversion>_<kind>_<namespace>_<name>
. 네임스페이스가 없는 클러스터 범위 CR의 경우 다음 형식을 사용합니다:<apiversion>_<kind>_<name>
. 템플릿 경로는metadata.yaml
파일을 기준으로 해야 합니다.
다음 명령을 실행하여
cluster-compare
명령에서 사용자 구성 파일을 참조하세요.oc cluster-compare -r <path_to_reference_config>/metadata.yaml -c <path_to_user_config>/user-config.yaml
$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -c <path_to_user_config>/user-config.yaml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
-c
옵션을 사용하여user-config.yaml
파일을 지정합니다.
6.5.2. 참조 구성 패치 링크 복사링크가 클립보드에 복사되었습니다!
특정 시나리오에서는 클러스터 구성에서 예상되는 편차를 처리하기 위해 참조 구성을 패치해야 할 수도 있습니다. 플러그인은 비교 프로세스 중에 패치를 적용하여 패치 파일에 정의된 대로 지정된 리소스 필드를 수정합니다.
예를 들어, 클러스터가 최신 참조 구성과 맞지 않는 더 이상 사용되지 않는 필드를 사용하기 때문에 템플릿에 임시 패치를 적용해야 할 수 있습니다. 패치된 파일은 비교 출력 요약에 보고됩니다.
패치 파일은 두 가지 방법으로 만들 수 있습니다.
-
cluster-compare
플러그인을 사용하여 패치 YAML 파일을 생성합니다. - 나만의 패치 파일을 만드세요.
6.5.2.1. 클러스터 비교 플러그인을 사용하여 패치 생성 링크 복사링크가 클립보드에 복사되었습니다!
cluster-compare
플러그인을 사용하면 특정 템플릿 파일에 대한 패치를 생성할 수 있습니다. 플러그인은 템플릿을 조정하여 클러스터 사용자 정의 리소스(CR)와 일치하도록 합니다. 이전에 패치된 템플릿에서 유효했던 차이점은 보고되지 않습니다. 이 플러그인은 출력에서 패치된 파일을 강조 표시합니다.
프로세스
다음 명령을 실행하여 템플릿에 대한 패치를 생성합니다.
oc cluster-compare -r <path_to_reference_config>/metadata.yaml -o 'generate-patches' --override-reason "A valid reason for the override" --generate-override-for "<template1_path>" --generate-override-for "<template2_path>" > <path_to_patches_file>
$ oc cluster-compare -r <path_to_reference_config>/metadata.yaml -o 'generate-patches' --override-reason "A valid reason for the override" --generate-override-for "<template1_path>" --generate-override-for "<template2_path>" > <path_to_patches_file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
-r은
참조 구성의 metadata.yaml 파일에 대한 경로를 지정합니다. -
-o는
출력 형식을 지정합니다. 패치 출력을 생성하려면generate-patches
값을 사용해야 합니다. -
--override-reason은
패치의 이유를 설명합니다. --generate-override-for는
패치가 필요한 템플릿에 대한 경로를 지정합니다.참고metadata.yaml
파일을 기준으로 대상 템플릿의 파일 경로를 사용해야 합니다. 예를 들어,metadata.yaml
파일의 파일 경로가./compare/metadata.yaml
인 경우 템플릿의 상대 파일 경로는optional/my-template.yaml
이 될 수 있습니다.-
<path_to_patches_file>은
패치의 파일 이름과 경로를 지정합니다.
-
선택 사항: 참조 구성에 적용하기 전에 패치 파일을 검토하세요.
패치 구성
파일 예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 참조 구성에 패치를 적용합니다.
oc cluster-compare -r <referenceConfigurationDirectory> -p <path_to_patches_file>
$ oc cluster-compare -r <referenceConfigurationDirectory> -p <path_to_patches_file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
-r은
참조 구성의 metadata.yaml 파일에 대한 경로를 지정합니다. -p는
패치 파일의 경로를 지정합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
6.5.2.2. 패치 파일을 수동으로 생성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 구성에서 예상되는 편차를 처리하기 위해 패치 파일을 작성할 수 있습니다.
패치에는 유형
필드에 대해 세 가지 가능한 값이 있습니다.
-
mergepatch
- JSON을 대상 템플릿에 병합합니다. 지정되지 않은 필드는 변경되지 않습니다. -
rfc6902
-add
,remove
,replace
,move
,copy
작업을 사용하여 대상 템플릿의 JSON을 병합합니다. 각 작업은 특정 경로를 목표로 합니다. -
go-template
- Golang 템플릿을 정의합니다. 플러그인은 클러스터 사용자 정의 리소스(CR)를 입력으로 사용하여 템플릿을 렌더링하고 대상 템플릿에 대한mergepatch
또는rfc6902
패치를 생성합니다.
다음 예는 세 가지 다른 형식을 모두 사용하여 동일한 패치를 보여줍니다.
프로세스
사용 사례에 맞는 패치 파일을 만듭니다. 다음 구조를 예로 들어 보겠습니다.
패치 구성
예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 패치는
kind
,apiVersion
,name
및namespace
필드를 사용하여 패치를 올바른 클러스터 CR과 일치시킵니다.
다음 명령을 실행하여 참조 구성에 패치를 적용합니다.
oc cluster-compare -r <referenceConfigurationDirectory> -p <path_to_patches_file>
$ oc cluster-compare -r <referenceConfigurationDirectory> -p <path_to_patches_file>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
-r은
참조 구성의 metadata.yaml 파일에 대한 경로를 지정합니다. p는
패치 파일의 경로를 지정합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
6.6. 클러스터 비교 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 비교
플러그인을 사용할 때 여러 클러스터 사용자 정의 리소스(CR)가 있는 경우 거짓 양성 결과나 충돌 등 예상치 못한 결과가 나타날 수 있습니다.
6.6.1. 누락된 리소스에 대한 거짓 양성 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 사용자 정의 리소스(CR)가 클러스터에 있더라도 플러그인은 누락된 리소스를 보고할 수 있습니다.
프로세스
-
클러스터 비교
플러그인의 최신 버전을 사용하고 있는지 확인하세요. 자세한 내용은 "클러스터 비교 플러그인 설치"를 참조하세요. - 최신 버전의 참조 구성을 사용하고 있는지 확인하세요.
-
템플릿에 클러스터 CR과 동일한
apiVersion
,kind
,name
및namespace
필드가 있는지 확인하세요.
6.6.2. 동일한 CR에 대한 여러 템플릿 일치 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
어떤 경우에는 두 개 이상의 클러스터 CR이 동일한 apiVersion
, namespace
, kind를
갖고 있기 때문에 템플릿과 일치할 수 있습니다. 플러그인의 기본 매칭은 가장 차이가 적은 CR을 비교합니다.
선택적으로 참조 구성을 구성하여 이러한 상황을 피할 수 있습니다.
프로세스
-
중복된 템플릿 매칭이 발생하지 않도록 템플릿에 고유한
apiVersion
,namespace
,kind
값이 있는지 확인하세요. - 사용자 구성 파일을 사용하여 템플릿을 CR에 수동으로 일치시킵니다. 자세한 내용은 "CR과 템플릿 간 수동 매칭 구성"을 참조하세요.
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의 클러스터 노드 리소스 소비
- 클러스터 노드 리소스 메모리 소비
7.2. 클러스터 최대값 테스트를 위한 OpenShift Container Platform 환경 및 구성 링크 복사링크가 클립보드에 복사되었습니다!
7.2.1. AWS 클라우드 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
노드 | 플레이버 | vCPU | RAM(GiB) | 디스크 유형 | 디스크 크기(GiB)/IOS | 수량 | 리전 |
---|---|---|---|---|---|---|---|
제어 평면/etcd [1] | r5.4xlarge | 16 | 128 | gp3 | 220 | 3 | us-west-2 |
Infra [2] | m5.12xlarge | 48 | 192 | gp3 | 100 | 3 | us-west-2 |
작업량 [3] | m5.4xlarge | 16 | 64 | gp3 | 500 [4] | 1 | us-west-2 |
Compute | m5.2xlarge | 8 | 32 | gp3 | 100 | 3/25/250/500 [5] | us-west-2 |
- 기준 성능이 3000 IOPS, 초당 125MiB인 gp3 디스크는 etcd가 지연 시간에 민감하기 때문에 제어 평면/etcd 노드에 사용됩니다. gp3 볼륨은 버스트 성능을 사용하지 않습니다.
- 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
- 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
- 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
- 클러스터는 반복적으로 확장되며 성능 및 확장성 테스트는 지정된 노드 수에 따라 실행됩니다.
7.2.2. IBM Power 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
노드 | vCPU | RAM(GiB) | 디스크 유형 | 디스크 크기(GiB)/IOS | 수량 |
---|---|---|---|---|---|
제어 평면/etcd [1] | 16 | 32 | io1 | GiB당 120/10 IOPS | 3 |
Infra [2] | 16 | 64 | gp2 | 120 | 2 |
워크로드 | 16 | 256 | gp2 | 120 [4] | 1 |
Compute | 16 | 64 | gp2 | 120 | 1~5 |
- etcd는 I/O 집약적이고 대기 시간에 민감하므로 GiB당 120/10 IOPS가 있는 io1 디스크는 컨트롤 플레인/etcd 노드에 사용됩니다.
- 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
- 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
- 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
- 클러스터는 반복으로 확장됩니다.
7.2.3. IBM Z 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
노드 | vCPU [4] | RAM(GiB)[5] | 디스크 유형 | 디스크 크기(GiB)/IOS | 수량 |
---|---|---|---|---|---|
컨트롤 플레인/etcd [1,2] | 8 | 32 | ds8k | 300 / LCU 1 | 3 |
Compute 0 | 8 | 32 | ds8k | 150 / LCU 2 | 4개의 노드(노드당 100/250/500 Pod로 스케일링) |
- etcd는 I/O 집약적이고 대기 시간에 민감하므로 컨트롤 플레인/etcd 노드의 디스크 I/O 로드를 최적화하기 위해 두 개의 LCU(Logical Control Unit) 간에 노드가 배포됩니다. etcd I/O 요구 사항은 다른 워크로드를 방해하지 않아야 합니다.
- 4개의 컴퓨팅 노드는 동시에 100/250/500개의 Pod가 있는 여러 반복 실행 테스트에 사용됩니다. 먼저 Pod를 유휴 상태로 설정하여 Pod 인스턴스를 평가할 수 있습니다. 다음으로, 과부하에 따른 시스템의 안정성을 평가하는 데 네트워크 및 CPU가 클라이언트/서버 워크로드를 사용했습니다. 클라이언트 및 서버 pod는 쌍으로 배포되었으며 각 쌍이 두 개의 컴퓨팅 노드에 분배되었습니다.
- 별도의 워크로드 노드가 사용되지 않았습니다. 워크로드는 두 컴퓨팅 노드 간에 마이크로 서비스 워크로드를 시뮬레이션합니다.
- 사용되는 물리적 프로세서 수는 Linux(IFL)에 대한 통합 6개입니다.
- 사용된 총 실제 메모리는 512GiB입니다.
7.3. 테스트된 클러스터 최대값에 따라 환경을 계획하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
노드에서 물리적 리소스에 대한 서브스크립션을 초과하면 Pod를 배치하는 동안 Kubernetes 스케줄러가 보장하는 리소스에 영향을 미칩니다. 메모리 교체가 발생하지 않도록 하기 위해 수행할 수 있는 조치를 알아보십시오.
테스트된 최대값 중 일부는 단일 차원에서만 확장됩니다. 클러스터에서 실행되는 오브젝트가 많으면 최대값이 달라집니다.
이 문서에 명시된 수치는 Red Hat의 테스트 방법론, 설정, 구성, 튜닝을 기반으로 한 것입니다. 고유한 개별 설정 및 환경에 따라 수치가 달라질 수 있습니다.
환경을 계획하는 동안 노드당 몇 개의 Pod가 적합할 것으로 예상되는지 결정하십시오.
required pods per cluster / pods per node = total number of nodes needed
required pods per cluster / pods per node = total number of nodes needed
노드당 기본 최대 Pod 수는 250입니다. 하지만 노드에 적합한 Pod 수는 애플리케이션 자체에 따라 달라집니다. 애플리케이션 요구사항에 따라 환경을 계획하는 방법에 설명된 대로 애플리케이션의 메모리, CPU 및 스토리지 요구사항을 고려하십시오.
시나리오 예
클러스터당 2,200개의 Pod로 클러스터 규모를 지정하려면 노드당 최대 500개의 Pod가 있다고 가정하여 최소 5개의 노드가 있어야 합니다.
2200 / 500 = 4.4
2200 / 500 = 4.4
노드 수를 20으로 늘리면 Pod 배포는 노드당 110개 Pod로 변경됩니다.
2200 / 20 = 110
2200 / 20 = 110
다음과 같습니다.
required pods per cluster / total number of nodes = expected pods per node
required pods per cluster / total number of nodes = expected pods per node
OpenShift Container Platform에는 기본적으로 모든 작업자 노드에서 실행되는 OVN-Kubernetes, DNS, Operator 등과 같은 여러 시스템 Pod가 제공됩니다. 따라서 위의 공식의 결과는 다를 수 있습니다.
7.4. 애플리케이션 요구사항에 따라 환경을 계획하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
예에 나온 애플리케이션 환경을 고려해 보십시오.
Pod 유형 | Pod 수량 | 최대 메모리 | CPU 코어 수 | 영구 스토리지 |
---|---|---|---|---|
apache | 100 | 500MB | 0.5 | 1GB |
node.js | 200 | 1GB | 1 | 1GB |
postgresql | 100 | 1GB | 2 | 10GB |
JBoss EAP | 100 | 1GB | 1 | 1GB |
예상 요구사항은 CPU 코어 550개, RAM 450GB 및 스토리지 1.4TB입니다.
노드의 인스턴스 크기는 기본 설정에 따라 높게 또는 낮게 조정될 수 있습니다. 노드에서는 리소스 초과 커밋이 발생하는 경우가 많습니다. 이 배포 시나리오에서는 동일한 양의 리소스를 제공하는 데 더 작은 노드를 추가로 실행하도록 선택할 수도 있고 더 적은 수의 더 큰 노드를 실행하도록 선택할 수도 있습니다. 운영 민첩성 및 인스턴스당 비용과 같은 요인을 고려해야 합니다.
노드 유형 | 수량 | CPU | RAM(GB) |
---|---|---|---|
노드(옵션 1) | 100 | 4 | 16 |
노드(옵션 2) | 50 | 8 | 32 |
노드(옵션 3) | 25 | 16 | 64 |
어떤 애플리케이션은 초과 커밋된 환경에 적합하지만 어떤 애플리케이션은 그렇지 않습니다. 대부분의 Java 애플리케이션과 대규모 페이지를 사용하는 애플리케이션은 초과 커밋에 적합하지 않은 애플리케이션의 예입니다. 해당 메모리는 다른 애플리케이션에 사용할 수 없습니다. 위의 예에 나온 환경에서는 초과 커밋이 약 30%이며, 이는 일반적으로 나타나는 비율입니다.
애플리케이션 Pod는 환경 변수 또는 DNS를 사용하여 서비스에 액세스할 수 있습니다. 환경 변수를 사용하는 경우 노드에서 Pod가 실행될 때 활성 서비스마다 kubelet을 통해 변수를 삽입합니다. 클러스터 인식 DNS 서버는 새로운 서비스의 Kubernetes API를 확인하고 각각에 대해 DNS 레코드 세트를 생성합니다. 클러스터 전체에서 DNS가 활성화된 경우 모든 Pod가 자동으로 해당 DNS 이름을 통해 서비스를 확인할 수 있어야 합니다. 서비스가 5,000개를 넘어야 하는 경우 DNS를 통한 서비스 검색을 사용할 수 있습니다. 서비스 검색에 환경 변수를 사용하는 경우 네임스페이스에서 서비스가 5,000개를 넘은 후 인수 목록이 허용되는 길이를 초과하면 Pod 및 배포가 실패하기 시작합니다. 이 문제를 해결하려면 배포의 서비스 사양 파일에서 서비스 링크를 비활성화하십시오.
네임스페이스에서 실행할 수 있는 애플리케이션 Pod 수는 서비스 검색에 환경 변수가 사용될 때 서비스 수와 서비스 이름의 길이에 따라 달라집니다. ARG_MAX
는 새로운 프로세스의 최대 인수 길이를 정의하고 기본적으로 2097152 KiB로 설정됩니다. Kubelet은 네임스페이스에서 실행되도록 예약된 각 pod에 환경 변수를 삽입합니다. 여기에는 다음이 포함됩니다.
-
<SERVICE_NAME>_SERVICE_HOST=<IP>
-
<SERVICE_NAME>_SERVICE_PORT=<PORT>
-
<SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
-
<SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
-
<SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
-
<SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
-
<SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>
인수 길이가 허용된 값을 초과하고 서비스 이름의 문자 수에 영향을 미치는 경우 네임스페이스의 Pod가 실패합니다. 예를 들어, 5000개의 서비스가 있는 네임스페이스에서 서비스 이름의 제한은 33자이며, 네임스페이스에서 5000개의 Pod를 실행할 수 있습니다.
8장. 할당량 및 제한 범위 사용 링크 복사링크가 클립보드에 복사되었습니다!
ResourceQuota 오브젝트로 정의하는 리소스 할당량
은 프로젝트당 집계 리소스 사용을 제한하는 제약 조건을 제공합니다. 이를 통해 프로젝트에서 생성할 수 있는 오브젝트의 수량을 유형별로 제한하고 해당 프로젝트의 리소스에서 사용할 수 있는 컴퓨팅 리소스 및 스토리지의 총량도 제한할 수 있습니다.
클러스터 관리자는 할당량 및 제한 범위를 사용하여 프로젝트에 사용되는 오브젝트 수 또는 컴퓨팅 리소스 양을 제한하는 제약 조건을 설정할 수 있습니다. 이렇게 하면 클러스터 관리자가 모든 프로젝트에서 리소스를 보다 효과적으로 관리하고 할당하며 클러스터 크기에 적합한 프로젝트가 없는지 확인할 수 있습니다.
할당량은 클러스터 관리자가 설정하고 지정된 프로젝트로 범위가 지정됩니다. OpenShift Container Platform 프로젝트 소유자는 프로젝트의 할당량을 변경할 수 있지만 범위를 제한할 수는 없습니다. OpenShift Container Platform 사용자는 할당량 또는 제한 범위를 수정할 수 없습니다.
다음 섹션에서는 할당량 및 제한 범위 설정, 제한할 수 있는 작업 종류 및 자체 Pod 및 컨테이너에서 컴퓨팅 리소스를 요청하거나 제한하는 방법을 확인하는 방법을 설명합니다.
8.1. 할당량으로 관리하는 리소스 링크 복사링크가 클립보드에 복사되었습니다!
ResourceQuota 오브젝트로 정의하는 리소스 할당량
은 프로젝트당 집계 리소스 사용을 제한하는 제약 조건을 제공합니다. 이를 통해 프로젝트에서 생성할 수 있는 오브젝트의 수량을 유형별로 제한하고 해당 프로젝트의 리소스에서 사용할 수 있는 컴퓨팅 리소스 및 스토리지의 총량도 제한할 수 있습니다.
다음 내용에서는 할당량으로 관리할 수 있는 컴퓨팅 리소스 및 오브젝트 유형 세트를 설명합니다.
status.phase
이 Failed
또는 Succeeded
인 경우 Pod는 터미널 상태에 있습니다.
리소스 이름 | 설명 |
---|---|
|
터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. |
|
터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. |
|
터미널이 아닌 상태에서 모든 Pod의 로컬 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
|
터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. |
|
터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. |
|
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
| 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다. |
| 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다. |
| 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다. 이 리소스는 임시 스토리지 기술 프리뷰를 활성화한 경우에만 사용할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다. |
리소스 이름 | 설명 |
---|---|
| 상태와 관계없이 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
| 프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다. |
| 상태와 관계없이 일치하는 스토리지 클래스가 있는 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
| 프로젝트에 존재할 수 있는, 일치하는 스토리지 클래스가 있는 총 영구 볼륨 클레임 수입니다. |
리소스 이름 | 설명 |
---|---|
| 프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다. |
| 프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다. |
| 프로젝트에 존재할 수 있는 총 리소스 할당량 수입니다. |
| 프로젝트에 존재할 수 있는 총 서비스 수입니다. |
| 프로젝트에 존재할 수 있는 총 시크릿 수입니다. |
|
프로젝트에 존재할 수 있는 총 |
| 프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다. |
| 프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다. |
count/<resource>.<group>
구문을 사용하여 이러한 표준 네임스페이스 리소스 유형에 대한 개체 수 할당량을 구성할 수 있습니다.
oc create quota <name> --hard=count/<resource>.<group>=<quota>
$ oc create quota <name> --hard=count/<resource>.<group>=<quota>
- 1
<resource>
는 리소스 이름이고<group>
은 API 그룹입니다(해당하는 경우).kubectl api-resources
명령을 사용하면 리소스 목록과 관련 API 그룹을 볼 수 있습니다.
8.1.1. 확장 리소스에 대한 리소스 할당량 설정 링크 복사링크가 클립보드에 복사되었습니다!
확장 리소스에는 리소스 과다 할당이 허용되지 않으므로 할당량의 해당 확장 리소스에 requests
및 limits
를 지정해야 합니다. 현재는 requests.
라는 접두사가 붙은 할당량 항목만 확장 리소스에 허용됩니다. 다음은 GPU 리소스 nvidia.com/gpu
에 대한 리소스 할당량을 설정하는 방법에 대한 예제 시나리오입니다.
프로세스
클러스터의 노드에서 사용 가능한 GPU 수를 확인하려면 다음 명령을 사용하세요.
oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'
$ oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서는 GPU 2개를 사용할 수 있습니다.
이 명령을 사용하여
nvidia
네임스페이스에 할당량을 설정합니다. 이 예에서 할당량은1
입니다.cat gpu-quota.yaml
$ cat gpu-quota.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령으로 할당량을 생성합니다.
oc create -f gpu-quota.yaml
$ oc create -f gpu-quota.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
resourcequota/gpu-quota created
resourcequota/gpu-quota created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 네임스페이스에 올바른 할당량 집합이 있는지 확인하세요.
oc describe quota gpu-quota -n nvidia
$ oc describe quota gpu-quota -n nvidia
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Name: gpu-quota Namespace: nvidia Resource Used Hard -------- ---- ---- requests.nvidia.com/gpu 0 1
Name: gpu-quota Namespace: nvidia Resource Used Hard -------- ---- ---- requests.nvidia.com/gpu 0 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 단일 GPU를 요청하는 Pod를 실행합니다.
oc create pod gpu-pod.yaml
$ oc create pod gpu-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 포드가 실행 중인지 확인하세요.
oc get pods
$ oc get pods
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE gpu-pod-s46h7 1/1 Running 0 1m
NAME READY STATUS RESTARTS AGE gpu-pod-s46h7 1/1 Running 0 1m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
사용된
할당량 카운터가 올바른지 확인하세요.oc describe quota gpu-quota -n nvidia
$ oc describe quota gpu-quota -n nvidia
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Name: gpu-quota Namespace: nvidia Resource Used Hard -------- ---- ---- requests.nvidia.com/gpu 1 1
Name: gpu-quota Namespace: nvidia Resource Used Hard -------- ---- ---- requests.nvidia.com/gpu 1 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여
nvidia
네임스페이스에 두 번째 GPU 포드를 만들어 보세요. 노드에 GPU가 2개 있으므로 기술적으로 가능합니다.oc create -f gpu-pod.yaml
$ oc create -f gpu-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1
Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이
금지
오류 메시지는 GPU 할당량이 1개이고 이 포드가 할당량을 초과하는 두 번째 GPU를 할당하려고 했기 때문에 발생합니다.
8.1.2. 할당량 범위 링크 복사링크가 클립보드에 복사되었습니다!
각 할당량에는 일련의 관련 범위가 있을 수 있습니다. 특정 할당량은 열거된 범위의 교집합과 일치하는 경우에만 리소스 사용량을 측정합니다.
할당량에 범위를 추가하면 할당량을 적용할 수 있는 리소스 세트가 제한됩니다. 허용된 설정을 벗어난 리소스를 지정하면 검증 오류가 발생합니다.
범위 | 설명 |
---|---|
|
|
|
|
|
|
|
|
BestEffort
범위는 할당량을 제한하여 다음 리소스를 제한합니다.
-
pods
Terminating
, NotTerminating
, NotBestEffort
범위는 할당량을 제한하여 다음 리소스를 추적합니다.
-
pods
-
memory
-
requests.memory
-
limits.memory
-
cpu
-
requests.cpu
-
limits.cpu
-
ephemeral-storage
-
requests.ephemeral-storage
-
limits.ephemeral-storage
임시 저장소 요청 및 제한은 임시 저장소 기술 미리 보기를 활성화한 경우에만 적용됩니다. 이 기능은 기본적으로 비활성화되어 있습니다.
추가 리소스
컴퓨팅 리소스에 대한 자세한 내용은 할당량으로 관리되는 리소스를 참조하세요.
컴퓨팅 리소스 커밋에 대한 자세한 내용은 서비스 품질 클래스를 참조하세요.
8.2. 관리자 할당량 사용 링크 복사링크가 클립보드에 복사되었습니다!
8.2.1. 할당량 적용 링크 복사링크가 클립보드에 복사되었습니다!
프로젝트의 리소스 할당량이 처음 생성된 후, 프로젝트는 업데이트된 사용 통계를 계산할 때까지 할당량 제약 조건을 위반할 수 있는 새 리소스를 생성하는 기능을 제한합니다.
할당량이 생성되고 사용량 통계가 업데이트되면 프로젝트에서 새 콘텐츠 생성을 허용합니다. 리소스를 생성하거나 수정할 때는 리소스 생성 또는 수정 요청에 따라 할당량 사용이 즉시 증가합니다.
리소스를 삭제할 때는 프로젝트에 대한 다음 할당량 통계 전체 재계산 중 할당량 사용이 감소합니다.
구성 가능한 시간에 따라 현재 관찰되는 시스템 값으로 할당량 사용을 줄이는 데 걸리는 시간이 결정됩니다.
프로젝트 수정 사항이 할당량 사용 한도를 초과하는 경우, 서버는 해당 작업을 거부하고, 위반된 할당량 제약 조건과 현재 시스템에서 관찰된 사용 통계를 설명하는 적절한 오류 메시지가 사용자에게 반환됩니다.
8.2.2. 요청과 제한 비교 링크 복사링크가 클립보드에 복사되었습니다!
할당량에 따라 컴퓨팅 리소스를 할당할 때 각 컨테이너는 CPU, 메모리, 임시 저장소에 대한 요청과 제한 값을 각각 지정할 수 있습니다. 할당량은 이러한 값 중을 제한할 수 있습니다.
할당량에 requests.cpu
또는 requests.memory
에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스를 명시적으로 요청해야 합니다. 할당량에 limits.cpu
또는 limits.memory
에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스에 대한 제한을 명시적으로 지정해야 합니다.
8.2.3. 리소스 할당량 정의의 예 링크 복사링크가 클립보드에 복사되었습니다!
core-object-counts.yaml 예제
openshift-object-counts.yaml 예시
- 1
- 프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.
예제 compute-resources.yaml
- 1
- 프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.
- 2
- 터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 코어 1개를 초과할 수 없습니다.
- 3
- 터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 1Gi를 초과할 수 없습니다.
- 4
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 2Gi를 초과할 수 없습니다.
- 5
- 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 코어 2개를 초과할 수 없습니다.
- 6
- 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 2Gi를 초과할 수 없습니다.
- 7
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 4Gi를 초과할 수 없습니다.
예시 besteffort.yaml
예제 compute-resources-long-running.yaml
- 1
- 터미널이 아닌 상태의 총 Pod 수입니다.
- 2
- 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
- 3
- 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
- 4
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다.
- 5
- 할당량을
spec.activeDeadlineSeconds
가nil
로 설정된 일치하는 Pod로만 제한합니다. 빌드 Pod는RestartNever
정책을 적용하지 않는 한NotTerminating
에 해당합니다.
예제: compute-resources-time-bound.yaml
- 1
- 터미널이 아닌 상태의 총 Pod 수입니다.
- 2
- 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
- 3
- 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
- 4
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다.
- 5
- 할당량을
spec.activeDeadlineSeconds >=0
인 일치하는 Pod로만 제한합니다. 예를 들어, 이 할당량은 빌드 포드에 대해서는 요금을 청구하지만, 웹 서버나 데이터베이스와 같은 장기 실행 포드에는 요금을 청구하지 않습니다.
storage-consumption.yaml 예시
- 1
- 프로젝트의 총 영구 볼륨 클레임 수
- 2
- 프로젝트의 모든 영구 볼륨 클레임에서 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
- 3
- 프로젝트의 모든 영구 볼륨 클레임에서 골드 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
- 4
- 프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
- 5
- 프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스의 총 클레임 수는 이 값을 초과할 수 없습니다.
- 6
- 프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을
0
으로 설정하면 브론즈 스토리지 클래스에서 스토리지를 요청할 수 없습니다. - 7
- 프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을
0
으로 설정하면 브론즈 스토리지 클래스에서 클레임을 생성할 수 없습니다.
8.2.4. 할당량 생성 링크 복사링크가 클립보드에 복사되었습니다!
할당량을 생성하려면 먼저 파일에 할당량을 정의합니다. 그런 다음 해당 파일을 사용하여 프로젝트에 적용합니다. 이에 대한 설명은 추가 자료 섹션을 참조하세요.
oc create -f <resource_quota_definition> [-n <project_name>]
$ oc create -f <resource_quota_definition> [-n <project_name>]
다음은 core-object-counts.yaml
리소스 할당량 정의와 demoproject
프로젝트 이름을 사용한 예입니다.
oc create -f core-object-counts.yaml -n demoproject
$ oc create -f core-object-counts.yaml -n demoproject
8.2.5. 오브젝트 수 할당량 생성 링크 복사링크가 클립보드에 복사되었습니다!
모든 OpenShift Container Platform 표준 네임스페이스 리소스 유형(예: BuildConfig
, DeploymentConfig
)에 대해 오브젝트 수 할당량을 생성할 수 있습니다. 오브젝트 할당량 수는 모든 표준 네임스페이스 리소스 유형에 정의된 할당량을 지정합니다.
리소스 할당량을 사용할 때 서버 스토리지에 존재하는 경우 오브젝트는 할당량에 대해 부과됩니다. 이러한 유형의 할당량은 스토리지 리소스의 소진을 방지하는 데 유용합니다.
리소스에 대한 개체 수 할당량을 구성하려면 다음 명령을 실행하세요.
oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>
$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>
객체 개수 할당량을 보여주는 예:
이 예제에서는 나열된 리소스가 클러스터에 있는 각 프로젝트의 하드 제한으로 제한됩니다.
8.2.6. 할당량 보기 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔에서 프로젝트의 할당량
페이지로 이동하면 프로젝트 할당량에 정의된 모든 하드 한도와 관련된 사용 통계를 볼 수 있습니다.
CLI를 사용하여 할당량 세부 정보를 볼 수도 있습니다.
먼저, 프로젝트에 정의된 할당량 목록을 가져옵니다. 예를 들어
demoproject
라는 프로젝트의 경우 다음과 같습니다.oc get quota -n demoproject
$ oc get quota -n demoproject NAME AGE besteffort 11m compute-resources 2m core-object-counts 29m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관심 있는 할당량을 입력합니다. 예를 들어
core-object-counts
할당량은 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.7. 할당량 동기화 기간 구성 링크 복사링크가 클립보드에 복사되었습니다!
리소스 세트가 삭제되면 리소스의 동기화 시간대는 /etc/origin/master/master-config.yaml
파일의 resource-quota-sync-period
설정에 따라 결정됩니다.
할당량 사용이 복원되기 전에 사용자는 리소스를 재사용하려고 할 때 문제에 직면할 수 있습니다. 리소스 할당량 동기화 기간
설정을 변경하면 리소스를 다시 사용할 수 있을 때까지 필요한 시간(초) 내에 리소스 집합이 재생성됩니다.
리소스 할당량 동기화 기간
설정 예시
변경 사항을 적용하려면 컨트롤러 서비스를 다시 시작하세요.
master-restart api master-restart controllers
$ master-restart api
$ master-restart controllers
자동화를 사용할 때 재생성 시간을 조정하면 리소스를 생성하고 리소스 사용량을 확인하는 데 도움이 될 수 있습니다.
리소스 할당량 동기화 기간
설정은 시스템 성능을 균형 있게 유지합니다. 동기화 기간을 줄이면 컨트롤러에 큰 부하가 걸릴 수 있습니다.
8.2.8. 리소스를 소비하기 위한 명시적 할당량 링크 복사링크가 클립보드에 복사되었습니다!
리소스가 할당량으로 관리되지 않으면 사용자는 사용할 수 있는 리소스 양에 제한이 없습니다. 예를 들어, 골드 저장 클래스와 관련된 저장 할당량이 없는 경우 프로젝트에서 생성할 수 있는 골드 저장량은 무제한입니다.
고비용 컴퓨팅 또는 스토리지 리소스의 경우 관리자는 리소스를 사용하기 위해 명시적인 할당량을 부여하도록 요구할 수 있습니다. 예를 들어, 프로젝트에 골드 스토리지 클래스와 관련된 스토리지 할당량이 명시적으로 제공되지 않은 경우 해당 프로젝트의 사용자는 해당 유형의 스토리지를 생성할 수 없습니다.
특정 리소스를 사용하기 위해 명시적인 할당량을 요구하려면 다음 구문을 master-config.yaml에 추가해야 합니다.
위의 예에서 할당량 시스템은 PersistentVolumeClaim을
생성하거나 업데이트하는 모든 작업을 가로채고 있습니다. 할당량으로 제어되는 리소스 중 어떤 것이 소모되는지 확인합니다. 해당 프로젝트에 해당 리소스에 대한 할당량이 없는 경우 요청은 거부됩니다. 이 예에서 사용자가 gold 스토리지 클래스와 연결된 스토리지를 사용하는 PersistentVolumeClaim을
생성하고 프로젝트에 일치하는 할당량이 없는 경우 요청은 거부됩니다.
추가 리소스
할당량을 설정하는 데 필요한 파일을 만드는 방법에 대한 예는 할당량으로 관리되는 리소스를 참조하세요.
할당량으로 관리되는 컴퓨팅 리소스를 할당하는 방법에 대한 설명입니다.
프로젝트 리소스에 대한 제한 및 할당량 관리에 대한 자세한 내용은 프로젝트 작업을 참조하세요.
프로젝트에 할당량이 정의된 경우 클러스터 구성의 고려 사항에 대한 배포 이해를 참조하세요.
8.3. 제한 범위 설정 링크 복사링크가 클립보드에 복사되었습니다!
LimitRange
객체로 정의된 제한 범위는 포드, 컨테이너, 이미지, 이미지 스트림 및 영구 볼륨 클레임 수준에서 컴퓨팅 리소스 제약 조건을 정의합니다. 제한 범위는 포드, 컨테이너, 이미지, 이미지 스트림 또는 영구 볼륨 클레임이 사용할 수 있는 리소스 양을 지정합니다.
리소스 생성 및 수정을 위한 모든 요청은 프로젝트의 각 LimitRange
오브젝트에 대해 평가됩니다. 리소스가 열거된 제약 조건을 위반하는 경우 해당 리소스는 거부됩니다. 리소스가 명시적 값을 설정하지 않고 제약 조건이 기본값을 지원하는 경우 기본값이 리소스에 적용됩니다.
CPU 및 메모리 제한의 경우 최대값은 지정하고 최소값은 지정하지 않으면 리소스가 최대값보다 더 많은 CPU 및 메모리 리소스를 소모할 수 있습니다.
코어 한계 범위 객체 정의
- 1
- 제한 범위 오브젝트의 이름입니다.
- 2
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 최대 CPU 양입니다.
- 3
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 최대 메모리 양입니다.
- 4
- 모든 컨테이너의 노드에서 포드가 요청할 수 있는 최소 CPU 양입니다.
최소값
을 설정하지 않거나최소값을
0
으로 설정하면 제한이 없어지고 Pod는최대
CPU 값보다 더 많은 CPU를 소비할 수 있습니다. - 5
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 최소 메모리 양입니다.
최소값
을 설정하지 않거나최소값을
0
으로 설정하면 제한이 없어지고 Pod는최대
메모리 값보다 더 많은 메모리를 사용할 수 있습니다. - 6
- Pod의 단일 컨테이너에서 요청할 수 있는 최대 CPU 양입니다.
- 7
- Pod의 단일 컨테이너에서 요청할 수 있는 최대 메모리 양입니다.
- 8
- Pod의 단일 컨테이너에서 요청할 수 있는 최소 CPU 양입니다.
최소값
을 설정하지 않거나최소값을
0
으로 설정하면 제한이 없어지고 Pod는최대
CPU 값보다 더 많은 CPU를 소비할 수 있습니다. - 9
- Pod의 단일 컨테이너에서 요청할 수 있는 최소 메모리 양입니다.
최소값
을 설정하지 않거나최소값을
0
으로 설정하면 제한이 없어지고 Pod는최대
메모리 값보다 더 많은 메모리를 사용할 수 있습니다. - 10
- Pod 사양에 제한을 지정하지 않으면 컨테이너의 기본 CPU 제한이 적용됩니다.
- 11
- Pod 사양에 제한을 지정하지 않으면 컨테이너의 기본 메모리 제한이 적용됩니다.
- 12
- Pod 사양에서 요청을 지정하지 않을 경우 컨테이너의 기본 CPU 요청입니다.
- 13
- Pod 사양에서 요청을 지정하지 않을 경우 컨테이너의 기본 메모리 요청입니다.
- 14
- 컨테이너에 대한 최대 제한 대 요청 비율입니다.
OpenShift 컨테이너 플랫폼 제한 범위 객체 정의
- 1
- 내부 레지스트리로 내보낼 수 있는 이미지의 최대 크기입니다.
- 2
- 이미지 스트림에 대한 사양에 정의된 고유 이미지 태그의 최대 개수입니다.
- 3
- 이미지 스트림 상태에 대한 사양에 정의된 고유 이미지 참조의 최대 수입니다.
- 4
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 최대 CPU 양입니다.
- 5
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 최대 메모리 양입니다.
- 6
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 임시 저장소의 최대 크기입니다.
- 7
- 모든 컨테이너의 노드에서 포드가 요청할 수 있는 최소 CPU 양입니다. 중요한 정보는 지원되는 제약 조건 표를 참조하세요.
- 8
- 모든 컨테이너에 걸쳐 노드에서 포드가 요청할 수 있는 최소 메모리 양입니다.
최소값
을 설정하지 않거나최소값을
0
으로 설정하면 결과에는 제한이 없으며 Pod는최대
메모리 값보다 더 많은 메모리를 사용할 수 있습니다.
하나의 제한 범위 객체에서 코어 리소스와 OpenShift Container Platform 리소스를 모두 지정할 수 있습니다.
8.3.1. 컨테이너 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- CPU
- 메모리
지원되는 제약 조건
컨테이너별로 다음 사항이 지정된 경우 반드시 참이어야 합니다.
컨테이너
강제 | 동작 |
---|---|
|
구성에서 |
|
구성에서 |
|
제한 범위가
예를 들어 컨테이너의 |
지원되는 기본값:
Default[<resource>]
-
값이 없는 경우,
container.resources.limit[<resource>]을
지정된 값으로 기본 설정합니다. 기본 요청[<리소스>]
-
값이 없는 경우,
container.resources.requests[<resource>]를
지정된 값으로 기본 설정합니다.
8.3.2. Pod 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- CPU
- 메모리
지원되는 제약 조건:
Pod의 모든 컨테이너에서 다음 사항이 충족되어야 합니다.
강제 | 강제된 행동 |
---|---|
|
|
|
|
|
|
8.3.3. 이미지 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- 스토리지
리소스 유형 이름:
-
openshift.io/이미지
이미지별로 다음 사항이 지정된 경우 반드시 참이어야 합니다.
강제 | 동작 |
---|---|
|
|
한도를 초과하는 블롭이 레지스트리에 업로드되는 것을 방지하려면 레지스트리를 구성하여 할당량을 적용해야 합니다. REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA
환경 변수는 true
로 설정해야 합니다. 기본적으로 환경 변수는 새로운 배포의 경우 true
로 설정됩니다.
8.3.4. 이미지 스트림 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
-
openshift.io/image-tags
-
openshift.io/images
리소스 유형 이름:
-
openshift.io/ImageStream
이미지 스트림별로 다음 사항이 지정된 경우 반드시 참이어야 합니다.
강제 | 동작 |
---|---|
|
|
|
|
8.3.5. 이미지 참조 계산 링크 복사링크가 클립보드에 복사되었습니다!
openshift.io/image-tags
리소스는 고유한 스트림 제한을 나타냅니다. 가능한 참조는 ImageStreamTag
, ImageStreamImage
또는 DockerImage
입니다. 태그는 oc tag
및 oc import-image
명령을 사용하거나 이미지 스트림을 사용하여 생성할 수 있습니다. 내부 참조와 외부 참조는 구분되지 않습니다. 그러나 이미지 스트림 사양에 태그가 지정된 각 고유 참조는 한 번만 계산됩니다. 내부 컨테이너 이미지 레지스트리에 대한 내보내기는 어떤 방식으로든 제한하지 않지만 태그 제한에 유용합니다.
openshift.io/images
리소스는 이미지 스트림 상태에 기록된 고유한 이미지 이름을 나타냅니다. 내부 레지스트리로 내보낼 수 있는 여러 이미지를 제한하는 데 도움이 됩니다. 내부 및 외부 참조는 구분되지 않습니다.
8.3.6. PersistentVolumeClaim 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- 스토리지
지원되는 제한 사항:
프로젝트의 모든 영구 볼륨 클레임에서 다음 사항이 충족되어야 합니다.
제약 조건 | 강제 동작 |
---|---|
| min[<resource>] <= claim.spec.resources.requests[<resource>] (필수) |
| claim.spec.resources.requests[<resource>] (필수) <= Max[<resource>] |
제한 범위 오브젝트 정의
추가 리소스
스트림 제한에 대한 자세한 내용은 이미지 스트림 관리를 참조하세요.
스트림 제한 에 대한 정보.
컴퓨팅 리소스 제약 에 대한 자세한 내용은 다음을 참조하세요.
CPU와 메모리가 측정되는 방법에 대한 자세한 내용은 권장되는 제어 평면 사례를 참조하세요.
임시 저장소에 대한 제한과 요청을 지정할 수 있습니다. 이 기능에 대한 자세한 내용은 임시 저장소 이해를 참조하세요.
8.4. 범위 제한 작업 링크 복사링크가 클립보드에 복사되었습니다!
8.4.1. 제한 범위 생성 링크 복사링크가 클립보드에 복사되었습니다!
여기에는 제한 범위를 생성하는 절차의 예가 나와 있습니다.
프로세스
오브젝트를 생성합니다.
oc create -f <limit_range_file> -n <project>
$ oc create -f <limit_range_file> -n <project>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.2. 한도 보기 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔에서 프로젝트의 할당량
페이지로 이동하면 프로젝트에 정의된 모든 제한 범위를 볼 수 있습니다. 다음 단계를 수행하여 CLI를 사용하여 제한 범위 세부 정보를 볼 수도 있습니다.
프로세스
프로젝트에 정의된 제한 범위 객체 목록을 가져옵니다. 예를 들어,
demoproject
라는 프로젝트가 있습니다.oc get limits -n demoproject
$ oc get limits -n demoproject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE resource-limits 6d
NAME AGE resource-limits 6d
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 한계 범위를 설명하세요. 예를 들어,
resource-limits
라는 제한 범위의 경우:oc describe limits resource-limits -n demoproject
$ oc describe limits resource-limits -n demoproject
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4.3. 제한 범위 삭제 링크 복사링크가 클립보드에 복사되었습니다!
제한 범위를 제거하려면 다음 명령을 실행하세요.
+
oc delete limits <limit_name>
$ oc delete limits <limit_name>
S
추가 리소스
사용자가 생성할 수 있는 프로젝트 수에 다양한 제한을 적용하고, 제한을 관리하고, 프로젝트 리소스에 대한 할당량을 설정하는 방법에 대한 자세한 내용은 프로젝트당 리소스 할당량을 참조하세요.
9장. IBM Z 및 IBM LinuxONE 환경에 권장되는 호스트 사례 링크 복사링크가 클립보드에 복사되었습니다!
이 주제에서는 IBM Z® 및 IBM® LinuxONE의 OpenShift Container Platform에 대한 권장 호스트 사례를 제공합니다.
s390x 아키텍처는 여러 면에서 독특합니다. 따라서 여기에 제시된 일부 권장 사항은 다른 플랫폼에는 적용되지 않을 수 있습니다.
달리 명시하지 않는 한 이러한 관행은 IBM Z® 및 IBM® LinuxONE의 z/VM과 Red Hat Enterprise Linux(RHEL) KVM 설치에 모두 적용됩니다.
9.1. CPU 과잉 할당 관리 링크 복사링크가 클립보드에 복사되었습니다!
고도로 가상화된 IBM Z® 환경에서 인프라 설정 및 크기를 신중하게 계획해야 합니다. 가상화의 가장 중요한 기능 중 하나는 리소스 과잉 할당 기능으로, 하이퍼바이저 수준에서 실제로 사용 가능한 것보다 더 많은 리소스를 가상 머신에 할당합니다. 이는 작업 부하에 따라 크게 달라지며 모든 설정에 적용할 수 있는 황금률은 없습니다.
설정에 따라 CPU 과잉 사용과 관련하여 다음과 같은 모범 사례를 고려하세요.
- LPAR 수준(PR/SM 하이퍼바이저)에서는 사용 가능한 모든 물리적 코어(IFL)를 각 LPAR에 할당하지 마십시오. 예를 들어 4개의 물리적 IFL을 사용할 수 있는 경우 각각 4개의 논리 IFL을 사용하여 3개의 LPAR을 정의해서는 안 됩니다.
- LPAR 점유율과 가중치를 확인하고 이해하세요.
- 가상 CPU 수가 너무 많으면 성능에 부정적인 영향을 미칠 수 있습니다. LPAR에 정의된 논리 프로세서보다 많은 가상 프로세서를 게스트에 정의하지 마세요.
- 최대 작업 부하에 맞춰 게스트당 가상 프로세서 수를 구성하세요. 그 이상은 안 됩니다.
- 작은 규모로 시작하고 작업량을 모니터링하세요. 필요한 경우 vCPU 수를 점진적으로 늘리세요.
- 모든 워크로드가 높은 오버 커밋 비율에 적합한 것은 아닙니다. 작업 부하가 CPU를 많이 사용하는 경우 성능 문제 없이 높은 비율을 달성하는 것은 어려울 수 있습니다. I/O 집약도가 높은 작업 부하는 높은 과잉 커밋 비율에도 일관된 성능을 유지할 수 있습니다.
9.2. 투명 거대 페이지 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
투명 거대 페이지(THP)는 거대한 페이지를 만들고, 관리하고, 사용하는 대부분의 측면을 자동화하려고 시도합니다. THP는 자동으로 방대한 페이지를 관리하므로 모든 유형의 작업 부하에서 항상 최적으로 처리되는 것은 아닙니다. THP는 많은 애플리케이션이 스스로 거대한 페이지를 처리하기 때문에 성능 저하로 이어질 수 있습니다. 따라서 THP를 비활성화하는 것을 고려하세요.
9.3. Receive Flow Steering으로 네트워킹 성능 향상 링크 복사링크가 클립보드에 복사되었습니다!
RFS(수신 흐름 스티어링)는 네트워크 지연 시간을 더욱 줄여 RPS(수신 패킷 스티어링)를 확장합니다. RFS는 기술적으로 RPS를 기반으로 하며 CPU 캐시 적중률을 증가시켜 패킷 처리의 효율성을 향상시킵니다. RFS는 이를 달성하고, 추가로 대기열 길이를 고려하여 계산에 가장 편리한 CPU를 결정함으로써 캐시 적중이 CPU 내에서 발생할 가능성이 더 높아집니다. 따라서 CPU 캐시의 무효화가 줄어들고 캐시를 재구축하는 데 필요한 사이클도 줄어듭니다. 이렇게 하면 패킷 처리 실행 시간을 줄일 수 있습니다.
9.3.1. RFS를 활성화하려면 MCO(Machine Config Operator)를 사용하세요. 링크 복사링크가 클립보드에 복사되었습니다!
프로세스
다음 MCO 샘플 프로필을 YAML 파일에 복사합니다. 예를 들어,
enable-rfs.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow MCO 프로필을 생성하세요.
oc create -f enable-rfs.yaml
$ oc create -f enable-rfs.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 50-enable-rfs
라는 항목이 나열되어 있는지 확인하세요.oc get mc
$ oc get mc
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 비활성화하려면 다음을 입력하세요.
oc delete mc 50-enable-rfs
$ oc delete mc 50-enable-rfs
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.4. 네트워킹 설정을 선택하세요 링크 복사링크가 클립보드에 복사되었습니다!
네트워킹 스택은 OpenShift Container Platform과 같은 Kubernetes 기반 제품의 가장 중요한 구성 요소 중 하나입니다. IBM Z® 설정의 경우, 네트워킹 설정은 선택한 하이퍼바이저에 따라 달라집니다. 워크로드 및 애플리케이션에 따라 가장 적합한 것은 일반적으로 사용 사례 및 트래픽 패턴에 따라 변경됩니다.
설정에 따라 다음 모범 사례를 고려하십시오.
- 트래픽 패턴을 최적화하기 위해 네트워킹 장치와 관련된 모든 옵션을 고려하십시오. OSA-Express, RoCE Express, HiperSockets, z/VM VSwitch, Linux Bridge(KVM)의 이점을 살펴보고 어떤 옵션을 설정하는데 가장 큰 이점이 있는지 확인하십시오.
- 항상 최신 NIC 버전을 사용하세요. 예를 들어, OSA Express 7S 10 GbE는 둘 다 10 GbE 어댑터이기는 하지만 트랜잭션 워크로드 유형에서 OSA Express 6S 10 GbE에 비해 큰 개선을 보여줍니다.
- 각 가상 스위치는 추가 대기 시간 계층을 추가합니다.
- 로드 밸런서는 클러스터 외부의 네트워크 통신에 중요한 역할을 합니다. 애플리케이션에 중요한 경우 프로덕션 등급 하드웨어 로드 밸런서를 사용하는 것을 고려하세요.
- OpenShift Container Platform OVN-Kubernetes 네트워크 플러그인은 네트워킹 성능에 영향을 미치는 흐름과 규칙을 도입합니다. 의사소통이 중요한 서비스의 현지성을 활용하려면 포드 친화성과 배치를 고려해야 합니다.
- 성능과 기능 간의 균형을 맞추세요.
9.5. z/VM에서 HyperPAV를 사용하여 높은 디스크 성능 보장 링크 복사링크가 클립보드에 복사되었습니다!
DASD 및 ECKD 장치는 IBM Z® 환경에서 일반적으로 사용되는 디스크 유형입니다. z/VM 환경에서 일반적인 OpenShift Container Platform 설정에서는 DASD 디스크가 일반적으로 노드의 로컬 스토리지를 지원하는 데 사용됩니다. z/VM 게스트를 지원하는 DASD 디스크에 더 많은 처리량과 전반적인 더 나은 I/O 성능을 제공하기 위해 HyperPAV 별칭 장치를 설정할 수 있습니다.
로컬 저장 장치에 HyperPAV를 사용하면 성능이 크게 향상됩니다. 하지만 처리량과 CPU 비용 사이에는 상충 관계가 있다는 점을 알아야 합니다.
9.5.1. z/VM 전체 팩 미니디스크를 사용하는 노드에서 HyperPAV 별칭을 활성화하려면 MCO(Machine Config Operator)를 사용하십시오. 링크 복사링크가 클립보드에 복사되었습니다!
전체 팩 미니디스크를 사용하는 z/VM 기반 OpenShift Container Platform 설정의 경우 모든 노드에서 HyperPAV 별칭을 활성화하여 MCO 프로필의 이점을 활용할 수 있습니다. 제어 평면과 컴퓨팅 노드 모두에 YAML 구성을 추가해야 합니다.
프로세스
다음 MCO 샘플 프로필을 제어 평면 노드의 YAML 파일에 복사합니다. 예를 들어,
05-master-kernelarg-hpav.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 MCO 샘플 프로필을 컴퓨팅 노드의 YAML 파일에 복사합니다. 예를 들어,
05-worker-kernelarg-hpav.yaml
:Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고장치 ID에 맞게
rd.dasd
인수를 수정해야 합니다.MCO 프로필을 만듭니다.
oc create -f 05-master-kernelarg-hpav.yaml
$ oc create -f 05-master-kernelarg-hpav.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f 05-worker-kernelarg-hpav.yaml
$ oc create -f 05-worker-kernelarg-hpav.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 비활성화하려면 다음을 입력하세요.
oc delete -f 05-master-kernelarg-hpav.yaml
$ oc delete -f 05-master-kernelarg-hpav.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete -f 05-worker-kernelarg-hpav.yaml
$ oc delete -f 05-worker-kernelarg-hpav.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.6. IBM Z 호스트 권장 사항의 RHEL KVM 링크 복사링크가 클립보드에 복사되었습니다!
KVM 가상 서버 환경을 최적화하는 것은 가상 서버의 작업 부하와 사용 가능한 리소스에 따라 크게 달라집니다. 어떤 환경에서는 성과를 향상시키는 효과가 있는 행동이 다른 환경에서는 부정적인 영향을 미칠 수 있습니다. 특정한 환경에 가장 적합한 균형을 찾는 것은 어려울 수 있으며, 종종 실험이 필요합니다.
다음 섹션에서는 IBM Z® 및 IBM® LinuxONE 환경에서 RHEL KVM과 함께 OpenShift Container Platform을 사용할 때의 몇 가지 모범 사례를 소개합니다.
9.6.1. 가상 블록 장치에 I/O 스레드 사용 링크 복사링크가 클립보드에 복사되었습니다!
가상 블록 장치가 I/O 스레드를 사용하도록 하려면 가상 서버와 각 가상 블록 장치에 대해 하나 이상의 I/O 스레드를 구성하여 이러한 I/O 스레드 중 하나를 사용해야 합니다.
다음 예제에서는 연속 10진수 스레드 ID 1, 2, 3으로 세 개의 I/O 스레드를 구성하려면 <iothreads>3</iothreads>
를 지정합니다. iothread="2"
매개변수는 ID 2의 I/O 스레드를 사용하기 위해 디스크 장치의 드라이버 요소를 지정합니다.
샘플 I/O 스레드 사양
스레드는 디스크 장치의 I/O 작업 성능을 높일 수 있지만 메모리와 CPU 리소스도 사용합니다. 여러 장치가 동일한 스레드를 사용하도록 구성할 수 있습니다. 스레드와 장치를 가장 잘 매핑하는 방법은 사용 가능한 리소스와 작업 부하에 따라 달라집니다.
적은 수의 I/O 스레드로 시작하세요. 대개 모든 디스크 장치에 대해 단일 I/O 스레드가 충분합니다. 가상 CPU 수보다 많은 스레드를 구성하지 말고, 유휴 스레드도 구성하지 마세요.
virsh iothreadadd
명령을 사용하면 실행 중인 가상 서버에 특정 스레드 ID를 가진 I/O 스레드를 추가할 수 있습니다.
9.6.2. 가상 SCSI 장치 방지 링크 복사링크가 클립보드에 복사되었습니다!
SCSI 특정 인터페이스를 통해 장치를 처리해야 하는 경우에만 가상 SCSI 장치를 구성하세요. 호스트의 백업에 관계없이 디스크 공간을 가상 SCSI 장치가 아닌 가상 블록 장치로 구성합니다.
하지만 다음과 같은 경우 SCSI 전용 인터페이스가 필요할 수 있습니다.
- 호스트의 SCSI 연결 테이프 드라이브에 대한 LUN입니다.
- 가상 DVD 드라이브에 마운트된 호스트 파일 시스템의 DVD ISO 파일입니다.
9.6.3. 디스크에 대한 게스트 캐싱 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스트가 아닌 게스트가 캐싱하도록 디스크 장치를 구성합니다.
디스크 장치의 드라이버 요소에 cache="none"
및 io="native"
매개변수가 포함되어 있는지 확인하세요.
<disk type="block" device="disk"> <driver name="qemu" type="raw" cache="none" io="native" iothread="1"/> ... </disk>
<disk type="block" device="disk">
<driver name="qemu" type="raw" cache="none" io="native" iothread="1"/>
...
</disk>
9.6.4. 메모리 풍선 장치 제외 링크 복사링크가 클립보드에 복사되었습니다!
동적 메모리 크기가 필요하지 않다면 메모리 풍선 장치를 정의하지 말고 libvirt가 메모리 풍선 장치를 자동으로 생성하지 않도록 하세요. 도메인 구성 XML 파일에 있는 devices 요소의 자식으로 memballoon
매개변수를 포함합니다.
활성 프로필 목록을 확인하세요.
<memballoon model="none"/>
<memballoon model="none"/>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9.6.5. 호스트 스케줄러의 CPU 마이그레이션 알고리즘을 조정합니다. 링크 복사링크가 클립보드에 복사되었습니다!
영향을 이해하는 전문가가 아니면 스케줄러 설정을 변경하지 마세요. 테스트를 거쳐 의도한 효과가 나타나는지 확인하지 않고 프로덕션 시스템에 변경 사항을 적용하지 마세요.
kernel.sched_migration_cost_ns
매개변수는 나노초 단위의 시간 간격을 지정합니다. 작업을 마지막으로 실행한 후 이 간격이 만료될 때까지 CPU 캐시가 유용한 콘텐츠로 간주됩니다. 이 간격을 늘리면 작업 마이그레이션이 줄어듭니다. 기본값은 500000ns입니다.
실행 가능한 프로세스가 있을 때 CPU 유휴 시간이 예상보다 길다면 이 간격을 줄여보세요. 작업이 CPU나 노드 간에 너무 자주 전환되는 경우, 이 값을 늘려보세요.
간격을 60000ns로 동적으로 설정하려면 다음 명령을 입력하세요.
sysctl kernel.sched_migration_cost_ns=60000
# sysctl kernel.sched_migration_cost_ns=60000
값을 지속적으로 60000ns로 변경하려면 /etc/sysctl.conf
에 다음 항목을 추가합니다.
kernel.sched_migration_cost_ns=60000
kernel.sched_migration_cost_ns=60000
9.6.6. cpuset cgroup 컨트롤러 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
이 설정은 cgroups 버전 1이 있는 KVM 호스트에만 적용됩니다. 호스트에서 CPU 핫플러그를 활성화하려면 cgroup 컨트롤러를 비활성화하세요.
프로세스
-
원하는 편집기로
/etc/libvirt/qemu.conf를
엽니다. -
cgroup_controllers
라인으로 이동합니다. - 줄 전체를 복제한 다음 복사본에서 앞에 있는 숫자 기호(#)를 제거합니다.
다음과 같이
cpuset
항목을 제거합니다.cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuacct" ]
cgroup_controllers = [ "cpu", "devices", "memory", "blkio", "cpuacct" ]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새로운 설정을 적용하려면 libvirtd 데몬을 다시 시작해야 합니다.
- 모든 가상 머신을 중지합니다.
다음 명령을 실행합니다.
systemctl restart libvirtd
# systemctl restart libvirtd
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 가상 머신을 다시 시작합니다.
이 설정은 호스트를 재부팅해도 유지됩니다.
9.6.7. 유휴 가상 CPU에 대한 폴링 기간 조정 링크 복사링크가 클립보드에 복사되었습니다!
가상 CPU가 유휴 상태가 되면 KVM은 호스트 리소스를 할당하기 전에 가상 CPU에 대한 웨이크업 조건을 폴링합니다. /sys/module/kvm/parameters/halt_poll_ns
에서 sysfs에서 폴링이 발생하는 시간 간격을 지정할 수 있습니다. 지정된 시간 동안 폴링은 리소스 사용을 희생하여 가상 CPU의 웨이크업 지연 시간을 줄입니다. 작업량에 따라, 여론조사 시간을 늘리거나 줄이는 것이 유익할 수 있습니다. 시간 간격은 나노초 단위로 지정됩니다. 기본값은 50000ns입니다.
낮은 CPU 소모를 최적화하려면 작은 값을 입력하거나 0을 입력하여 폴링을 비활성화합니다.
echo 0 > /sys/module/kvm/parameters/halt_poll_ns
# echo 0 > /sys/module/kvm/parameters/halt_poll_ns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어 트랜잭션 워크로드의 경우 낮은 대기 시간을 최적화하려면 큰 값을 입력하세요.
echo 80000 > /sys/module/kvm/parameters/halt_poll_ns
# echo 80000 > /sys/module/kvm/parameters/halt_poll_ns
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10장. Node Tuning Operator 사용 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator에 대해 알아보고, Node Tuning Operator를 사용하여 Tuned 데몬을 오케스트레이션하고 노드 수준 튜닝을 관리하는 방법도 알아봅니다.
10.1. Node Tuning Operator 정보 링크 복사링크가 클립보드에 복사되었습니다!
노드 튜닝 오퍼레이터는 TuneD 데몬을 조율하여 노드 수준 튜닝을 관리하고 성능 프로파일 컨트롤러를 사용하여 낮은 지연 시간 성능을 달성하는 데 도움이 됩니다. 대부분의 고성능 애플리케이션에는 일정 수준의 커널 튜닝이 필요합니다. Node Tuning Operator는 노드 수준 sysctls 사용자에게 통합 관리 인터페이스를 제공하며 사용자의 필요에 따라 지정되는 사용자 정의 튜닝을 추가할 수 있는 유연성을 제공합니다.
Operator는 OpenShift Container Platform의 컨테이너화된 TuneD 데몬을 Kubernetes 데몬 세트로 관리합니다. 클러스터에서 실행되는 모든 컨테이너화된 TuneD 데몬에 사용자 정의 튜닝 사양이 데몬이 이해할 수 있는 형식으로 전달되도록 합니다. 데몬은 클러스터의 모든 노드에서 노드당 하나씩 실행됩니다.
컨테이너화된 TuneD 데몬을 통해 적용되는 노드 수준 설정은 프로필 변경을 트리거하는 이벤트 시 또는 컨테이너화된 TuneD 데몬이 종료 신호를 수신하고 처리하여 정상적으로 종료될 때 롤백됩니다.
노드 튜닝 오퍼레이터는 성능 프로파일 컨트롤러를 사용하여 자동 튜닝을 구현하여 OpenShift Container Platform 애플리케이션에 대한 저지연 성능을 달성합니다.
클러스터 관리자는 다음과 같은 노드 수준 설정을 정의하기 위해 성능 프로필을 구성합니다.
- 커널을 kernel-rt로 업데이트합니다.
- 하우스키핑을 위한 CPU 선택.
- 워크로드 실행을 위한 CPU 선택.
버전 4.1 이상에서는 Node Tuning Operator가 표준 OpenShift Container Platform 설치에 포함되어 있습니다.
OpenShift Container Platform의 이전 버전에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션의 저지연 성능을 달성하기 위한 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능이 Node Tuning Operator의 일부입니다.
10.2. Node Tuning Operator 사양 예에 액세스 링크 복사링크가 클립보드에 복사되었습니다!
이 프로세스를 사용하여 Node Tuning Operator 사양 예에 액세스하십시오.
프로세스
다음 명령을 실행하여 Node Tuning Operator 사양의 예에 액세스하세요.
oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator
oc get tuned.tuned.openshift.io/default -o yaml -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
기본 CR은 OpenShift Container Platform 플랫폼의 표준 노드 수준 튜닝을 제공하기 위한 것이며 Operator 관리 상태를 설정하는 경우에만 수정할 수 있습니다. Operator는 기본 CR에 대한 다른 모든 사용자 정의 변경사항을 덮어씁니다. 사용자 정의 튜닝의 경우 고유한 Tuned CR을 생성합니다. 새로 생성된 CR은 노드 또는 Pod 라벨 및 프로필 우선 순위에 따라 OpenShift Container Platform 노드에 적용된 기본 CR 및 사용자 정의 튜닝과 결합됩니다.
특정 상황에서는 Pod 라벨에 대한 지원이 필요한 튜닝을 자동으로 제공하는 편리한 방법일 수 있지만 이러한 방법은 권장되지 않으며 특히 대규모 클러스터에서는 이러한 방법을 사용하지 않는 것이 좋습니다. 기본 Tuned CR은 Pod 라벨이 일치되지 않은 상태로 제공됩니다. Pod 라벨이 일치된 상태로 사용자 정의 프로필이 생성되면 해당 시점에 이 기능이 활성화됩니다. 포드 레이블 기능은 향후 Node Tuning Operator 버전에서는 더 이상 지원되지 않습니다.
10.3. 클러스터에 설정된 기본 프로필 링크 복사링크가 클립보드에 복사되었습니다!
다음은 클러스터에 설정된 기본 프로필입니다.
OpenShift Container Platform 4.9부터 모든 OpenShift TuneD 프로필이 TuneD 패키지와 함께 제공됩니다. oc exec
명령을 사용하여 이러한 프로필의 내용을 볼 수 있습니다.
oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;
$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;
10.4. TuneD 프로필이 적용되었는지 검증 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 노드에 적용된 TuneD 프로필을 확인하세요.
oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
출력 예
-
NAME
: Profile 오브젝트의 이름입니다. 노드당 하나의 Profile 오브젝트가 있고 해당 이름이 일치합니다. -
TUNED
: 적용할 TuneD 프로파일의 이름입니다. -
APPLIED
: TuneD 데몬이 원하는 프로필을 적용한 경우True
입니다. (True/False/Unknown
). -
DEGRADED
: TuneD 프로파일 적용 중에 오류가 보고된 경우 (True
)./False/Unknown
-
AGE
: Profile 개체 생성 이후 경과 시간입니다.
ClusterOperator/node-tuning
개체에는 Operator와 해당 노드 에이전트의 상태에 대한 유용한 정보도 포함되어 있습니다. 예를 들어, 운영자 오류 구성은 ClusterOperator/노드 튜닝
상태 메시지를 통해 보고됩니다.
ClusterOperator/node-tuning
개체에 대한 상태 정보를 얻으려면 다음 명령을 실행하세요.
oc get co/node-tuning -n openshift-cluster-node-tuning-operator
$ oc get co/node-tuning -n openshift-cluster-node-tuning-operator
출력 예
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE node-tuning 4.19.1 True False True 60m 1/5 Profiles with bootcmdline conflict
NAME VERSION AVAILABLE PROGRESSING DEGRADED SINCE MESSAGE
node-tuning 4.19.1 True False True 60m 1/5 Profiles with bootcmdline conflict
ClusterOperator/노드 튜닝
이나 프로필 개체의 상태가 DEGRADED
인 경우 Operator 또는 피연산자 로그에 추가 정보가 제공됩니다.
10.5. 사용자 정의 튜닝 사양 링크 복사링크가 클립보드에 복사되었습니다!
Operator의 CR(사용자 정의 리소스)에는 두 가지 주요 섹션이 있습니다. 첫 번째 섹션인 profile:
은 TuneD 프로필 및 해당 이름의 목록입니다. 두 번째인 recommend:
은 프로필 선택 논리를 정의합니다.
여러 사용자 정의 튜닝 사양은 Operator의 네임스페이스에 여러 CR로 존재할 수 있습니다. 새로운 CR의 존재 또는 오래된 CR의 삭제는 Operator에서 탐지됩니다. 기존의 모든 사용자 정의 튜닝 사양이 병합되고 컨테이너화된 TuneD 데몬의 해당 오브젝트가 업데이트됩니다.
관리 상태
Operator 관리 상태는 기본 Tuned CR을 조정하여 설정됩니다. 기본적으로 Operator는 Managed 상태이며 기본 Tuned CR에는 spec.managementState
필드가 없습니다. Operator 관리 상태에 유효한 값은 다음과 같습니다.
- Managed: 구성 리소스가 업데이트되면 Operator가 해당 피연산자를 업데이트합니다.
- Unmanaged: Operator가 구성 리소스에 대한 변경을 무시합니다.
- Removed: Operator가 프로비저닝한 해당 피연산자 및 리소스를 Operator가 제거합니다.
프로필 데이터
profile:
섹션에는 TuneD 프로필 및 해당 이름이 나열됩니다.
권장 프로필
profile:
선택 논리는 CR의 recommend:
섹션에 의해 정의됩니다. recommend:
섹션은 선택 기준에 따라 프로필을 권장하는 항목의 목록입니다.
recommend: <recommend-item-1> # ... <recommend-item-n>
recommend:
<recommend-item-1>
# ...
<recommend-item-n>
목록의 개별 항목은 다음과 같습니다.
- 1
- 선택 사항입니다.
- 2
- 키/값
MachineConfig
라벨 사전입니다. 키는 고유해야 합니다. - 3
- 생략하면 우선 순위가 높은 프로필이 먼저 일치되거나
machineConfigLabels
가 설정되어 있지 않으면 프로필이 일치하는 것으로 가정합니다. - 4
- 선택사항 목록입니다.
- 5
- 프로필 순서 지정 우선 순위입니다. 숫자가 작을수록 우선 순위가 높습니다(
0
이 가장 높은 우선 순위임). - 6
- 일치에 적용할 TuneD 프로필입니다. 예를 들어
tuned_profile_1
이 있습니다. - 7
- 선택적 피연산자 구성.
- 8
- TuneD 데몬에 대해 디버깅을 켜거나 끕니다. 켜짐의 경우 옵션은
true
이고 꺼짐의 경우 옵션은false입니다
. 기본값은false
입니다. - 9
- TuneD 데몬에 대해
reapply_sysctl
기능을 켜거나 끕니다. 켜짐에 대한 옵션은true
이고 꺼짐에 대한 옵션은false입니다
.
<match>
는 다음과 같이 재귀적으로 정의되는 선택사항 목록입니다.
- label: <label_name> value: <label_value> type: <label_type> <match>
- label: <label_name>
value: <label_value>
type: <label_type>
<match>
<match>
를 생략하지 않으면 모든 중첩 <match>
섹션도 true
로 평가되어야 합니다. 생략하면 false
로 가정하고 해당 <match>
섹션이 있는 프로필을 적용하지 않거나 권장하지 않습니다. 따라서 중첩(하위 <match>
섹션)은 논리 AND 연산자 역할을 합니다. 반대로 <match>
목록의 항목이 일치하면 전체 <match>
목록이 true
로 평가됩니다. 따라서 이 목록이 논리 OR 연산자 역할을 합니다.
machineConfigLabels
가 정의되면 지정된 recommend:
목록 항목에 대해 머신 구성 풀 기반 일치가 설정됩니다. <mcLabels>
는 머신 구성의 라벨을 지정합니다. 머신 구성은 <tuned_profile_name>
프로필에 대해 커널 부팅 매개변수와 같은 호스트 설정을 적용하기 위해 자동으로 생성됩니다. 여기에는 <mcLabels>
와 일치하는 머신 구성 선택기가 있는 모든 머신 구성 풀을 찾고 머신 구성 풀이 할당된 모든 노드에서 <tuned_profile_name>
프로필을 설정하는 작업이 포함됩니다. 마스터 및 작업자 역할이 모두 있는 노드를 대상으로 하려면 마스터 역할을 사용해야 합니다.
목록 항목 match
및 machineConfigLabels
는 논리 OR 연산자로 연결됩니다. match
항목은 단락 방식으로 먼저 평가됩니다. 따라서 true
로 평가되면 machineConfigLabels
항목이 고려되지 않습니다.
머신 구성 풀 기반 일치를 사용하는 경우 동일한 하드웨어 구성을 가진 노드를 동일한 머신 구성 풀로 그룹화하는 것이 좋습니다. 이 방법을 따르지 않으면 TuneD 피연산자가 동일한 머신 구성 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.
예: 노드 또는 포드 레이블 기반 매칭
위의 CR은 컨테이너화된 TuneD 데몬의 프로필 우선 순위에 따라 recommended.conf
파일로 변환됩니다. 우선 순위가 가장 높은 프로필(10
)이 openshift-control-plane-es
이므로 이 프로필을 첫 번째로 고려합니다. 지정된 노드에서 실행되는 컨테이너화된 TuneD 데몬은 tuned.openshift.io/elasticsearch
라벨이 설정된 동일한 노드에서 실행되는 Pod가 있는지 확인합니다. 없는 경우 전체 <match>
섹션이 false
로 평가됩니다. 라벨이 있는 Pod가 있는 경우 <match>
섹션을 true
로 평가하려면 노드 라벨도 node-role.kubernetes.io/master
또는 node-role.kubernetes.io/infra
여야 합니다.
우선 순위가 10
인 프로필의 라벨이 일치하면 openshift-control-plane-es
프로필이 적용되고 다른 프로필은 고려되지 않습니다. 노드/Pod 라벨 조합이 일치하지 않으면 두 번째로 높은 우선 순위 프로필(openshift-control-plane
)이 고려됩니다. 컨테이너화된 TuneD Pod가 node-role.kubernetes.io/master
또는 node-role.kubernetes.io/infra
. 라벨이 있는 노드에서 실행되는 경우 이 프로필이 적용됩니다.
마지막으로, openshift-node
프로필은 우선 순위가 가장 낮은 30
입니다. 이 프로필에는 <match>
섹션이 없으므로 항상 일치합니다. 지정된 노드에서 우선 순위가 더 높은 다른 프로필이 일치하지 않는 경우 openshift-node
프로필을 설정하는 데 catch-all 프로필 역할을 합니다.
예: 머신 구성 풀 기반 매칭
노드 재부팅을 최소화하려면 머신 구성 풀의 노드 선택기와 일치하는 라벨로 대상 노드에 라벨을 지정한 후 위의 Tuned CR을 생성하고 마지막으로 사용자 정의 머신 구성 풀을 생성합니다.
클라우드 공급자별 TuneD 프로필
이 기능을 사용하면 모든 클라우드 공급자별 노드에 OpenShift Container Platform 클러스터의 특정 클라우드 공급자에 맞게 특별히 조정된 TuneD 프로필을 편리하게 할당할 수 있습니다. 추가 노드 레이블을 추가하거나 노드를 머신 구성 풀로 그룹화하지 않고도 이 작업을 수행할 수 있습니다.
이 기능은 <cloud-provider>://<cloud-provider-specific-id>
형식의 spec.providerID
노드 오브젝트 값을 활용하고 NTO 피연산자 컨테이너의 <cloud-provider>
값으로 /var/lib/ocp-tuned/provider
파일을 씁니다. 이 파일의 내용은 TuneD에서 provider-<cloud-provider>
프로필이 존재하는 경우 해당 프로필을 로드하는 데 사용됩니다.
이제
및 openshift
-control-planeopenshift-node
프로필에서 설정을 상속하는 openshift 프로파일이 조건부 프로필 로드를 사용하여 이 기능을 사용하도록 업데이트되었습니다. 현재 NTO와 TuneD에는 클라우드 공급자별 프로필이 포함되어 있지 않습니다. 그러나 모든 클라우드 공급자별 클러스터 노드에 적용될 사용자 정의 프로필 공급자-<클라우드 공급자>를
만드는 것이 가능합니다.
GCE 클라우드 공급자 프로필 예시
프로필 상속으로 인해 provider-<cloud-provider>
프로필에 지정된 모든 설정은 openshift
프로필과 그 자식 프로필에 의해 덮어쓰여집니다.
10.6. 사용자 정의 튜닝 예 링크 복사링크가 클립보드에 복사되었습니다!
기본 CR에서 TuneD 프로파일 사용
다음 CR에서는 tuned.openshift.io/ingress-node-label
레이블이 임의의 값으로 설정된 OpenShift Container Platform 노드에 대해 사용자 정의 노드 수준 튜닝을 적용합니다.
예: openshift-control-plane TuneD 프로필을 사용한 사용자 정의 튜닝
사용자 정의 프로필 작성자는 기본 TuneD CR에 제공된 기본 Tuned 데몬 프로필을 포함하는 것이 좋습니다. 위의 예에서는 기본 openshift-control-plane
프로필을 사용하여 작업을 수행합니다.
내장된 TuneD 프로필 사용
NTO 관리 데몬 세트가 성공적으로 롤아웃되면 TuneD 피연산자는 모두 동일한 버전의 TuneD 데몬을 관리합니다. 데몬에서 지원하는 기본 제공 TuneD 프로필을 나열하려면 다음 방식으로 TuneD Pod를 쿼리합니다.
oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'
$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'
사용자 정의 튜닝 사양에서 이 명령으로 검색한 프로필 이름을 사용할 수 있습니다.
예: 기본 제공 hpc-compute TuneD 프로필 사용
기본 제공 hpc-compute
프로필 외에도 위의 예제에는 기본 Tuned CR 내에 제공된 openshift-node
TuneD 데몬 프로필이 포함되어 컴퓨팅 노드에 OpenShift별 튜닝을 사용합니다.
호스트 수준 sysctl 재정의
다양한 커널 매개변수는 /run/sysctl.d/
, /etc/sysctl.d/
, /etc/sysctl.conf
호스트 구성 파일을 사용하여 런타임에 변경할 수 있습니다. OpenShift Container Platform은 런타임에 커널 매개변수를 설정하는 여러 호스트 구성 파일을 추가합니다. 예를 들어 net.ipv[4-6].
, fs.inotify.
, vm.max_map_count
. 이러한 런타임 매개변수는 kubelet과 Operator가 시작되기 전에 시스템에 대한 기본적인 기능 조정을 제공합니다.
reapply_sysctl
옵션이 false
로 설정되지 않는 한 Operator는 이러한 설정을 재정의하지 않습니다. 이 옵션을 false
로 설정하면 TuneD가
사용자 정의 프로필을 적용한 후 호스트 구성 파일의 설정을 적용하지 않습니다.
예: 호스트 수준 sysctls 재정의
10.7. 튜닝 변경 사항 적용 연기 링크 복사링크가 클립보드에 복사되었습니다!
관리자로서 노드 튜닝 운영자(NTO)를 사용하여 실행 중인 시스템의 사용자 정의 리소스(CR)를 업데이트하고 튜닝을 변경합니다. 예를 들어, 조정된 개체의 [sysctl] 섹션에 sysctl 매개변수를 업데이트하거나 추가할 수 있습니다. 관리자가 튜닝 변경 사항을 적용하면 NTO는 TuneD에 모든 구성을 다시 처리하도록 요청하여 튜닝된 프로세스가 모든 튜닝을 롤백한 다음 다시 적용합니다.
지연 시간에 민감한 애플리케이션의 경우, 조정된 프로필을 제거하고 다시 적용하면 성능이 잠시 저하될 수 있으므로 이를 허용하지 않을 수 있습니다. 이는 성능 프로필을 사용하여 CPU를 분할하고 프로세스 또는 인터럽트 친화성을 관리하는 구성에 특히 중요합니다. 이 문제를 방지하기 위해 OpenShift Container Platform은 튜닝 변경 사항을 적용하기 위한 새로운 방법을 도입했습니다. OpenShift Container Platform 4.17 이전에는 사용 가능한 유일한 방법은 즉시 변경 사항을 적용하여 조정된 재시작을 트리거하는 것이었습니다.
다음과 같은 추가 방법이 지원됩니다.
-
항상
: 모든 변경 사항은 다음 노드가 다시 시작될 때 적용됩니다. -
업데이트
: 튜닝 변경으로 인해 튜닝된 프로필이 수정되면 기본적으로 즉시 적용되며 가능한 한 빨리 효과가 나타납니다. 튜닝 변경으로 인해 튜닝된 프로필이 변경되지 않고 해당 값이 그대로 수정된 경우에는 항상 그렇듯이 처리됩니다.
tuned.openshift.io/deferred
주석을 추가하여 이 기능을 활성화하세요. 다음 표는 주석에 가능한 값을 요약한 것입니다.
주석 값 | 설명 |
---|---|
없어진 | 변경 사항은 즉시 적용됩니다. |
always | 변경 사항은 다음 노드 재시작 시 적용됩니다. |
update | 프로필이 변경되면 변경 사항이 즉시 적용되고, 그렇지 않으면 다음 노드를 다시 시작할 때 적용됩니다. |
다음 예제에서는 always
메서드를 사용하여 kernel.shmmni
sysctl 매개변수에 변경 사항을 적용하는 방법을 보여줍니다.
예
Topology Aware Lifecycle Manager를 사용하면 여러 스포크 클러스터에 걸쳐 제어된 재부팅을 수행하여 지연된 튜닝 변경 사항을 적용할 수 있습니다. 조정된 재부팅에 대한 자세한 내용은 "구성 변경에 따른 재부팅 조정"을 참조하세요.
10.7.1. 튜닝 변경 사항 적용 연기: 예 링크 복사링크가 클립보드에 복사되었습니다!
다음의 실제 예제에서는 노드 튜닝 연산자를 사용하여 튜닝 변경 사항의 적용을 연기하는 방법을 설명합니다.
사전 요구 사항
-
클러스터 관리자
역할 액세스 권한이 있습니다. - 클러스터에 성능 프로필을 적용했습니다.
-
예를 들어,
Worker-cnf
와 같은MachineConfigPool
리소스는 프로필이 지정된 노드에만 적용되도록 구성됩니다.
프로세스
다음 명령을 실행하여 현재 클러스터에 적용된 프로필을 확인하세요.
oc -n openshift-cluster-node-tuning-operator get tuned
$ oc -n openshift-cluster-node-tuning-operator get tuned
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE default 63m openshift-node-performance-performance 21m
NAME AGE default 63m openshift-node-performance-performance 21m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터의 머신 구성 풀을 확인하세요.
oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-79a26af9f78ced61fa8ccd309d3c859c True False False 3 3 3 0 157m worker rendered-worker-d9352e91a1b14de7ef453fa54480ce0e True False False 2 2 2 0 157m worker-cnf rendered-worker-cnf-f398fc4fcb2b20104a51e744b8247272 True False False 1 1 1 0 92m
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-79a26af9f78ced61fa8ccd309d3c859c True False False 3 3 3 0 157m worker rendered-worker-d9352e91a1b14de7ef453fa54480ce0e True False False 2 2 2 0 157m worker-cnf rendered-worker-cnf-f398fc4fcb2b20104a51e744b8247272 True False False 1 1 1 0 92m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 현재 적용된 성능 프로필을 설명합니다.
oc describe performanceprofile performance | grep Tuned
$ oc describe performanceprofile performance | grep Tuned
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-performance
Tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-performance
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kernel.shmmni
sysctl 매개변수의 기존 값을 확인하세요.다음 명령을 실행하여 노드 이름을 표시합니다.
oc get nodes
$ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 노드
ip-10-0-32-74.ec2.internal
의kernel.shmmni
sysctl 매개변수의 현재 값을 표시합니다.oc debug node/ip-10-0-26-151.ec2.internal -q -- chroot host sysctl kernel.shmmni
$ oc debug node/ip-10-0-26-151.ec2.internal -q -- chroot host sysctl kernel.shmmni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
kernel.shmmni = 4096
kernel.shmmni = 4096
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
예를 들어,
kernel.shmmni
sysctl 매개변수를8192
로 변경하는perf-patch.yaml
과 같은 프로필 패치를 만듭니다. 다음 구성을 적용하여always
메서드를 사용하여 변경 사항 적용을 새로운 수동 재시작으로 연기합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 프로필 패치를 적용합니다.
oc apply -f perf-patch.yaml
$ oc apply -f perf-patch.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 프로필 패치가 다음 노드 재시작을 기다리고 있는지 확인하세요.
oc -n openshift-cluster-node-tuning-operator get profile
$ oc -n openshift-cluster-node-tuning-operator get profile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 재시작하기 전에
kernel.shmmni
sysctl 매개변수 값이 변경되지 않은지 확인하세요.다음 명령을 실행하여 노드
ip-10-0-26-151.ec2.internal
의kernel.shmmni
sysctl 매개변수에 대한성능 패치
변경 사항이 적용되지 않았는지 확인합니다.oc debug node/ip-10-0-26-151.ec2.internal -q -- chroot host sysctl kernel.shmmni
$ oc debug node/ip-10-0-26-151.ec2.internal -q -- chroot host sysctl kernel.shmmni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
kernel.shmmni = 4096
kernel.shmmni = 4096
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 필요한 변경 사항을 적용하려면 노드
ip-10-0-26-151.ec2.internal
을 다시 시작합니다.oc debug node/ip-10-0-26-151.ec2.internal -q -- chroot host reboot&
$ oc debug node/ip-10-0-26-151.ec2.internal -q -- chroot host reboot&
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다른 터미널 창에서 다음 명령을 실행하여 노드가 다시 시작되었는지 확인합니다.
watch oc get nodes
$ watch oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드
ip-10-0-26-151.ec2.internal
이준비
상태로 다시 전환될 때까지 기다립니다.다음 명령을 실행하여 프로필 패치가 다음 노드 재시작을 기다리고 있는지 확인하세요.
oc -n openshift-cluster-node-tuning-operator get profile
$ oc -n openshift-cluster-node-tuning-operator get profile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 재시작 후
kernel.shmmni
sysctl 매개변수 값이 변경되었는지 확인하세요.다음 명령을 실행하여
kernel.shmmni
sysctl 매개변수 변경 사항이 노드ip-10-0-32-74.ec2.internal
에 적용되었는지 확인합니다.oc debug node/ip-10-0-32-74.ec2.internal -q -- chroot host sysctl kernel.shmmni
$ oc debug node/ip-10-0-32-74.ec2.internal -q -- chroot host sysctl kernel.shmmni
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
kernel.shmmni = 8192
kernel.shmmni = 8192
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
추가로 재시작하면 kernel.shmmni
sysctl 매개변수의 원래 값이 복원됩니다.
10.8. 지원되는 TuneD 데몬 플러그인 링크 복사링크가 클립보드에 복사되었습니다!
[main]
섹션을 제외하고 다음 TuneD 플러그인은 Tuned CR의 profile: 섹션
에 정의된 사용자 정의 프로필을 사용할 때 지원됩니다.
- audio
- cpu
- disk
- eeepc_she
- modules
- mounts
- net
- scheduler
- scsi_host
- selinux
- sysctl
- sysfs
- usb
- video
- vm
- bootloader
일부 플러그인은 지원되지 않는 동적 튜닝 기능을 제공합니다. 현재 지원되지 않는 TuneD 플러그인은 다음과 같습니다.
- script
- systemd
TuneD 부트로더 플러그인은 Red Hat Enterprise Linux CoreOS(RHCOS) 워커 노드만 지원합니다.
추가 리소스
10.9. 호스트 클러스터에서 노드 튜닝 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 노드에 노드 수준 튜닝을 설정하려면 Node Tuning Operator를 사용할 수 있습니다. 호스팅된 컨트롤 플레인에서는 Tuned
오브젝트가 포함된 구성 맵을 생성하고 노드 풀에 해당 구성 맵을 참조하여 노드 튜닝을 구성할 수 있습니다.
절차
유효한 tuned 매니페스트가 포함된 구성 맵을 생성하고 노드 풀에서 매니페스트를 참조합니다. 다음 예에서
Tuned
매니페스트는tuned-1-node-label
노드 라벨이 임의의 값이 포함된 노드에서vm.dirty_ratio
를 55로 설정하는 프로필을 정의합니다.tuned-1.yaml
이라는 파일에 다음ConfigMap
매니페스트를 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Tuned 사양의
spec.recommend
섹션에 있는 항목에 라벨을 추가하지 않으면 node-pool 기반 일치로 간주되므로spec.recommend
섹션에서 가장 높은 우선 순위 프로필이 풀의 노드에 적용됩니다. Tuned.spec.recommend.match
섹션에서 레이블 값을 설정하여 보다 세분화된 노드 레이블 기반 일치를 수행할 수 있지만 노드 레이블은 노드 풀의.spec.management.upgradeType
값을InPlace
로 설정하지 않는 한 업그레이드 중에 유지되지 않습니다.관리 클러스터에
ConfigMap
오브젝트를 생성합니다.oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 풀을 편집하거나 하나를 생성하여 노드 풀의
spec.tuningConfig
필드에서ConfigMap
오브젝트를 참조합니다. 이 예에서는 2개의 노드가 포함된nodepool-1
이라는NodePool
이 하나만 있다고 가정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고여러 노드 풀에서 동일한 구성 맵을 참조할 수 있습니다. 호스팅된 컨트롤 플레인에서 Node Tuning Operator는 노드 풀 이름과 네임스페이스의 해시를 Tuned CR 이름에 추가하여 구별합니다. 이 경우 동일한 호스트 클러스터에 대해 다른 Tuned CR에 동일한 이름의 여러 TuneD 프로필을 생성하지 마십시오.
검증
이제 Tuned
매니페스트가 포함된 ConfigMap
오브젝트를 생성하여 NodePool
에서 참조하므로 Node Tuning Operator가 Tuned
오브젝트를 호스팅된 클러스터에 동기화합니다. 정의된 Tuned
오브젝트와 각 노드에 적용되는 TuneD 프로필을 확인할 수 있습니다.
호스트 클러스터에서
Tuned
오브젝트를 나열합니다.oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE default 7m36s rendered 7m36s tuned-1 65s
NAME AGE default 7m36s rendered 7m36s tuned-1 65s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터의
Profile
오브젝트를 나열합니다.oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 tuned-1-profile True False 7m43s nodepool-1-worker-2 tuned-1-profile True False 7m14s
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 tuned-1-profile True False 7m43s nodepool-1-worker-2 tuned-1-profile True False 7m14s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고사용자 지정 프로필이 생성되지 않으면 기본적으로
openshift-node
프로필이 적용됩니다.튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고 sysctl 값을 확인합니다.
oc --kubeconfig="$HC_KUBECONFIG" \ debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
$ oc --kubeconfig="$HC_KUBECONFIG" \ debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
vm.dirty_ratio = 55
vm.dirty_ratio = 55
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
10.10. 커널 부팅 매개변수를 설정하여 호스팅된 클러스터에 대한 고급 노드 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 제어 평면에서 보다 고급 튜닝을 수행하려면 커널 부팅 매개변수 설정이 필요하며, 이 경우 노드 튜닝 연산자를 사용할 수도 있습니다. 다음 예제에서는 방대한 페이지를 예약하여 노드 풀을 만드는 방법을 보여줍니다.
프로세스
크기가 2MB인 10개의 거대한 페이지를 생성하기 위한
Tuned
객체 매니페스트가 포함된ConfigMap
객체를 생성합니다. 이ConfigMap
매니페스트를tuned-hugepages.yaml
이라는 이름의 파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고.spec.recommend.match
필드는 의도적으로 비워두었습니다. 이 경우, 이Tuned
객체는 이ConfigMap
객체가 참조되는 노드 풀의 모든 노드에 적용됩니다. 동일한 하드웨어 구성을 가진 노드를 동일한 노드 풀로 그룹화합니다. 그렇지 않으면 TuneD 피연산자는 동일한 노드 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.관리 클러스터에
ConfigMap
오브젝트를 생성합니다.oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml
$ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<management_cluster_kubeconfig>를
관리 클러스터kubeconfig
파일의 이름으로 바꾸세요.
NodePool
매니페스트 YAML 파일을 만들고,NodePool
의 업그레이드 유형을 사용자 지정하고,spec.tuningConfig
섹션에서 만든ConfigMap
객체를 참조합니다.hcp
CLI를 사용하여NodePool
매니페스트를 만들고hugepages-nodepool.yaml
이라는 파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고hcp create
명령의--render
플래그는 비밀을 렌더링하지 않습니다. 비밀을 렌더링하려면hcp create
명령에서--render
및--render-sensitive
플래그를 모두 사용해야 합니다.hugepages-nodepool.yaml
파일에서.spec.management.upgradeType을
InPlace
로 설정하고,.spec.tuningConfig를
사용자가 만든tuned-hugepages
ConfigMap
객체를 참조하도록 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고새로운
MachineConfig
객체를 적용할 때 불필요한 노드 재생성을 방지하려면.spec.management.upgradeType을
InPlace
로 설정합니다.Replace
업그레이드 유형을 사용하면 노드가 완전히 삭제되고 TuneD 피연산자가 계산한 새 커널 부팅 매개변수를 적용할 때 새 노드로 기존 노드를 대체할 수 있습니다.관리 클러스터에
NodePool을
생성합니다.oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml
$ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
노드를 사용할 수 있게 되면 컨테이너화된 TuneD 데몬은 적용된 TuneD 프로필을 기반으로 필요한 커널 부팅 매개변수를 계산합니다. 노드가 준비되고 생성된 MachineConfig
객체를 적용하기 위해 한 번 재부팅하면 TuneD 프로필이 적용되었고 커널 부팅 매개변수가 설정되었는지 확인할 수 있습니다.
호스트 클러스터에서
Tuned
오브젝트를 나열합니다.oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE default 123m hugepages-8dfb1fed 1m23s rendered 123m
NAME AGE default 123m hugepages-8dfb1fed 1m23s rendered 123m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터의
Profile
오브젝트를 나열합니다.oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
$ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io \ -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 openshift-node True False 132m nodepool-1-worker-2 openshift-node True False 131m hugepages-nodepool-worker-1 openshift-node-hugepages True False 4m8s hugepages-nodepool-worker-2 openshift-node-hugepages True False 3m57s
NAME TUNED APPLIED DEGRADED AGE nodepool-1-worker-1 openshift-node True False 132m nodepool-1-worker-2 openshift-node True False 131m hugepages-nodepool-worker-1 openshift-node-hugepages True False 4m8s hugepages-nodepool-worker-2 openshift-node-hugepages True False 3m57s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새
NodePool
의 작업자 노드 모두openshift-node-hugepages
프로필이 적용됩니다.튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고
/proc/cmdline
을 확인합니다.oc --kubeconfig="<hosted_cluster_kubeconfig>" \ debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
$ oc --kubeconfig="<hosted_cluster_kubeconfig>" \ debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50
BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11장. CPU 관리자 및 토폴로지 관리자 사용 링크 복사링크가 클립보드에 복사되었습니다!
CPU 관리자는 CPU 그룹을 관리하고 워크로드를 특정 CPU로 제한합니다.
CPU 관리자는 다음과 같은 속성 중 일부가 포함된 워크로드에 유용합니다.
- 가능한 한 많은 CPU 시간이 필요합니다.
- 프로세서 캐시 누락에 민감합니다.
- 대기 시간이 짧은 네트워크 애플리케이션입니다.
- 다른 프로세스와 조정하고 단일 프로세서 캐시 공유를 통해 얻는 이점이 있습니다.
토폴로지 관리자는 동일한 NUMA(Non-Uniform Memory Access) 노드의 모든 QoS(Quality of Service) 클래스에 대해 CPU 관리자, 장치 관리자, 기타 힌트 공급자로부터 힌트를 수집하여 CPU, SR-IOV VF, 기타 장치 리소스 등의 Pod 리소스를 정렬합니다.
토폴로지 관리자는 토폴로지 관리자 정책 및 요청된 Pod 리소스를 기반으로 수집된 힌트의 토폴로지 정보를 사용하여 노드에서 Pod를 수락할 것인지 거부할 것인지 결정합니다.
토폴로지 관리자는 하드웨어 가속기를 사용하여 대기 시간이 중요한 실행과 처리량이 높은 병렬 계산을 지원하는 워크로드에 유용합니다.
토폴로지 관리자를 사용하려면 정적
정책을 사용하여 CPU 관리자를 구성해야 합니다.
11.1. CPU 관리자 설정 링크 복사링크가 클립보드에 복사되었습니다!
CPU 관리자를 구성하려면 KubeletConfig CR(사용자 정의 리소스)을 생성하고 원하는 노드 세트에 적용합니다.
프로세스
다음 명령을 실행하여 노드에 레이블을 지정합니다.
oc label node perf-node.example.com cpumanager=true
# oc label node perf-node.example.com cpumanager=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 모든 컴퓨팅 노드에 대해 CPU 관리자를 활성화하려면 다음 명령을 실행하여 CR을 편집합니다.
oc edit machineconfigpool worker
# oc edit machineconfigpool worker
Copy to Clipboard Copied! Toggle word wrap Toggle overflow metadata.labels
섹션에custom-kubelet: cpumanager-enabled
레이블을 추가합니다.metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabled
metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow KubeletConfig
,cpumanager-kubeletconfig.yaml
, CR(사용자 정의 리소스)을 생성합니다. 이전 단계에서 생성한 레이블을 참조하여 올바른 노드가 새 kubelet 구성으로 업데이트되도록 합니다.machineConfigPoolSelector
섹션을 참조하십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 동적 kubelet 구성을 생성합니다.
oc create -f cpumanager-kubeletconfig.yaml
# oc create -f cpumanager-kubeletconfig.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 그러면 kubelet 구성에 CPU 관리자 기능이 추가되고 필요한 경우 MCO(Machine Config Operator)가 노드를 재부팅합니다. CPU 관리자를 활성화하는 데는 재부팅이 필요하지 않습니다.
다음 명령을 실행하여 병합된 kubelet 구성을 확인합니다.
oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
# oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 컴퓨팅 노드에서 업데이트된
kubelet.conf
파일이 있는지 확인합니다.oc debug node/perf-node.example.com
# oc debug node/perf-node.example.com sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
cpuManagerPolicy: static cpuManagerReconcilePeriod: 5s
cpuManagerPolicy: static
1 cpuManagerReconcilePeriod: 5s
2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 프로젝트를 생성합니다.
oc new-project <project_name>
$ oc new-project <project_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다.
cat cpumanager-pod.yaml
# cat cpumanager-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod를 생성합니다.
oc create -f cpumanager-pod.yaml
# oc create -f cpumanager-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 레이블을 지정한 노드에 Pod가 예약되어 있는지 확인합니다.
oc describe pod cpumanager
# oc describe pod cpumanager
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 CPU가 Pod에만 할당되었는지 확인합니다.
oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2
# oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME CPU Requests CPU Limits Memory Requests Memory Limits Age cpuman cpumanager-mlrrz 1 (28%) 1 (28%) 1G (13%) 1G (13%) 27m
NAMESPACE NAME CPU Requests CPU Limits Memory Requests Memory Limits Age cpuman cpumanager-mlrrz 1 (28%) 1 (28%) 1G (13%) 1G (13%) 27m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cgroups
가 올바르게 설정되었는지 검증합니다. 다음 명령을 실행하여일시 중지
프로세스의 PID(프로세스 ID)를 가져옵니다.oc debug node/perf-node.example.com
# oc debug node/perf-node.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl status | grep -B5 pause
sh-4.2# systemctl status | grep -B5 pause
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고출력에서 일시 정지 프로세스 항목을 여러 개 반환하는 경우 올바른 일시 중지 프로세스를 식별해야 합니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 QoS(서비스 품질) 계층
Guaranteed
의 포드가kubepods.slice
하위 디렉토리에 배치되었는지 확인하세요.cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
# cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
Copy to Clipboard Copied! Toggle word wrap Toggle overflow for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
# for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고다른 QoS 계층의 Pod는 부모
KubePod
의 자식cgroup
에 속하게 됩니다.출력 예
cpuset.cpus 1 tasks 32706
cpuset.cpus 1 tasks 32706
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 작업에 허용된 CPU 목록을 확인하세요.
grep ^Cpus_allowed_list /proc/32706/status
# grep ^Cpus_allowed_list /proc/32706/status
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Cpus_allowed_list: 1
Cpus_allowed_list: 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 시스템의 다른 포드가
보장된
포드에 할당된 코어에서 실행될 수 없는지 확인합니다. 예를 들어,Besteffort
QoS 계층에서 Pod를 확인하려면 다음 명령을 실행하세요.cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
# cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe node perf-node.example.com
# oc describe node perf-node.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 VM에는 두 개의 CPU 코어가 있습니다.
system-reserved
설정은 500밀리코어로 설정되었습니다. 즉,Node Allocatable
양이 되는 노드의 전체 용량에서 한 코어의 절반이 감산되었습니다.Allocatable CPU
는 1500 밀리코어임을 확인할 수 있습니다. 즉, Pod마다 하나의 전체 코어를 사용하므로 CPU 관리자 Pod 중 하나를 실행할 수 있습니다. 전체 코어는 1000밀리코어에 해당합니다. 두 번째 Pod를 예약하려고 하면 시스템에서 해당 Pod를 수락하지만 Pod가 예약되지 않습니다.NAME READY STATUS RESTARTS AGE cpumanager-6cqz7 1/1 Running 0 33m cpumanager-7qc2t 0/1 Pending 0 11s
NAME READY STATUS RESTARTS AGE cpumanager-6cqz7 1/1 Running 0 33m cpumanager-7qc2t 0/1 Pending 0 11s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.2. 토폴로지 관리자 정책 링크 복사링크가 클립보드에 복사되었습니다!
토폴로지 관리자는 CPU 관리자 및 장치 관리자와 같은 힌트 공급자로부터 토폴로지 힌트를 수집하고 수집된 힌트로 Pod
리소스를 정렬하는 방법으로 모든 QoS(Quality of Service) 클래스의 Pod
리소스를 정렬합니다.
Topology Manager는 KubeletConfig
사용자 정의 리소스(CR)인 cpumanager-enabled
에서 할당하는 4가지 할당 정책을 지원합니다.
none
정책- 기본 정책으로, 토폴로지 정렬을 수행하지 않습니다.
best-effort
정책-
best-effort
토폴로지 관리 정책이 적용된 포드의 각 컨테이너에 대해 kubelet은 해당 컨테이너에 대한 기본 NUMA 노드 친화성에 따라 NUMA 노드에 필요한 모든 리소스를 정렬하려고 시도합니다. 리소스가 부족하여 할당이 불가능한 경우에도 토폴로지 관리자는 여전히 pod를 허용하지만 할당은 다른 NUMA 노드와 공유됩니다. restricted
정책-
restricted
토폴로지 관리 정책이 적용된 포드의 각 컨테이너에 대해 kubelet은 요청을 충족할 수 있는 이론적 최소 NUMA 노드 수를 결정합니다. 실제 할당에 해당 NUMA 노드 수보다 많은 것이 필요한 경우 토폴로지 관리자는 승인을 거부하고 pod를Terminated
상태로 전환합니다. NUMA 노드의 수가 요청을 충족할 수 있는 경우 토폴로지 관리자는 pod를 허용하고 pod가 실행을 시작합니다. single-numa-node
정책-
single-numa-node
토폴로지 관리 정책이 적용된 pod의 각 컨테이너에 대해 kubelet은 pod에 필요한 모든 리소스를 동일한 NUMA 노드에 할당할 수 있는 경우 해당 pod를 허용합니다. 단일 NUMA 노드 친화성이 불가능한 경우 토폴로지 관리자는 노드에서 pod를 거부합니다. 이로 인해 pod는Terminated
상태가 되고 pod 입장 실패가 발생합니다.
11.3. 토폴로지 관리자 설정 링크 복사링크가 클립보드에 복사되었습니다!
Topology Manager를 사용하려면 KubeletConfig
사용자 정의 리소스(CR)에서 cpumanager-enabled
라는 할당 정책을 구성해야 합니다. CPU 관리자를 설정한 경우 해당 파일이 존재할 수 있습니다. 파일이 없으면 파일을 생성할 수 있습니다.
사전 요구 사항
-
CPU 관리자 정책을
static
으로 구성하십시오.
프로세스
토폴로지 관리자를 활성화하려면:
사용자 지정 리소스에서 토폴로지 관리자 할당 정책을 구성합니다.
oc edit KubeletConfig cpumanager-enabled
$ oc edit KubeletConfig cpumanager-enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4. Pod와 토폴로지 관리자 정책 간의 상호 작용 링크 복사링크가 클립보드에 복사되었습니다!
예제 Pod
사양은 Topology Manager와 Pod의 상호작용을 보여줍니다.
다음 Pod는 리소스 요청 또는 제한이 지정되어 있지 않기 때문에 BestEffort
QoS 클래스에서 실행됩니다.
spec: containers: - name: nginx image: nginx
spec:
containers:
- name: nginx
image: nginx
다음 Pod는 요청이 제한보다 작기 때문에 Burstable
QoS 클래스에서 실행됩니다.
선택한 정책이 none
이 아닌 경우, 토폴로지 관리자는 모든 포드를 처리하고 Guaranteed
QoS Pod
사양에 대해서만 리소스 정렬을 적용합니다. Topology Manager 정책이 none
으로 설정된 경우 관련 컨테이너는 NUMA 친화성을 고려하지 않고 사용 가능한 CPU에 고정됩니다. 이는 기본 동작이며 성능에 민감한 작업 부하에 최적화되지 않습니다. 다른 값은 CPU 및 메모리와 같은 장치 플러그인 핵심 리소스에서 토폴로지 인식 정보를 사용할 수 있게 해줍니다. 정책이 none
외의 값으로 설정된 경우, 토폴로지 관리자는 노드의 토폴로지에 따라 CPU, 메모리 및 장치 할당을 정렬하려고 시도합니다. 사용 가능한 값에 대한 자세한 내용은 토폴로지 관리자 정책을 참조하세요.
다음 예제 pod 는 요청이 제한과 같기 때문에 Guaranteed
QoS 클래스에서 실행됩니다.
토폴로지 관리자는 이러한 Pod를 고려합니다. 토폴로지 관리자는 CPU 관리자, 장치 관리자, 메모리 관리자인 힌트 제공자를 참조하여 pod 에 대한 토폴로지 힌트를 얻습니다.
토폴로지 관리자는 이 정보를 사용하여 해당 컨테이너에 가장 적합한 토폴로지를 저장합니다. 이 Pod의 경우 CPU 관리자와 장치 관리자는 리소스 할당 단계에서 이러한 저장된 정보를 사용합니다.
12장. NUMA 인식 워크로드 예약 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 스케줄링에 대해 알아보고 이를 사용하여 OpenShift Container Platform 클러스터에서 고성능 워크로드를 배포하는 방법을 알아보세요.
NUMA 리소스 연산자를 사용하면 동일한 NUMA 영역에서 고성능 작업 부하를 예약할 수 있습니다. 사용 가능한 클러스터 노드 NUMA 리소스를 보고하는 노드 리소스 내보내기 에이전트와 작업 부하를 관리하는 보조 스케줄러를 배포합니다.
12.1. NUMA 소개 링크 복사링크가 클립보드에 복사되었습니다!
비균일 메모리 액세스(NUMA) 아키텍처는 CPU가 모든 위치의 모든 메모리에 동일한 속도로 액세스하지 않는 멀티프로세서 아키텍처 모델입니다. 그 대신 CPU는 자신과 더 가까운 메모리나 로컬 메모리에 더 빨리 접근할 수 있지만, 더 멀리 있는 메모리에 더 느리게 접근할 수 있습니다.
여러 개의 메모리 컨트롤러가 있는 CPU는 메모리가 어디에 위치하든 관계없이 CPU 복합체 전체에서 사용 가능한 모든 메모리를 사용할 수 있습니다. 그러나 이러한 유연성의 증가는 성능 저하로 이어집니다.
NUMA 리소스 토폴로지는 NUMA 영역 에서 CPU, 메모리, PCI 장치의 상대적인 물리적 위치를 나타냅니다. NUMA 아키텍처에서 NUMA 영역은 자체 프로세서와 메모리를 갖춘 CPU 그룹입니다. 동일한 NUMA 영역에 있는 리소스는 동일한 NUMA 영역에 있다고 하며, 한 영역 내의 CPU는 그 영역 외부의 CPU보다 동일한 로컬 메모리에 더 빠르게 액세스할 수 있습니다. NUMA 영역 외부에 있는 메모리를 사용하여 워크로드를 처리하는 CPU는 단일 NUMA 영역에서 처리되는 워크로드보다 느립니다. I/O가 제한된 작업 부하의 경우, 멀리 떨어진 NUMA 영역의 네트워크 인터페이스로 인해 정보가 애플리케이션에 도달하는 속도가 느려집니다.
애플리케이션은 동일한 NUMA 영역 내에 데이터와 처리를 포함함으로써 더 나은 성능을 달성할 수 있습니다. 통신 워크로드와 같은 고성능 워크로드 및 애플리케이션의 경우, 워크로드가 사양에 따라 작동할 수 있도록 클러스터는 단일 NUMA 영역에서 Pod 워크로드를 처리해야 합니다.
12.2. NUMA 인식 스케줄링에 관하여 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 스케줄링은 요청된 클러스터 컴퓨팅 리소스(CPU, 메모리, 장치)를 동일한 NUMA 영역에 정렬하여 지연에 민감한 작업이나 고성능 작업을 효율적으로 처리합니다. NUMA 인식 스케줄링은 더욱 큰 리소스 효율성을 위해 컴퓨팅 노드당 포드 밀도도 개선합니다.
12.2.1. 노드 튜닝 운영자와의 통합 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator의 성능 프로필을 NUMA 인식 스케줄링과 통합하면 대기 시간에 민감한 워크로드의 성능을 최적화하기 위해 CPU 친화성을 추가로 구성할 수 있습니다.
12.2.2. 기본 스케줄링 로직 링크 복사링크가 클립보드에 복사되었습니다!
기본 OpenShift Container Platform Pod 스케줄러 스케줄링 논리는 개별 NUMA 영역이 아닌 전체 컴퓨팅 노드의 사용 가능한 리소스를 고려합니다. Kubelet 토폴로지 관리자에서 가장 제한적인 리소스 정렬이 요청되면 포드를 노드에 허용할 때 오류 상황이 발생할 수 있습니다. 반대로, 가장 제한적인 리소스 정렬이 요청되지 않으면 포드가 적절한 리소스 정렬 없이 노드에 입장할 수 있으며, 이로 인해 성능이 저하되거나 예측할 수 없게 됩니다. 예를 들어, 토폴로지 친화성 오류
상태가 있는 폭주형 포드 생성은 포드 스케줄러가 포드의 요청된 리소스가 사용 가능한지 알지 못한 채 보장된 포드 워크로드에 대해 최적이 아닌 스케줄링 결정을 내릴 때 발생할 수 있습니다. 예약 불일치 결정으로 인해 Pod 시작 지연이 발생할 수 있습니다. 또한 클러스터 상태와 리소스 할당에 따라 잘못된 Pod 스케줄링 결정으로 인해 시작 시도가 실패하여 클러스터에 추가 부하가 발생할 수 있습니다.
12.2.3. NUMA 인식 Pod 스케줄링 다이어그램 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 운영자는 사용자 지정 NUMA 리소스 보조 스케줄러와 기타 리소스를 배포하여 기본 OpenShift Container Platform Pod 스케줄러의 단점을 완화합니다. 다음 다이어그램은 NUMA 인식 Pod 스케줄링에 대한 간략한 개요를 제공합니다.
그림 12.1. NUMA 인식 스케줄링 개요
- NodeResourceTopology API
-
NodeResourceTopology
API는 각 컴퓨팅 노드에서 사용 가능한 NUMA 영역 리소스를 설명합니다. - NUMA 인식 스케줄러
-
NUMA 인식 보조 스케줄러는
NodeResourceTopology
API에서 사용 가능한 NUMA 영역에 대한 정보를 수신하고 최적으로 처리할 수 있는 노드에서 고성능 워크로드를 스케줄링합니다. - 노드 토폴로지 내보내기
-
노드 토폴로지 내보내기 기능은 각 컴퓨팅 노드에 사용 가능한 NUMA 영역 리소스를
NodeResourceTopology
API에 공개합니다. 노드 토폴로지 내보내기 데몬은PodResources
API를 사용하여 kubelet의 리소스 할당을 추적합니다. - PodResources API
PodResources
API는 각 노드에 로컬하며 리소스 토폴로지와 사용 가능한 리소스를 kubelet에 공개합니다.참고PodResources
API의List
엔드포인트는 특정 컨테이너에 할당된 독점 CPU를 노출합니다. API는 공유 풀에 속한 CPU를 노출하지 않습니다.GetAllocatableResources
엔드포인트는 노드에서 사용 가능한 할당 가능한 리소스를 노출합니다.
12.3. NUMA 리소스 스케줄링 전략 링크 복사링크가 클립보드에 복사되었습니다!
고성능 작업 부하를 스케줄링할 때, 보조 스케줄러는 다양한 전략을 사용하여 선택된 작업자 노드 내에서 어떤 NUMA 노드가 작업 부하를 처리할지 결정할 수 있습니다. OpenShift Container Platform에서 지원되는 전략에는 LeastAllocated
, MostAllocated
, BalancedAllocation이
있습니다. 이러한 전략을 이해하면 성능과 리소스 활용을 위해 작업 부하 배치를 최적화하는 데 도움이 됩니다.
NUMA 인식 클러스터에서 고성능 작업이 예약되면 다음 단계가 발생합니다.
- 스케줄러는 먼저 클러스터 전체 기준에 따라 적합한 워커 노드를 선택합니다. 예를 들어 오염, 라벨 또는 리소스 가용성입니다.
- 작업자 노드가 선택된 후 스케줄러는 NUMA 노드를 평가하고 점수 매기기 전략을 적용하여 어떤 NUMA 노드가 작업 부하를 처리할지 결정합니다.
- 작업 부하가 예약된 후, 선택된 NUMA 노드의 리소스가 할당을 반영하도록 업데이트됩니다.
기본적으로 적용되는 전략은 LeastAllocated
전략입니다. 이렇게 하면 가장 사용 가능한 리소스가 많고 가장 적게 활용되는 NUMA 노드에 작업 부하가 할당됩니다. 이 전략의 목표는 경쟁을 줄이고 핫스팟을 피하기 위해 NUMA 노드에 작업 부하를 분산하는 것입니다.
다음 표는 다양한 전략과 그 결과를 요약한 것입니다.
득점 전략 요약
전략 | 설명 | 결과 |
---|---|---|
| 가장 많은 사용 가능한 리소스를 보유한 NUMA 노드를 선호합니다. | 경쟁을 줄이고 우선 순위가 높은 작업을 위한 여유 공간을 확보하기 위해 작업 부하를 분산합니다. |
| 사용 가능한 리소스가 가장 적은 NUMA 노드를 선호합니다. | 더 적은 수의 NUMA 노드에 작업 부하를 통합하여 다른 노드가 에너지 효율성에 집중할 수 있도록 지원합니다. |
| CPU와 메모리 사용량이 균형 잡힌 NUMA 노드를 선호합니다. | 불균형한 사용 패턴을 방지하여 균등한 리소스 활용을 보장합니다. |
LeastAllocated 전략 예시
LeastAllocated
가 기본 전략입니다. 이 전략은 가장 많은 리소스가 있는 NUMA 노드에 작업 부하를 할당하여 리소스 경합을 최소화하고 NUMA 노드 전반에 작업 부하를 분산합니다. 이를 통해 핫스팟이 줄어들고 우선 순위가 높은 작업에 충분한 여유 공간이 확보됩니다. 워커 노드에 두 개의 NUMA 노드가 있고 작업 부하에 4개의 vCPU와 8GB의 메모리가 필요하다고 가정해 보겠습니다.
NUMA 노드 | 총 CPU | 사용된 CPU | 총 메모리(GB) | 사용된 메모리(GB) | 사용 가능한 리소스 |
---|---|---|---|---|---|
NUMA 1 | 16 | 12 | 64 | 56 | 4개의 CPU, 8GB 메모리 |
NUMA 2 | 16 | 6 | 64 | 24 | 10개의 CPU, 40GB 메모리 |
NUMA 2는 NUMA 1에 비해 사용 가능한 리소스가 더 많으므로 작업 부하가 NUMA 2에 할당됩니다.
MostAllocated 전략 예시
MostAllocated
전략은 사용 가능한 리소스가 가장 적은 NUMA 노드, 즉 가장 많이 활용되는 NUMA 노드에 작업 부하를 할당하여 작업 부하를 통합합니다. 이러한 접근 방식은 다른 NUMA 노드가 에너지 효율성이나 완전한 격리가 필요한 중요한 작업 부하를 처리할 수 있도록 도와줍니다. 이 예제에서는 최소 할당
섹션에 나열된 "예시 초기 NUMA 노드 상태" 값을 사용합니다.
작업 부하에는 다시 4개의 vCPU와 8GB 메모리가 필요합니다. NUMA 1은 NUMA 2에 비해 사용 가능한 리소스가 적으므로 스케줄러는 NUMA 1에 작업 부하를 할당하여 NUMA 2를 유휴 상태 또는 최소한의 부하로 남겨두면서 리소스를 더욱 활용합니다.
BalancedAllocation 전략 예시
BalancedAllocation
전략은 CPU와 메모리에서 리소스 활용도가 가장 균형 잡힌 NUMA 노드에 작업 부하를 할당합니다. 목표는 CPU 사용률이 높고 메모리 활용도가 낮은 등 사용 불균형을 방지하는 것입니다. 작업자 노드에 다음과 같은 NUMA 노드 상태가 있다고 가정합니다.
NUMA 노드 | CPU 사용량 | 메모리 사용량 | BalancedAllocation 점수 |
---|---|---|---|
NUMA 1 | 60% | 55% | 높음(더 균형 잡힌) |
NUMA 2 | 80% | 20% | 낮음(균형이 덜 잡힘) |
NUMA 1은 NUMA 2에 비해 CPU와 메모리 활용도가 더 균형 잡혀 있으므로 BalancedAllocation
전략을 적용하면 작업 부하가 NUMA 1에 할당됩니다.
12.4. NUMA 리소스 운영자 설치 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 Operator는 NUMA 인식 워크로드 및 배포를 예약할 수 있는 리소스를 배포합니다. OpenShift Container Platform CLI나 웹 콘솔을 사용하여 NUMA Resources Operator를 설치할 수 있습니다.
12.4.1. CLI를 사용하여 NUMA 리소스 운영자 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
NUMA 리소스 연산자에 대한 네임스페이스를 만듭니다.
다음 YAML을
nro-namespace.yaml
파일에 저장합니다.apiVersion: v1 kind: Namespace metadata: name: openshift-numaresources
apiVersion: v1 kind: Namespace metadata: name: openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
네임스페이스
CR을 만듭니다.oc create -f nro-namespace.yaml
$ oc create -f nro-namespace.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NUMA 리소스 운영자에 대한 운영자 그룹을 만듭니다.
다음 YAML을
nro-operatorgroup.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
OperatorGroup
CR을 생성합니다.oc create -f nro-operatorgroup.yaml
$ oc create -f nro-operatorgroup.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
NUMA 리소스 운영자에 대한 구독을 만듭니다.
다음 YAML을
nro-sub.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
구독
CR을 만듭니다.oc create -f nro-sub.yaml
$ oc create -f nro-sub.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
openshift-numaresources
네임스페이스의 CSV 리소스를 검사하여 설치가 성공했는지 확인하세요. 다음 명령을 실행합니다.oc get csv -n openshift-numaresources
$ oc get csv -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME DISPLAY VERSION REPLACES PHASE numaresources-operator.v4.19.2 numaresources-operator 4.19.2 Succeeded
NAME DISPLAY VERSION REPLACES PHASE numaresources-operator.v4.19.2 numaresources-operator 4.19.2 Succeeded
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4.2. 웹 콘솔을 사용하여 NUMA 리소스 운영자 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 웹 콘솔을 사용하여 NUMA 리소스 운영자를 설치할 수 있습니다.
프로세스
NUMA 리소스 연산자에 대한 네임스페이스를 만듭니다.
- OpenShift Container Platform 웹 콘솔에서 관리 → 네임스페이스를 클릭합니다.
-
네임스페이스 만들기를 클릭하고 이름 필드에
openshift-numaresources를
입력한 다음 만들기를 클릭합니다.
NUMA 리소스 운영자를 설치하세요:
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 연산자 목록에서 numarsources-operator를 선택한 다음 설치를 클릭합니다.
-
설치된 네임스페이스 필드에서
openshift-numaresources
네임스페이스를 선택한 다음 설치를 클릭합니다.
선택 사항: NUMA Resources Operator가 성공적으로 설치되었는지 확인하세요.
- Operator → 설치된 Operator 페이지로 전환합니다.
NUMA Resources Operator가 InstallSucceeded된 상태로
openshift-numaresources
네임스페이스에 나열되어 있는지 확인합니다.참고설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
-
워크로드 → 포드 페이지로 이동하여
기본
프로젝트의 포드 로그를 확인하세요.
12.5. 단일 NUMA 노드 정책 구성 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 운영자는 클러스터에서 단일 NUMA 노드 정책을 구성해야 합니다. 이는 두 가지 방법으로 달성할 수 있습니다. 성능 프로필을 생성하고 적용하거나 KubeletConfig를 구성하는 것입니다.
단일 NUMA 노드 정책을 구성하는 가장 좋은 방법은 성능 프로필을 적용하는 것입니다. 성과 프로필 생성기(PPC) 도구를 사용하여 성과 프로필을 생성할 수 있습니다. 클러스터에서 성능 프로필이 생성되면 KubeletConfig
및 튜닝된
프로필과 같은 다른 튜닝 구성 요소도 자동으로 생성됩니다.
성과 프로필 생성에 대한 자세한 내용은 "추가 리소스" 섹션의 "성과 프로필 생성기 정보"를 참조하세요.
12.5.1. 성능 프로파일의 예 링크 복사링크가 클립보드에 복사되었습니다!
이 YAML 예제는 PPC(성능 프로필 생성기) 도구를 사용하여 생성된 성능 프로필을 보여줍니다.
- 1
- 이 값은 NUMA 리소스 연산자를 구성하려는
MachineConfigPool
값과 일치해야 합니다. 예를 들어, 통신 작업을 실행하는 노드 집합을 지정하는worker-cnf
라는MachineConfigPool
객체를 만들 수 있습니다.MachineConfigPool
의 값은 나중에 "NUMAResourcesOperator 사용자 정의 리소스 만들기"에서 구성하는NUMAResourcesOperator
CR의machineConfigPoolSelector
값과 일치해야 합니다. - 2
- PPC 도구를 실행할 때
topology-manager-policy
인수를single-numa-node
로 설정하여topologyPolicy
필드가single-numa-node
로 설정되어 있는지 확인합니다.참고호스팅된 제어 평면 클러스터의 경우
machineConfigPoolSelector는
어떠한 기능적 효과도 미치지 않습니다. 대신 노드 연결은 지정된NodePool
개체에 의해 결정됩니다.
12.5.2. KubeletConfig CR 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 NUMA 노드 정책을 구성하는 데 권장되는 방법은 성능 프로필을 적용하는 것입니다. 또 다른 방법은 다음 절차에 표시된 대로 KubeletConfig
사용자 정의 리소스(CR)를 만들고 적용하는 것입니다.
프로세스
머신 프로필에 대한 포드 입장 정책을 구성하는
KubeletConfig
사용자 정의 리소스(CR)를 만듭니다.다음 YAML을
nro-kubeletconfig.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 레이블이 나중에 "NUMAResourcesOperator 사용자 정의 리소스 만들기"에서 구성하는
NUMAResourcesOperator
CR의machineConfigPoolSelector
설정과 일치하는지 확인하세요. - 2
cpuManagerPolicy
의 경우static은
소문자s를
사용해야 합니다.- 3
- 노드의 CPU에 따라 이를 조정하세요.
- 4
memoryManagerPolicy
의 경우Static은
대문자S를
사용해야 합니다.- 5
topologyManagerPolicy는
single-numa-node
로 설정되어야 합니다.
참고호스팅된 제어 평면 클러스터의 경우
machineConfigPoolSelector
설정은 어떠한 기능적 영향도 미치지 않습니다. 대신 노드 연결은 지정된NodePool
개체에 의해 결정됩니다. 호스팅된 제어 평면 클러스터에KubeletConfig를
적용하려면 구성이 포함된ConfigMap을
만든 다음NodePool
의spec.config
필드 내에서 해당ConfigMap을
참조해야 합니다.다음 명령을 실행하여
KubeletConfig
CR을 만듭니다.oc create -f nro-kubeletconfig.yaml
$ oc create -f nro-kubeletconfig.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고성능 프로필이나
KubeletConfig를
적용하면 노드가 자동으로 재부팅됩니다. 재부팅이 발생하지 않으면KubeletConfig
에서 노드 그룹을 나타내는 레이블을 확인하여 문제를 해결할 수 있습니다.
12.6. NUMA 인식 워크로드 예약 링크 복사링크가 클립보드에 복사되었습니다!
지연 시간에 민감한 워크로드를 실행하는 클러스터는 일반적으로 워크로드 지연 시간을 최소화하고 성능을 최적화하는 데 도움이 되는 성능 프로필을 갖추고 있습니다. NUMA 인식 스케줄러는 사용 가능한 노드 NUMA 리소스와 노드에 적용된 모든 성능 프로필 설정을 기준으로 작업 부하를 배포합니다. NUMA 인식 배포와 워크로드의 성능 프로필을 결합하면 워크로드가 성능을 극대화하는 방식으로 예약됩니다.
NUMA 리소스 운영자가 완전히 작동하려면 NUMAResourcesOperator
사용자 지정 리소스와 NUMA 인식 보조 포드 스케줄러를 배포해야 합니다.
12.6.1. NUMAResourcesOperator 사용자 정의 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
NUMA Resources Operator를 설치한 후 NUMA Resources Operator가 데몬 세트와 API를 포함하여 NUMA 인식 스케줄러를 지원하는 데 필요한 모든 클러스터 인프라를 설치하도록 지시하는 NUMAResourcesOperator
사용자 지정 리소스(CR)를 만듭니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - NUMA 리소스 운영자를 설치합니다.
프로세스
NUMAResourcesOperator
사용자 지정 리소스를 만듭니다.다음의 최소 필수 YAML 파일 예를
nrop.yaml
로 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이는 NUMA 리소스 연산자를 구성하려는
MachineConfigPool
리소스와 일치해야 합니다. 예를 들어, 통신 작업을 실행할 것으로 예상되는 노드 집합을 지정하는worker-cnf
라는MachineConfigPool
리소스를 만들었을 수 있습니다. 각NodeGroup은
정확히 하나의MachineConfigPool
과 일치해야 합니다.NodeGroup이
두 개 이상의MachineConfigPool
과 일치하는 구성은 지원되지 않습니다.
다음 명령을 실행하여
NUMAResourcesOperator
CR을 만듭니다.oc create -f nrop.yaml
$ oc create -f nrop.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
선택 사항: 여러 머신 구성 풀(MCP)에 대해 NUMA 인식 스케줄링을 활성화하려면 각 풀에 대해 별도의
NodeGroup을
정의합니다. 예를 들어, 다음 예와 같이NUMAResourcesOperator
CR에서worker-cnf
,worker-ht
및worker-other
에 대한 세 개의NodeGroup을
정의합니다.여러
NodeGroups가
있는NUMAResourcesOperator
CR에 대한 YAML 정의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 NUMA 리소스 운영자가 성공적으로 배포되었는지 확인하세요.
oc get numaresourcesoperators.nodetopology.openshift.io
$ oc get numaresourcesoperators.nodetopology.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesoperator 27s
NAME AGE numaresourcesoperator 27s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 몇 분 후, 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인하세요.
oc get all -n openshift-numaresources
$ oc get all -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE pod/numaresources-controller-manager-7d9d84c58d-qk2mr 1/1 Running 0 12m pod/numaresourcesoperator-worker-7d96r 2/2 Running 0 97s pod/numaresourcesoperator-worker-crsht 2/2 Running 0 97s pod/numaresourcesoperator-worker-jp9mw 2/2 Running 0 97s
NAME READY STATUS RESTARTS AGE pod/numaresources-controller-manager-7d9d84c58d-qk2mr 1/1 Running 0 12m pod/numaresourcesoperator-worker-7d96r 2/2 Running 0 97s pod/numaresourcesoperator-worker-crsht 2/2 Running 0 97s pod/numaresourcesoperator-worker-jp9mw 2/2 Running 0 97s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.6.2. 호스팅된 제어 평면에 대한 NUMAResourcesOperator 사용자 지정 리소스 만들기 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 연산자를 설치한 후 NUMAResourcesOperator
사용자 정의 리소스(CR)를 만듭니다. CR은 NUMA 리소스 운영자에게 데몬 세트와 API를 포함하여 호스팅된 제어 평면에서 NUMA 인식 스케줄러를 지원하는 데 필요한 모든 클러스터 인프라를 설치하도록 지시합니다.
호스팅된 제어 평면에 대한 NUMAResourcesOperator 사용자 지정 리소스를 만드는 것은 기술 미리 보기 기능에만 해당됩니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - NUMA 리소스 운영자를 설치합니다.
프로세스
다음 명령을 실행하여 관리 클러스터 kubeconfig 파일을 내보냅니다.
export KUBECONFIG=<path-to-management-cluster-kubeconfig>
$ export KUBECONFIG=<path-to-management-cluster-kubeconfig>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터의
노드 풀 이름을
찾으세요.oc --kubeconfig="$MGMT_KUBECONFIG" get np -A
$ oc --kubeconfig="$MGMT_KUBECONFIG" get np -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters democluster-us-east-1a democluster 1 1 False False 4.19.0 False False
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters democluster-us-east-1a democluster 1 1 False False 4.19.0 False False
Copy to Clipboard Copied! Toggle word wrap Toggle overflow node-pool-name은
출력의NAME
필드입니다. 이 예에서노드 풀 이름
은democluster-us-east-1a
입니다.최소한 다음 내용을 포함하는
nrop-hcp.yaml
이라는 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
poolName
은 2단계에서 검색된노드 풀 이름
입니다.
관리 클러스터에서 다음 명령을 실행하여 사용 가능한 비밀을 나열합니다.
oc get secrets -n clusters
$ oc get secrets -n clusters
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터의
kubeconfig
파일을 추출합니다.oc get secret <SECRET_NAME> -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
$ oc get secret <SECRET_NAME> -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예
oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
$ oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터
kubeconfig
파일을 내보냅니다.export HC_KUBECONFIG=<path_to_hosted-cluster-kubeconfig>
$ export HC_KUBECONFIG=<path_to_hosted-cluster-kubeconfig>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터에서 다음 명령을 실행하여
NUMAResourcesOperator
CR을 만듭니다.oc create -f nrop-hcp.yaml
$ oc create -f nrop-hcp.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 NUMA 리소스 운영자가 성공적으로 배포되었는지 확인하세요.
oc get numaresourcesoperators.nodetopology.openshift.io
$ oc get numaresourcesoperators.nodetopology.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesoperator 27s
NAME AGE numaresourcesoperator 27s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 몇 분 후, 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인하세요.
oc get all -n openshift-numaresources
$ oc get all -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE pod/numaresources-controller-manager-7d9d84c58d-qk2mr 1/1 Running 0 12m pod/numaresourcesoperator-democluster-7d96r 2/2 Running 0 97s pod/numaresourcesoperator-democluster-crsht 2/2 Running 0 97s pod/numaresourcesoperator-democluster-jp9mw 2/2 Running 0 97s
NAME READY STATUS RESTARTS AGE pod/numaresources-controller-manager-7d9d84c58d-qk2mr 1/1 Running 0 12m pod/numaresourcesoperator-democluster-7d96r 2/2 Running 0 97s pod/numaresourcesoperator-democluster-crsht 2/2 Running 0 97s pod/numaresourcesoperator-democluster-jp9mw 2/2 Running 0 97s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.6.3. NUMA 인식 보조 포드 스케줄러 배포 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 연산자를 설치한 후 다음 절차에 따라 NUMA 인식 보조 포드 스케줄러를 배포합니다.
프로세스
NUMA 인식 사용자 정의 Pod 스케줄러를 배포하는
NUMAResourcesScheduler
사용자 정의 리소스를 만듭니다.다음의 최소한의 필수 YAML을
nro-scheduler.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 연결이 끊긴 환경에서는 다음 중 하나를 수행하여 이 이미지의 해상도를 구성해야 합니다.
-
ImageTagMirrorSet
사용자 정의 리소스(CR) 생성. 자세한 내용은 "추가 리소스" 섹션의 "이미지 레지스트리 저장소 미러링 구성"을 참조하세요. - 연결이 끊긴 레지스트리에 URL을 설정합니다.
-
다음 명령을 실행하여
NUMAResourcesScheduler
CR을 만듭니다.oc create -f nro-scheduler.yaml
$ oc create -f nro-scheduler.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고호스팅된 제어 평면 클러스터에서 호스팅된 제어 평면 노드에서 이 명령을 실행합니다.
몇 초 후에 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인하세요.
oc get all -n openshift-numaresources
$ oc get all -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.6.4. NUMA 인식 스케줄러를 사용한 작업 스케줄링 링크 복사링크가 클립보드에 복사되었습니다!
이제 topo-aware-scheduler가
설치되었고 NUMAResourcesOperator
및 NUMAResourcesScheduler
CR이 적용되었으며 클러스터에 일치하는 성능 프로필이나 kubeletconfig
가 있으므로 워크로드를 처리하는 데 필요한 최소 리소스를 지정하는 배포 CR을 사용하여 NUMA 인식 스케줄러로 워크로드를 예약할 수 있습니다.
다음 예제 배포에서는 샘플 워크로드에 대해 NUMA 인식 스케줄링을 사용합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
다음 명령을 실행하여 클러스터에 배포된 NUMA 인식 스케줄러의 이름을 가져옵니다.
oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
$ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
"topo-aware-scheduler"
"topo-aware-scheduler"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어
topo-aware-scheduler
라는 스케줄러를 사용하는배포
CR을 만듭니다.다음 YAML을
nro-deployment.yaml
파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
schedulerName은
클러스터에 배포된 NUMA 인식 스케줄러의 이름과 일치해야 합니다(예:topo-aware-scheduler )
.
다음 명령을 실행하여
배포
CR을 만듭니다.oc create -f nro-deployment.yaml
$ oc create -f nro-deployment.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
배포가 성공했는지 확인하세요.
oc get pods -n openshift-numaresources
$ oc get pods -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
topo-aware-scheduler가
배포된 Pod를 예약하는지 확인하세요.oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources
$ oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 4m45s topo-aware-scheduler Successfully assigned openshift-numaresources/numa-deployment-1-6c4f5bdb84-wgn6g to worker-1
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 4m45s topo-aware-scheduler Successfully assigned openshift-numaresources/numa-deployment-1-6c4f5bdb84-wgn6g to worker-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고스케줄링에 사용할 수 있는 리소스보다 많은 리소스를 요청하는 배포는
MinimumReplicasUnavailable
오류로 인해 실패합니다. 필요한 리소스를 사용할 수 있게 되면 배포가 성공합니다. 필요한 리소스가 제공될 때까지 Pod는보류
상태로 유지됩니다.노드에 대해 예상 할당 리소스가 나열되어 있는지 확인합니다.
다음 명령을 실행하여 배포 포드를 실행하는 노드를 식별합니다.
oc get pods -n openshift-numaresources -o wide
$ oc get pods -n openshift-numaresources -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES numa-deployment-1-6c4f5bdb84-wgn6g 0/2 Running 0 82m 10.128.2.50 worker-1 <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES numa-deployment-1-6c4f5bdb84-wgn6g 0/2 Running 0 82m 10.128.2.50 worker-1 <none> <none>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 배포 포드를 실행 중인 노드의 이름으로 다음 명령을 실행합니다.
oc describe noderesourcetopologies.topology.node.k8s.io worker-1
$ oc describe noderesourcetopologies.topology.node.k8s.io worker-1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 보장된 포드에 할당된 리소스로 인해
사용 가능한
용량이 감소합니다.
보장된 포드에서 사용되는 리소스는
noderesourcetopologies.topology.node.k8s.io
에 나열된 사용 가능한 노드 리소스에서 빼집니다.
Best-effort
또는Burstable
서비스 품질(qosClass
)을 갖춘 포드에 대한 리소스 할당은noderesourcetopologies.topology.node.k8s.io
아래의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 소모된 리소스가 노드 리소스 계산에 반영되지 않는 경우 Pod에보장된
qosClass
가 있고 CPU 요청이 십진수 값이 아닌 정수 값인지 확인합니다. 다음 명령을 실행하여 Pod의qosClass
가Guaranteed
인지 확인할 수 있습니다.oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"
$ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Guaranteed
Guaranteed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.7. 선택 사항: NUMA 리소스 업데이트에 대한 폴링 작업 구성 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 운영자가 제어하는 데몬은 노드 그룹
에서 리소스를 폴링하여 사용 가능한 NUMA 리소스에 대한 업데이트를 검색합니다. NUMAResourcesOperator
사용자 정의 리소스(CR)에서 spec.nodeGroups
사양을 구성하여 이러한 데몬에 대한 폴링 작업을 미세 조정할 수 있습니다. 이를 통해 여론조사 작업에 대한 고급 제어가 가능합니다. 이러한 사양을 구성하여 스케줄링 동작을 개선하고 최적이 아닌 스케줄링 결정에 대한 문제를 해결하세요.
구성 옵션은 다음과 같습니다.
-
infoRefreshMode
: kubelet을 폴링하기 위한 트리거 조건을 결정합니다. NUMA 리소스 운영자는 결과 정보를 API 서버에 보고합니다. -
infoRefreshPeriod
: 폴링 업데이트 사이의 기간을 결정합니다. podsFingerprinting
: 노드에서 실행 중인 현재 포드 세트에 대한 특정 시점 정보가 폴링 업데이트에 노출되는지 여부를 결정합니다.참고podsFingerprinting
의 기본값은EnabledExclusiveResources
입니다. 스케줄러 성능을 최적화하려면podsFingerprinting을
EnabledExclusiveResources
또는Enabled
로 설정합니다. 또한NUMAResourcesScheduler
사용자 정의 리소스(CR)의cacheResyncPeriod를
0보다 큰 값으로 구성합니다.cacheResyncPeriod
사양은 노드에서 보류 중인 리소스를 모니터링하여 더 정확한 리소스 가용성을 보고하는 데 도움이 됩니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다. - NUMA 리소스 운영자를 설치합니다.
프로세스
NUMAResourcesOperator
CR에서spec.nodeGroups
사양을 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 유효한 값은
Periodic
,Events
,PeriodicAndEvents
입니다.infoRefreshPeriod
에서 정의한 간격으로 kubelet을 폴링하려면Periodic을
사용합니다.이벤트를
사용하여 모든 Pod 수명 주기 이벤트에서 kubelet을 폴링합니다.PeriodicAndEvents를
사용하여 두 가지 방법을 모두 활성화합니다. - 2
주기적
또는PeriodicAndEvents
새로 고침 모드에 대한 폴링 간격을 정의합니다. 새로 고침 모드가이벤트
인 경우 필드는 무시됩니다.- 3
- 유효한 값은
Enabled
,Disabled
,EnabledExclusiveResources
입니다.NUMAResourcesScheduler
의cacheResyncPeriod
사양을 사용하려면Enabled
또는EnabledExclusiveResources
로 설정해야 합니다.
검증
NUMA 리소스 연산자를 배포한 후 다음 명령을 실행하여 노드 그룹 구성이 적용되었는지 확인하세요.
oc get numaresop numaresourcesoperator -o json | jq '.status'
$ oc get numaresop numaresourcesoperator -o json | jq '.status'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8. NUMA 인식 스케줄링 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 Pod 스케줄링과 관련된 일반적인 문제를 해결하려면 다음 단계를 수행하세요.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc
)를 설치합니다. - cluster-admin 권한이 있는 사용자로 로그인합니다.
- NUMA 리소스 운영자를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
프로세스
다음 명령을 실행하여
noderesourcetopologies
CRD가 클러스터에 배포되었는지 확인하세요.oc get crd | grep noderesourcetopologies
$ oc get crd | grep noderesourcetopologies
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CREATED AT noderesourcetopologies.topology.node.k8s.io 2022-01-18T08:28:06Z
NAME CREATED AT noderesourcetopologies.topology.node.k8s.io 2022-01-18T08:28:06Z
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 NUMA 인식 스케줄러 이름이 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인하세요.
oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
$ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
topo-aware-scheduler
topo-aware-scheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NUMA 인식 스케줄 가능 노드에 CR이 적용된
noderesourcetopologies
가 있는지 확인합니다. 다음 명령을 실행합니다.oc get noderesourcetopologies.topology.node.k8s.io
$ oc get noderesourcetopologies.topology.node.k8s.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE compute-0.example.com 17h compute-1.example.com 17h
NAME AGE compute-0.example.com 17h compute-1.example.com 17h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고노드 수는 머신 구성 풀(
mcp
) 작업자 정의에서 구성된 작업자 노드 수와 같아야 합니다.다음 명령을 실행하여 모든 예약 가능한 노드에 대한 NUMA 영역 세분성을 확인하세요.
oc get noderesourcetopologies.topology.node.k8s.io -o yaml
$ oc get noderesourcetopologies.topology.node.k8s.io -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.1. 더욱 정확한 리소스 가용성 보고 링크 복사링크가 클립보드에 복사되었습니다!
cacheResyncPeriod
사양을 활성화하면 NUMA 리소스 운영자가 노드에서 보류 중인 리소스를 모니터링하고 정의된 간격으로 스케줄러 캐시에서 이 정보를 동기화하여 더욱 정확한 리소스 가용성을 보고할 수 있습니다. 이는 최적이 아닌 스케줄링 결정으로 인해 발생하는 토폴로지 친화성 오류를 최소화하는 데에도 도움이 됩니다. 간격이 낮을수록 네트워크 부하가 커집니다. cacheResyncPeriod
사양은 기본적으로 비활성화되어 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
현재 실행 중인
NUMAResourcesScheduler
리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler를
가져옵니다.oc get NUMAResourcesScheduler
$ oc get NUMAResourcesScheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 92m
NAME AGE numaresourcesscheduler 92m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
oc delete NUMAResourcesScheduler numaresourcesscheduler
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 YAML을
nro-scheduler-cacheresync.yaml
파일에 저장합니다. 이 예에서는 로그 수준을Debug
로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 스케줄러 캐시 동기화를 위한 간격 값을 초 단위로 입력합니다. 대부분의 구현에서는
5초의
값이 일반적입니다.
다음 명령을 실행하여 업데이트된
NUMAResourcesScheduler
리소스를 만듭니다.oc create -f nro-scheduler-cacheresync.yaml
$ oc create -f nro-scheduler-cacheresync.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증 단계
NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.
oc get crd | grep numaresourcesschedulers
$ oc get crd | grep numaresourcesschedulers
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
oc get numaresourcesschedulers.nodetopology.openshift.io
$ oc get numaresourcesschedulers.nodetopology.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 3h26m
NAME AGE numaresourcesscheduler 3h26m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.
다음 명령을 실행하여
openshift-numaresources
네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.oc get pods -n openshift-numaresources
$ oc get pods -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE numaresources-controller-manager-d87d79587-76mrm 1/1 Running 0 46h numaresourcesoperator-worker-5wm2k 2/2 Running 0 45h numaresourcesoperator-worker-pb75c 2/2 Running 0 45h secondary-scheduler-7976c4d466-qm4sc 1/1 Running 0 21m
NAME READY STATUS RESTARTS AGE numaresources-controller-manager-d87d79587-76mrm 1/1 Running 0 46h numaresourcesoperator-worker-5wm2k 2/2 Running 0 45h numaresourcesoperator-worker-pb75c 2/2 Running 0 45h secondary-scheduler-7976c4d466-qm4sc 1/1 Running 0 21m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.
oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
$ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.2. 고성능 워크로드가 실행되는 위치 변경 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 보조 스케줄러는 작업자 노드와 워크로드를 최적으로 처리할 수 있는 NUMA 노드에서 고성능 워크로드를 스케줄링합니다. 기본적으로 보조 스케줄러는 가장 사용 가능한 리소스가 있는 선택한 작업자 노드 내의 NUMA 노드에 워크로드를 할당합니다.
워크로드가 실행되는 위치를 변경하려면 scoringStrategy
설정을 NUMAResourcesScheduler
사용자 정의 리소스에 추가하고 해당 값을 MostAllocated
또는 BalancedAllocation
으로 설정할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
다음 단계를 사용하여 현재 실행 중인
NUMAResourcesScheduler
리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler
를 가져옵니다.oc get NUMAResourcesScheduler
$ oc get NUMAResourcesScheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 92m
NAME AGE numaresourcesscheduler 92m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
oc delete NUMAResourcesScheduler numaresourcesscheduler
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
nro-scheduler-mostallocated.yaml
파일에 다음 YAML을 저장합니다. 이 예제에서는scoringStrategy
를MostAllocated
로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
scoringStrategy
구성이 생략되면 기본값LeastAllocated
가 적용됩니다.
다음 명령을 실행하여 업데이트된
NUMAResourcesScheduler
리소스를 만듭니다.oc create -f nro-scheduler-mostallocated.yaml
$ oc create -f nro-scheduler-mostallocated.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 단계를 사용하여 NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD(사용자 정의 리소스 정의)가 성공적으로 생성되었는지 확인합니다.
oc get crd | grep numaresourcesschedulers
$ oc get crd | grep numaresourcesschedulers
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
oc get numaresourcesschedulers.nodetopology.openshift.io
$ oc get numaresourcesschedulers.nodetopology.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 3h26m
NAME AGE numaresourcesscheduler 3h26m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 스케줄러의 관련
ConfigMap
리소스를 확인하여ScoringStrategy
가 올바르게 적용되었는지 확인합니다.oc get -n openshift-numaresources cm topo-aware-scheduler-config -o yaml | grep scoring -A 1
$ oc get -n openshift-numaresources cm topo-aware-scheduler-config -o yaml | grep scoring -A 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
scoringStrategy: type: MostAllocated
scoringStrategy: type: MostAllocated
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.3. NUMA 인식 스케줄러 로그 확인 링크 복사링크가 클립보드에 복사되었습니다!
로그를 검토하여 NUMA 인식 스케줄러의 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler
리소스의 spec.logLevel
필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal
,Debug
및 Trace
이며 Trace
는 가장 자세한 옵션입니다.
보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 다시 배포합니다. 이 다운타임 동안 새 워크로드를 예약할 수 없습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
현재 실행 중인
NUMAResourcesScheduler
리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler
를 가져옵니다.oc get NUMAResourcesScheduler
$ oc get NUMAResourcesScheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 90m
NAME AGE numaresourcesscheduler 90m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
oc delete NUMAResourcesScheduler numaresourcesscheduler
$ oc delete NUMAResourcesScheduler numaresourcesscheduler
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
nro-scheduler-debug.yaml
파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을Debug
로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 업데이트된
Debug
loggingNUMAResourcesScheduler
리소스를 만듭니다.oc create -f nro-scheduler-debug.yaml
$ oc create -f nro-scheduler-debug.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증 단계
NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.
oc get crd | grep numaresourcesschedulers
$ oc get crd | grep numaresourcesschedulers
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
NAME CREATED AT numaresourcesschedulers.nodetopology.openshift.io 2022-02-25T11:57:03Z
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
oc get numaresourcesschedulers.nodetopology.openshift.io
$ oc get numaresourcesschedulers.nodetopology.openshift.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 3h26m
NAME AGE numaresourcesscheduler 3h26m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.
다음 명령을 실행하여
openshift-numaresources
네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.oc get pods -n openshift-numaresources
$ oc get pods -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE numaresources-controller-manager-d87d79587-76mrm 1/1 Running 0 46h numaresourcesoperator-worker-5wm2k 2/2 Running 0 45h numaresourcesoperator-worker-pb75c 2/2 Running 0 45h secondary-scheduler-7976c4d466-qm4sc 1/1 Running 0 21m
NAME READY STATUS RESTARTS AGE numaresources-controller-manager-d87d79587-76mrm 1/1 Running 0 46h numaresourcesoperator-worker-5wm2k 2/2 Running 0 45h numaresourcesoperator-worker-pb75c 2/2 Running 0 45h secondary-scheduler-7976c4d466-qm4sc 1/1 Running 0 21m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.
oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
$ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.4. 리소스 토폴로지 내보내기 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
해당 resource-topology-exporter
로그를 검사하여 예기치 않은 결과가 발생하는 noderesourcetopologies
오브젝트의 문제를 해결합니다.
해당 노드에서 클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름을 지정하는 것이 좋습니다. 예를 들어, 이름이 worker
인 작업자 노드에는 worker
라는 해당 noderesourcetopologies
오브젝트가 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
NUMA Resources Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는
NUMAResourcesOperator
CR에 해당nodeGroup
이 있습니다. 다음 명령을 실행합니다.oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"
$ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
{"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
{"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이전 단계의
name
에 대한 값을 사용하여 관심 있는 데몬 세트의 레이블을 가져옵니다.oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"
$ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
{"name":"resource-topology"}
{"name":"resource-topology"}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
resource-topology
레이블을 사용하여 Pod를 가져옵니다.oc get pods -n openshift-numaresources -l name=resource-topology -o wide
$ oc get pods -n openshift-numaresources -l name=resource-topology -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE IP NODE numaresourcesoperator-worker-5wm2k 2/2 Running 0 2d1h 10.135.0.64 compute-0.example.com numaresourcesoperator-worker-pb75c 2/2 Running 0 2d1h 10.132.2.33 compute-1.example.com
NAME READY STATUS RESTARTS AGE IP NODE numaresourcesoperator-worker-5wm2k 2/2 Running 0 2d1h 10.135.0.64 compute-0.example.com numaresourcesoperator-worker-pb75c 2/2 Running 0 2d1h 10.132.2.33 compute-1.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 문제 해결 중인 노드에 해당하는 작업자 Pod에서 실행 중인
resource-topology-exporter
컨테이너의 로그를 검사합니다. 다음 명령을 실행합니다.oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c
$ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.5. 누락된 리소스 토폴로지 내보내기 구성 맵 수정 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 설정이 잘못 구성된 클러스터에 NUMA Resources Operator를 설치하는 경우 Operator가 active로 표시되지만 RTE(Resource topology exporter) 데몬 세트 Pod의 로그에 RTE의 구성이 누락되어 있음을 보여줍니다.
Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"
Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"
이 로그 메시지는 필요한 구성이 있는 kubeletconfig
가 클러스터에 제대로 적용되지 않아 RTE configmap
이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에 numaresourcesoperator-worker
configmap
CR (사용자 정의 리소스)이 없습니다.
oc get configmap
$ oc get configmap
출력 예
NAME DATA AGE 0e2a6bd3.openshift-kni.io 0 6d21h kube-root-ca.crt 1 6d21h openshift-service-ca.crt 1 6d21h topo-aware-scheduler-config 1 6d18h
NAME DATA AGE
0e2a6bd3.openshift-kni.io 0 6d21h
kube-root-ca.crt 1 6d21h
openshift-service-ca.crt 1 6d21h
topo-aware-scheduler-config 1 6d18h
올바르게 구성된 클러스터에서 oc get configmap
도 numaresourcesoperator-worker
configmap
CR을 반환합니다.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc
)를 설치합니다. - cluster-admin 권한이 있는 사용자로 로그인합니다.
- NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
프로세스
다음 명령을 사용하여
MachineConfigPool
(mcp
) 작업자 CR의spec.machineConfigPoolSelector.matchLabels
값과kubeletconfig
및metadata.labels
의 값을 비교합니다.다음 명령을 실행하여
kubeletconfig
레이블을 확인합니다.oc get kubeletconfig -o yaml
$ oc get kubeletconfig -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
machineConfigPoolSelector: matchLabels: cnf-worker-tuning: enabled
machineConfigPoolSelector: matchLabels: cnf-worker-tuning: enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
mcp
레이블을 확인합니다.oc get mcp worker -o yaml
$ oc get mcp worker -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
labels: machineconfiguration.openshift.io/mco-built-in: "" pools.operator.machineconfiguration.openshift.io/worker: ""
labels: machineconfiguration.openshift.io/mco-built-in: "" pools.operator.machineconfiguration.openshift.io/worker: ""
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cnf-worker-tuning: enabled
라벨은MachineConfigPool
개체에 없습니다.
예를 들어,
MachineConfigPool
CR을 편집하여 누락된 레이블을 포함합니다.oc edit mcp worker -o yaml
$ oc edit mcp worker -o yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
labels: machineconfiguration.openshift.io/mco-built-in: "" pools.operator.machineconfiguration.openshift.io/worker: "" cnf-worker-tuning: enabled
labels: machineconfiguration.openshift.io/mco-built-in: "" pools.operator.machineconfiguration.openshift.io/worker: "" cnf-worker-tuning: enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.
검증
누락된
numarsourcesoperator-worker
configmap
CR이 적용되었는지 확인하세요.oc get configmap
$ oc get configmap
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.8.6. NUMA 리소스 운영자 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather
CLI 명령을 사용하면 NUMA 리소스 연산자와 관련된 기능 및 객체를 포함하여 클러스터에 대한 정보를 수집할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)가 설치되어 있습니다.
프로세스
must-gather 를
사용하여 NUMA 리소스 연산자 데이터를 수집하려면 NUMA 리소스 연산자must-gather
이미지를 지정해야 합니다.oc adm must-gather --image=registry.redhat.io/openshift4/numaresources-must-gather-rhel9:v4.19
$ oc adm must-gather --image=registry.redhat.io/openshift4/numaresources-must-gather-rhel9:v4.19
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13장. 확장성 및 성능 최적화 링크 복사링크가 클립보드에 복사되었습니다!
13.1. 스토리지 최적화 링크 복사링크가 클립보드에 복사되었습니다!
스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.
13.1.1. 사용 가능한 영구 스토리지 옵션 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 환경을 최적화할 수 있도록 영구 스토리지 옵션에 대해 알아보십시오.
스토리지 유형 | 설명 | 예 |
---|---|---|
블록 |
| AWS EBS와 VMware vSphere는 OpenShift Container Platform에서 기본적으로 동적 영구 볼륨(PV) 프로비저닝을 지원합니다. |
파일 |
| RHEL NFS, NetApp NFS [1] 및 Vendor NFS |
개체 |
| AWS S3 |
- NetApp NFS는 Trident 플러그인을 사용할 때 동적 PV 프로비저닝을 지원합니다.
13.1.2. 권장되는 구성 가능한 스토리지 기술 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 지정된 OpenShift Container Platform 클러스터 애플리케이션에 권장되는 구성 가능한 스토리지 기술이 요약되어 있습니다.
스토리지 유형 | 블록 | 파일 | 개체 |
---|---|---|---|
1
2 3 Prometheus는 메트릭에 사용되는 기본 기술입니다. 4 물리적 디스크, VM 물리적 디스크, VMDK, NFS를 통한 루프백, AWS EBS 및 Azure Disk에는 적용되지 않습니다.
5 메트릭의 경우 RWX( 6 로깅을 위해 로그 저장소에 대한 영구 저장소 구성 섹션에서 권장되는 저장소 솔루션을 검토하세요. Gluster와 같은 NAS를 통해 또는 영구 볼륨으로 NFS 스토리지를 사용하면 데이터가 손상될 수 있습니다. 따라서 OpenShift Container Platform Logging의 Elasticsearch 저장소와 LokiStack 로그 저장소에서는 NFS가 지원되지 않습니다. 로그 저장소당 하나의 영구 볼륨 유형을 사용해야 합니다. 7 OpenShift Container Platform의 PV 또는 PVC를 통해서는 오브젝트 스토리지가 사용되지 않습니다. 앱은 오브젝트 스토리지 REST API와 통합해야 합니다. | |||
ROX1 | 제공됨4 | 제공됨4 | 제공됨 |
RWX2 | 없음 | 제공됨 | 제공됨 |
레지스트리 | 구성 가능 | 구성 가능 | 권장 |
확장 레지스트리 | 구성 불가능 | 구성 가능 | 권장 |
Metrics3 | 권장 | 구성 가능5 | 구성 불가능 |
Elasticsearch 로깅 | 권장 | 구성 가능6 | 6 지원되지 않음 |
로키 로깅 | 구성 불가능 | 구성 불가능 | 권장 |
앱 | 권장 | 권장 | 구성 불가능7 |
확장된 레지스트리는 두 개 이상의 포드 복제본이 실행되는 OpenShift 이미지 레지스트리입니다.
13.1.2.1. 특정 애플리케이션 스토리지 권장 사항 링크 복사링크가 클립보드에 복사되었습니다!
테스트 결과, Red Hat Enterprise Linux(RHEL)에서 NFS 서버를 핵심 서비스의 스토리지 백엔드로 사용하는 데 문제가 있는 것으로 나타났습니다. 여기에는 OpenShift Container Registry and Quay, 스토리지 모니터링을 위한 Prometheus, 로깅 스토리지를 위한 Elasticsearch가 포함됩니다. 따라서 RHEL NFS를 사용하여 핵심 서비스에서 사용하는 PV를 백업하는 것은 권장되지 않습니다.
시중에 나와 있는 다른 NFS 구현에는 이런 문제가 없을 수도 있습니다. 이러한 OpenShift Container Platform 핵심 구성 요소에 대해 완료된 테스트에 대한 자세한 내용은 개별 NFS 구현 공급업체에 문의하십시오.
13.1.2.1.1. 레지스트리 링크 복사링크가 클립보드에 복사되었습니다!
비확장/고가용성(HA) OpenShift 이미지 레지스트리 클러스터 배포에서:
- 스토리지 기술에서 RWX 액세스 모드를 지원할 필요가 없습니다.
- 스토리지 기술에서 쓰기 후 읽기 일관성을 보장해야 합니다.
- 기본 스토리지 기술은 오브젝트 스토리지, 블록 스토리지 순입니다.
- 프로덕션 워크로드가 포함된 OpenShift 이미지 레지스트리 클러스터 배포에는 파일 저장소를 권장하지 않습니다.
13.1.2.1.2. 확장 레지스트리 링크 복사링크가 클립보드에 복사되었습니다!
확장/HA OpenShift 이미지 레지스트리 클러스터 배포에서:
- 스토리지 기술은 RWX 액세스 모드를 지원해야 합니다.
- 스토리지 기술에서 쓰기 후 읽기 일관성을 보장해야 합니다.
- 기본 스토리지 기술은 오브젝트 스토리지입니다.
- Red Hat OpenShift Data Foundation(ODF), Amazon Simple Storage Service(Amazon S3), Google Cloud Storage(GCS), Microsoft Azure Blob Storage, OpenStack Swift가 지원됩니다.
- 오브젝트 스토리지는 S3 또는 Swift와 호환되어야 합니다.
- vSphere, 베어 메탈 설치 등 클라우드 이외의 플랫폼에서는 구성 가능한 유일한 기술이 파일 스토리지입니다.
- 블록 스토리지는 구성 불가능합니다.
- OpenShift Container Platform에서 NFS(Network File System) 스토리지 사용이 지원됩니다. 그러나 확장된 레지스트리와 함께 NFS 스토리지를 사용하면 알려진 문제가 발생할 수 있습니다. 자세한 내용은 프로덕션의 OpenShift 클러스터 내부 구성 요소에 대해 NFS가 지원되는 Red Hat 지식베이스 솔루션을 참조하십시오.
13.1.2.1.3. 지표 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 호스트 지표 클러스터 배포에서는 다음 사항에 유의합니다.
- 기본 스토리지 기술은 블록 스토리지입니다.
- 오브젝트 스토리지는 구성 불가능합니다.
프로덕션 워크로드가 있는 호스트 지표 클러스터 배포에는 파일 스토리지를 사용하지 않는 것이 좋습니다.
13.1.2.1.4. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 호스트 로깅 클러스터 배포에서는 다음 사항에 유의합니다.
로키 오퍼레이터:
- 선호되는 저장 기술은 S3 호환 객체 스토리지입니다.
- 블록 스토리지는 구성 불가능합니다.
OpenShift Elasticsearch Operator:
- 기본 스토리지 기술은 블록 스토리지입니다.
- 개체 스토리지는 지원되지 않습니다.
로깅 버전 5.4.3부터 OpenShift Elasticsearch Operator는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 수명 주기 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만, 이 기능은 더 이상 향상되지 않고 제거될 예정입니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 저장소를 관리하는 대신 Loki Operator를 사용할 수 있습니다.
13.1.2.1.5. 애플리케이션 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 사용 사례는 다음 예에 설명된 대로 애플리케이션마다 다릅니다.
- 동적 PV 프로비저닝을 지원하는 스토리지 기술은 마운트 대기 시간이 짧고 정상 클러스터를 지원하는 노드와 관련이 없습니다.
- 애플리케이션 개발자는 애플리케이션의 스토리지 요구사항을 잘 알고 있으며 제공된 스토리지로 애플리케이션을 작동시켜 애플리케이션이 스토리지 계층을 스케일링하거나 스토리지 계층과 상호 작용할 때 문제가 발생하지 않도록 하는 방법을 이해하고 있어야 합니다.
13.1.2.2. 다른 특정 애플리케이션 스토리지 권장 사항 링크 복사링크가 클립보드에 복사되었습니다!
etcd
와 같이 쓰기
작업이 많은 작업에는 RAID 구성을 사용하지 않는 것이 좋습니다. RAID 구성으로 etcd를
실행하는 경우 워크로드에서 성능 문제가 발생할 위험이 있습니다.
- Red Hat OpenStack Platform(RHOSP) Cinder: RHOSP Cinder는 ROX 액세스 모드 사용 사례에 적합한 경향이 있습니다.
- 데이터베이스: 데이터베이스(RDBMS, NoSQL DB 등)는 전용 블록 스토리지를 사용하는 경우 성능이 최대화되는 경향이 있습니다.
- etcd 데이터베이스는 대규모 클러스터를 활성화하기 위해 충분한 저장 공간과 적절한 성능 용량을 갖춰야 합니다. 충분한 저장 공간과 고성능 환경을 구축하기 위한 모니터링 및 벤치마킹 도구에 대한 정보는 권장되는 etcd 사례 에 설명되어 있습니다.
13.1.3. 데이터 스토리지 관리 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 OpenShift Container Platform 구성 요소가 데이터를 쓰는 기본 디렉터리가 요약되어 있습니다.
디렉터리 | 참고 | 크기 조정 | 예상 증가 |
---|---|---|---|
/var/log | 모든 구성 요소의 로그 파일입니다. | 10~30GB입니다. | 로그 파일이 빠르게 증가할 수 있습니다. 크기는 디스크를 늘리거나 로그 회전을 사용하여 관리할 수 있습니다. |
/var/lib/etcd | 데이터베이스를 저장할 때 etcd 스토리지에 사용됩니다. | 20GB 미만입니다. 데이터베이스는 최대 8GB까지 증가할 수 있습니다. | 환경과 함께 천천히 증가합니다. 메타데이터만 저장합니다. 추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다. |
/var/lib/containers | CRI-O 런타임의 마운트 옵션입니다. Pod를 포함한 활성 컨테이너 런타임에 사용되는 스토리지 및 로컬 이미지 스토리지입니다. 레지스트리 스토리지에는 사용되지 않습니다. | 16GB 메모리가 있는 노드의 경우 50GB가 증가합니다. 이 크기 조정은 최소 클러스터 요구사항을 결정하는 데 사용하면 안 됩니다. 추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다. | 컨테이너 실행 용량에 의해 증가가 제한됩니다. |
/var/lib/kubelet | Pod용 임시 볼륨 스토리지입니다. 런타임 시 컨테이너로 마운트된 외부 요소가 모두 포함됩니다. 영구 볼륨에서 지원하지 않는 환경 변수, kube 보안 및 데이터 볼륨이 포함됩니다. | 변동 가능 | 스토리지가 필요한 Pod가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다. |
13.1.4. Microsoft Azure를 위한 스토리지 성능 최적화 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 및 Kubernetes는 디스크 성능에 민감하며 특히 컨트롤 플레인 노드의 etcd에 더 빠른 스토리지를 사용하는 것이 좋습니다.
프로덕션 Azure 클러스터와 작업 부하가 큰 클러스터의 경우, 제어 평면 머신용 가상 머신 운영 체제 디스크는 테스트 및 권장되는 최소 처리량인 5000 IOPS/200MBps를 유지할 수 있어야 합니다. 이 처리량은 최소 1 TiB Premium SSD (P30)를 보유하여 제공할 수 있습니다. Azure 및 Azure Stack Hub에서 디스크 성능은 SSD 디스크 크기에 직접적으로 영향을 받습니다. Standard_D8s_v3
가상 머신이나 이와 유사한 머신 유형이 지원하는 처리량과 5000 IOPS 목표를 달성하려면 최소한 P30 디스크가 필요합니다.
데이터를 읽을 때 낮은 지연 시간과 높은 IOPS 및 처리량을 얻으려면 호스트 캐싱을 ReadOnly
로 설정해야 합니다. VM 메모리나 로컬 SSD 디스크에 있는 캐시에서 데이터를 읽는 것은 Blob 스토리지에 있는 디스크에서 데이터를 읽는 것보다 훨씬 빠릅니다.
13.2. 라우팅 최적화 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform HAProxy 라우터는 성능을 최적화하도록 확장하거나 구성할 수 있습니다.
13.2.1. 기본 Ingress 컨트롤러(라우터) 성능 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform Ingress Controller 또는 라우터는 경로와 Ingress를 사용하여 구성된 애플리케이션과 서비스에 대한 Ingress 트래픽의 Ingress 지점입니다.
초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.
- HTTP 연결 유지/닫기 모드
- 경로 유형
- TLS 세션 재개 클라이언트 지원
- 대상 경로당 동시 연결 수
- 대상 경로 수
- 백엔드 서버 페이지 크기
- 기본 인프라(네트워크, CPU 등)
특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.
HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.
Encryption | LoadBalancerService | HostNetwork |
---|---|---|
none | 21515 | 29622 |
edge | 16743 | 22913 |
passthrough | 36786 | 53295 |
re-encrypt | 21583 | 25198 |
HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.
Encryption | LoadBalancerService | HostNetwork |
---|---|---|
none | 5719 | 8273 |
edge | 2729 | 4069 |
passthrough | 4121 | 5344 |
re-encrypt | 2320 | 2941 |
기본 Ingress Controller 구성은 spec.tuningOptions.threadCount
필드를 4
로 설정하여 사용되었습니다. 두 가지 다른 엔드포인트 게시 전략(로드 밸런서 서비스 및 호스트 네트워크)이 테스트되었습니다. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP keep-alive를 사용하면 단일 HAProxy 라우터가 8kB만큼 작은 페이지 크기에서 1Gbit NIC를 포화시킬 수 있습니다.
최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.
애플리케이션 수 | 애플리케이션 유형 |
---|---|
5-10 | 정적 파일/웹 서버 또는 캐싱 프록시 |
100-1000 | 동적 콘텐츠를 생성하는 애플리케이션 |
일반적으로 HAProxy는 사용되는 기술에 따라 최대 1000개의 애플리케이션에 대한 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.
Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.
Ingress 샤딩에 대한 자세한 내용은 경로 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성 및 네임스페이스 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하세요.
Ingress Controller 사양의 스레드에 대한 Ingress Controller 스레드 수 설정 및 시간 초과에 대한 Ingress Controller 구성 매개변수 , 기타 튜닝 구성에 제공된 정보를 사용하여 Ingress Controller 배포를 수정할 수 있습니다.
13.2.2. Ingress Controller 활성, 준비 및 시작 프로브 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OpenShift Container Platform Ingress Controller(라우터)에서 관리하는 라우터 배포에 대한 kubelet의 활성 상태, 준비 상태 및 시작 프로브에 대한 시간 초과 값을 구성할 수 있습니다. 라우터의 활성 및 준비 프로브는 기본 시간 초과 값인 1초를 사용하는데, 이는 네트워킹이나 런타임 성능이 심각하게 저하될 때 너무 짧습니다. 프로브 시간 초과로 인해 원치 않는 라우터 재시작이 발생하여 애플리케이션 연결이 중단될 수 있습니다. 더 큰 시간 초과 값을 설정할 수 있는 기능은 불필요하고 원치 않는 재시작 위험을 줄일 수 있습니다.
라우터 컨테이너의 livenessProbe
, readinessProbe
및 startupProbe
매개변수에서 timeoutSeconds
값을 업데이트할 수 있습니다.
매개변수 | 설명 |
---|---|
|
|
|
|
|
|
타임아웃 구성 옵션은 문제를 해결하는 데 사용할 수 있는 고급 튜닝 기술입니다. 그러나 이러한 문제는 결국 진단되어야 하며, 프로브 시간 초과를 유발하는 문제에 대해서는 지원 사례나 Jira 문제가 개설될 수 있습니다.
다음 예제에서는 기본 라우터 배포에 직접 패치를 적용하여 활성 및 준비 프로브에 대한 5초 시간 초과를 설정하는 방법을 보여줍니다.
oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'
$ oc -n openshift-ingress patch deploy/router-default --type=strategic --patch='{"spec":{"template":{"spec":{"containers":[{"name":"router","livenessProbe":{"timeoutSeconds":5},"readinessProbe":{"timeoutSeconds":5}}]}}}}'
검증
oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
$ oc -n openshift-ingress describe deploy/router-default | grep -e Liveness: -e Readiness:
Liveness: http-get http://:1936/healthz delay=0s timeout=5s period=10s #success=1 #failure=3
Readiness: http-get http://:1936/healthz/ready delay=0s timeout=5s period=10s #success=1 #failure=3
13.2.3. HAProxy 재로드 간격 구성 링크 복사링크가 클립보드에 복사되었습니다!
경로 또는 경로와 연관된 엔드포인트를 업데이트하면 OpenShift Container Platform 라우터가 HAProxy에 대한 구성을 업데이트합니다. 그런 다음 HAProxy는 업데이트된 구성을 다시 로드하여 변경 사항을 적용합니다. HAProxy가 다시 로드되면 업데이트된 구성을 사용하여 새 연결을 처리하는 새 프로세스가 생성됩니다.
HAProxy는 모든 연결이 닫힐 때까지 기존 연결을 처리하기 위해 이전 프로세스를 계속 실행합니다. 오래된 프로세스에 오랫동안 연결이 유지되는 경우 해당 프로세스가 누적되어 리소스를 소모할 수 있습니다.
기본 최소 HAProxy 재로드 간격은 5초입니다. spec.tuningOptions.reloadInterval
필드를 사용하여 Ingress Controller를 구성하면 최소 재로드 간격을 더 길게 설정할 수 있습니다.
최소 HAProxy 재로드 간격에 큰 값을 설정하면 경로와 해당 엔드포인트에 대한 업데이트를 관찰하는 데 지연이 발생할 수 있습니다. 위험을 줄이려면 업데이트에 허용되는 지연 시간보다 큰 값을 설정하지 마세요.
프로세스
다음 명령을 실행하여 기본 Ingress 컨트롤러의 최소 HAProxy 재로드 간격을 15초로 변경합니다.
oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'
$ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.3. 네트워킹 최적화 링크 복사링크가 클립보드에 복사되었습니다!
OVN-Kubernetes는 Geneve와 유사한 프로토콜인 Generic Network Virtualization Encapsulation(Geneve)을 사용하여 노드 간 트래픽을 터널링합니다. 이 네트워크는 네트워크 인터페이스 컨트롤러(NIC) 오프로드를 사용하여 조정할 수 있습니다.
제네바는 VLAN에 비해 네트워크 수를 4,096개에서 1,600만 개 이상으로 늘리고 물리적 네트워크 전반에 걸쳐 2계층 연결을 제공하는 등의 이점을 제공합니다. 이를 통해 서비스 뒤에 있는 모든 Pod가 서로 다른 시스템에서 실행되는 경우에도 서로 통신할 수 있습니다.
OpenShift Container Platform을 실행하는 클라우드, 가상 및 베어메탈 환경은 최소한의 튜닝으로 NIC 기능의 높은 비율을 활용할 수 있습니다. Geneve 터널링을 갖춘 OVN-Kubernetes를 사용하는 프로덕션 클러스터는 높은 처리량 트래픽을 효과적으로 처리하고 특별한 구성 없이도 확장(예: 100Gbps NIC 활용) 및 확장(예: NIC 추가)이 가능합니다.
최대 효율성이 중요한 일부 고성능 시나리오에서는 타겟형 성능 튜닝을 통해 CPU 사용량을 최적화하고, 오버헤드를 줄이고, NIC 기능을 최대한 활용할 수 있습니다.
최대 처리량과 CPU 효율성이 중요한 환경에서는 다음 전략을 사용하여 성능을 더욱 최적화할 수 있습니다.
-
iPerf3
및k8s-netperf
와 같은 도구를 사용하여 네트워크 성능을 검증합니다. 이러한 도구를 사용하면 Pod 및 노드 인터페이스에서 처리량, 지연 시간, 초당 패킷 수(PPS)를 벤치마킹할 수 있습니다. - BGP(Border Gateway Protocol)와 같은 OVN-Kubernetes 사용자 정의 네트워킹(UDN) 라우팅 기술을 평가합니다.
- Geneve-offload가 가능한 네트워크 어댑터를 사용하세요. Geneve-offload는 패킷 체크섬 계산과 관련 CPU 오버헤드를 시스템 CPU에서 벗어나 네트워크 어댑터의 전용 하드웨어로 옮깁니다. 이를 통해 포드와 애플리케이션에서 CPU 사이클을 사용할 수 있게 되고, 사용자는 네트워크 인프라의 전체 대역폭을 사용할 수 있습니다.
13.3.1. 네트워크에 대한 MTU 최적화 링크 복사링크가 클립보드에 복사되었습니다!
두 가지 중요한 최대 전송 단위(MTU)가 있습니다. 네트워크 인터페이스 컨트롤러(NIC) MTU와 클러스터 네트워크 MTU입니다.
NIC MTU는 OpenShift Container Platform 설치 시 구성되며, 설치 후 작업으로 클러스터의 MTU를 변경할 수도 있습니다. 자세한 내용은 "클러스터 네트워크 MTU 변경"을 참조하세요.
OVN-Kubernetes 플러그인을 사용하는 클러스터의 경우 MTU는 네트워크 NIC에서 지원하는 최대값보다 100
바이트 작아야 합니다. 처리량을 최적화하는 경우 8900
과 같이 가능한 가장 큰 값을 선택하세요. 최소 지연을 최적화하려면 더 낮은 값을 선택합니다.
클러스터가 OVN-Kubernetes 플러그인을 사용하고 네트워크가 NIC를 사용하여 네트워크를 통해 조각화되지 않은 점보 프레임 패킷을 송수신하는 경우, 포드가 실패하지 않도록 NIC의 MTU 값으로 9000
바이트를 지정해야 합니다.
13.3.2. 대규모 클러스터 설치에 대한 권장 사례 링크 복사링크가 클립보드에 복사되었습니다!
대규모 클러스터를 설치하거나 클러스터를 더 큰 노드 수로 확장하는 경우, 클러스터를 설치하기 전에 install-config.yaml
파일에서 클러스터 네트워크 CIDR을
적절히 설정하세요.
노드 수가 많은 클러스터에 대한 네트워크 구성이 포함된 install-config.yaml
파일 예시
클러스터 크기가 500개 노드를 초과하는 경우 기본 클러스터 네트워크 cidr
10.128.0.0/14
를 사용할 수 없습니다. 500개 이상의 노드를 추가하려면 cidr을
10.128.0.0/12
또는 10.128.0.0/10
으로 설정해야 합니다.
13.3.3. IPsec 영향 링크 복사링크가 클립보드에 복사되었습니다!
노드 호스트의 암호화 및 암호 해독은 CPU를 사용하기 때문에 사용 중인 IP 보안 시스템에 관계없이 암호화를 사용할 때 노드의 처리량과 CPU 사용량 모두에서 성능에 영향을 미칩니다.
IPsec은 NIC에 도달하기 전에 IP 페이로드 수준에서 트래픽을 암호화하여 NIC 오프로드에 사용되는 필드를 보호합니다. 즉, IPSec이 활성화된 경우 일부 NIC 가속 기능을 사용할 수 없고 처리량이 감소하고 CPU 사용량이 증가할 수 있습니다.
13.4. 마운트 네임스페이스 캡슐화를 통한 CPU 사용량 최적화 링크 복사링크가 클립보드에 복사되었습니다!
마운트 네임스페이스 캡슐화를 사용하여 kubelet 및 CRI-O 프로세스에 대한 개인 네임스페이스를 제공하면 OpenShift Container Platform 클러스터에서 CPU 사용량을 최적화할 수 있습니다. 이렇게 하면 기능상의 차이 없이 systemd에서 사용하는 클러스터 CPU 리소스가 줄어듭니다.
마운트 네임스페이스 캡슐화는 Technology Preview 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
13.4.1. 마운트 네임스페이스 캡슐화 링크 복사링크가 클립보드에 복사되었습니다!
마운트 네임스페이스는 서로 다른 네임스페이스의 프로세스가 서로의 파일을 볼 수 없도록 마운트 지점을 격리하는 데 사용됩니다. 캡슐화는 Kubernetes 마운트 네임스페이스를 호스트 운영 체제에서 지속적으로 검사하지 않는 대체 위치로 옮기는 프로세스입니다.
호스트 운영 체제는 systemd를 사용하여 모든 마운트 네임스페이스를 지속적으로 스캔합니다. 여기에는 표준 Linux 마운트와 Kubernetes가 운영하는 데 사용하는 수많은 마운트가 모두 포함됩니다. kubelet과 CRI-O의 현재 구현은 모두 모든 컨테이너 런타임과 kubelet 마운트 지점에 대해 최상위 네임스페이스를 사용합니다. 그러나 이러한 컨테이너별 마운트 지점을 개인 네임스페이스에 캡슐화하면 기능상의 차이 없이 systemd 오버헤드가 줄어듭니다. CRI-O와 kubelet 모두에 별도의 마운트 네임스페이스를 사용하면 systemd나 다른 호스트 운영 체제와의 상호 작용에서 컨테이너별 마운트를 캡슐화할 수 있습니다.
주요 CPU 최적화를 잠재적으로 달성할 수 있는 이 기능은 이제 모든 OpenShift Container Platform 관리자가 사용할 수 있습니다. 캡슐화는 권한이 없는 사용자가 검사할 수 없는 안전한 위치에 Kubernetes 관련 마운트 지점을 저장하여 보안을 강화할 수도 있습니다.
다음 다이어그램은 캡슐화 전과 후의 Kubernetes 설치를 보여줍니다. 두 시나리오 모두 마운트 전파 설정이 양방향, 호스트-컨테이너, 없음인 예시 컨테이너를 보여줍니다.
여기서는 systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임이 단일 마운트 네임스페이스를 공유하는 것을 볼 수 있습니다.
- systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임은 각각 모든 마운트 지점에 대한 액세스 권한과 가시성을 갖습니다.
-
양방향 마운트 전파로 구성된 컨테이너 1은 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다.
/run/a
와 같이 컨테이너 1에서 시작된 마운트는 systemd, 호스트 운영 체제 프로세스, kubelet, 컨테이너 런타임 및 호스트-컨테이너 또는 양방향 마운트 전파가 구성된 다른 컨테이너(컨테이너 2의 경우)에서 볼 수 있습니다. -
호스트-컨테이너 마운트 전파로 구성된 컨테이너 2는 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다.
/run/b
와 같이 컨테이너 2에서 시작된 마운트는 다른 컨텍스트에서는 볼 수 없습니다. -
마운트 전파가 구성되지 않은 컨테이너 3에는 외부 마운트 지점이 표시되지 않습니다.
/run/c
와 같이 컨테이너 3에서 시작된 마운트는 다른 컨텍스트에서는 볼 수 없습니다.
다음 다이어그램은 캡슐화 후의 시스템 상태를 보여줍니다.
- 주요 systemd 프로세스는 더 이상 Kubernetes 관련 마운트 지점의 불필요한 스캔에 전념하지 않습니다. systemd 관련 및 호스트 마운트 지점만 모니터링합니다.
- 호스트 운영 체제 프로세스는 systemd 및 호스트 마운트 지점에만 액세스할 수 있습니다.
- CRI-O와 kubelet에 별도의 마운트 네임스페이스를 사용하면 모든 컨테이너별 마운트가 systemd나 다른 호스트 운영 체제와의 상호 작용에서 완전히 분리됩니다.
-
컨테이너 1의 동작은 변경되지 않았지만,
/run/a
와 같이 컨테이너가 생성하는 마운트는 더 이상 systemd나 호스트 운영 체제 프로세스에 표시되지 않습니다. 호스트-컨테이너 또는 양방향 마운트 전파가 구성된 kubelet, CRI-O 및 기타 컨테이너(컨테이너 2와 같음)에서는 여전히 볼 수 있습니다. - 컨테이너 2와 컨테이너 3의 동작은 변경되지 않습니다.
13.4.2. 마운트 네임스페이스 캡슐화 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터가 리소스 오버헤드를 덜 발생하도록 마운트 네임스페이스 캡슐화를 구성할 수 있습니다.
마운트 네임스페이스 캡슐화는 기술 미리보기 기능이며 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 수동으로 활성화해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
클러스터 관리자
권한이 있는 사용자로 로그인했습니다.
프로세스
다음 YAML을 사용하여
mount_namespace_config.yaml
이라는 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 마운트 네임스페이스
MachineConfig
CR을 적용합니다.oc apply -f mount_namespace_config.yaml
$ oc apply -f mount_namespace_config.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
machineconfig.machineconfiguration.openshift.io/99-kubens-master created machineconfig.machineconfiguration.openshift.io/99-kubens-worker created
machineconfig.machineconfiguration.openshift.io/99-kubens-master created machineconfig.machineconfiguration.openshift.io/99-kubens-worker created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfig
CR이 클러스터에 적용되는 데 최대 30분이 걸릴 수 있습니다. 다음 명령을 실행하여MachineConfig
CR의 상태를 확인할 수 있습니다.oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-03d4bc4befb0f4ed3566a2c8f7636751 False True False 3 0 0 0 45m worker rendered-worker-10577f6ab0117ed1825f8af2ac687ddf False True False 3 1 1
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-03d4bc4befb0f4ed3566a2c8f7636751 False True False 3 0 0 0 45m worker rendered-worker-10577f6ab0117ed1825f8af2ac687ddf False True False 3 1 1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행한 후
MachineConfig
CR이 모든 제어 평면과 작업자 노드에 성공적으로 적용될 때까지 기다리세요.oc wait --for=condition=Updated mcp --all --timeout=30m
$ oc wait --for=condition=Updated mcp --all --timeout=30m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
machineconfigpool.machineconfiguration.openshift.io/master condition met machineconfigpool.machineconfiguration.openshift.io/worker condition met
machineconfigpool.machineconfiguration.openshift.io/master condition met machineconfigpool.machineconfiguration.openshift.io/worker condition met
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
클러스터 호스트의 캡슐화를 확인하려면 다음 명령을 실행하세요.
클러스터 호스트에 디버그 셸을 엽니다.
oc debug node/<node_name>
$ oc debug node/<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow chroot
세션을 엽니다.chroot /host
sh-4.4# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow systemd 마운트 네임스페이스를 확인하세요.
readlink /proc/1/ns/mnt
sh-4.4# readlink /proc/1/ns/mnt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
mnt:[4026531953]
mnt:[4026531953]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow kubelet 마운트 네임스페이스를 확인하세요:
readlink /proc/$(pgrep kubelet)/ns/mnt
sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
mnt:[4026531840]
mnt:[4026531840]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CRI-O 마운트 네임스페이스를 확인하세요.
readlink /proc/$(pgrep crio)/ns/mnt
sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
mnt:[4026531840]
mnt:[4026531840]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이 명령은 systemd, kubelet 및 컨테이너 런타임과 관련된 마운트 네임스페이스를 반환합니다. OpenShift Container Platform에서 컨테이너 런타임은 CRI-O입니다.
위의 예처럼 systemd가 kubelet 및 CRI-O와 다른 마운트 네임스페이스에 있는 경우 캡슐화가 적용됩니다. 3개의 프로세스가 모두 동일한 마운트 네임스페이스에 있는 경우 캡슐화는 적용되지 않습니다.
13.4.3. 캡슐화된 네임스페이스 검사 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Enterprise Linux CoreOS(RHCOS)에서 제공되는 kubensenter
스크립트를 사용하면 디버깅이나 감사 목적으로 클러스터 호스트 운영 체제에서 Kubernetes 관련 마운트 지점을 검사할 수 있습니다.
클러스터 호스트에 대한 SSH 셸 세션은 기본 네임스페이스에 있습니다. SSH 셸 프롬프트에서 Kubernetes 관련 마운트 지점을 검사하려면 kubensenter
스크립트를 루트로 실행해야 합니다. kubensenter
스크립트는 마운트 캡슐화 상태를 인식하고 캡슐화가 활성화되지 않은 경우에도 안전하게 실행할 수 있습니다.
oc 디버그
원격 셸 세션은 기본적으로 Kubernetes 네임스페이스 내부에서 시작됩니다. oc debug를
사용하면 마운트 지점을 검사하기 위해 kubensenter를
실행할 필요가 없습니다.
캡슐화 기능이 활성화되어 있지 않으면 kubensenter findmnt
및 findmnt
명령은 oc 디버그
세션에서 실행하든 SSH 셸 프롬프트에서 실행하든 관계없이 동일한 출력을 반환합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 로그인했습니다. - 클러스터 호스트에 대한 SSH 액세스를 구성했습니다.
프로세스
클러스터 호스트에 대한 원격 SSH 쉘을 엽니다. 예를 들면 다음과 같습니다.
ssh core@<node_name>
$ ssh core@<node_name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 제공된
kubensenter
스크립트를 root 사용자로 사용하여 명령을 실행합니다. Kubernetes 네임스페이스 내에서 단일 명령을 실행하려면 명령과kubensenter
스크립트에 인수를 제공합니다. 예를 들어 Kubernetes 네임스페이스 내에서findmnt
명령을 실행하려면 다음 명령을 실행합니다.sudo kubensenter findmnt
[core@control-plane-1 ~]$ sudo kubensenter findmnt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubernetes 네임스페이스 내에서 새 대화형 쉘을 시작하려면 인수 없이
kubensenter
스크립트를 실행합니다.sudo kubensenter
[core@control-plane-1 ~]$ sudo kubensenter
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.4.4. 캡슐화된 네임스페이스에서 추가 서비스 실행 링크 복사링크가 클립보드에 복사되었습니다!
호스트 운영 체제에서 실행하는 기능을 사용하고 kubelet, CRI-O 또는 컨테이너 자체에서 생성한 마운트 지점을 확인할 수 있는 모니터링 툴은 이러한 마운트 지점을 확인하기 위해 컨테이너 마운트 네임스페이스를 입력해야 합니다. OpenShift Container Platform과 함께 제공되는 kubensenter
스크립트는 Kubernetes 마운트 지점 내에서 다른 명령을 실행하고 기존 툴을 조정하는 데 사용할 수 있습니다.
kubensenter
스크립트는 마운트 캡슐화 기능 상태를 알고 있으며 캡슐화가 활성화되지 않은 경우에도 실행하는 것이 안전합니다. 이 경우 스크립트는 기본 마운트 네임스페이스에서 제공된 명령을 실행합니다.
예를 들어 systemd 서비스를 새 Kubernetes 마운트 네임스페이스 내에서 실행해야 하는 경우 서비스 파일을 편집하고 kubensenter
와 함께 ExecStart=
명령줄을 사용합니다.
[Unit] Description=Example service [Service] ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2
[Unit]
Description=Example service
[Service]
ExecStart=/usr/bin/kubensenter /path/to/original/command arg1 arg2
14장. 베어 메탈 호스트 관리 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 클러스터에 OpenShift Container Platform을 설치할 때 클러스터에 있는 베어 메탈 호스트에 대한 machine
및 machineset
CR(사용자 정의 리소스)을 사용하여 베어 메탈 노드를 프로비저닝하고 관리할 수 있습니다.
14.1. 베어 메탈 호스트 및 노드 정보 링크 복사링크가 클립보드에 복사되었습니다!
RHCOS(Red Hat Enterprise Linux CoreOS) 베어 메탈 호스트를 클러스터에서 노드로 프로비저닝하려면 먼저 베어 메탈 호스트 하드웨어에 해당하는 MachineSet
CR(사용자 정의 리소스) 오브젝트를 생성합니다. 베어 메탈 호스트 머신 세트는 구성과 관련된 인프라 구성 요소를 설명합니다. 이러한 머신에 특정 Kubernetes 레이블을 적용한 다음 해당 머신 세트에서만 실행되도록 인프라 구성 요소를 업데이트합니다.
machine
CR은 metal3.io/autoscale-to-hosts
주석이 포함된 관련 MachineSet
을 확장하면 자동으로 생성됩니다. OpenShift Container Platform은 Machine
CR을 사용하여 MachineSet
CR에 지정된 대로 호스트에 해당하는 베어 메탈 노드를 프로비저닝합니다.
14.2. 베어 메탈 호스트 유지관리 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔에서 클러스터의 베어 메탈 호스트의 세부 정보를 유지 관리할 수 있습니다. 컴퓨팅 → 베어 메탈 호스트로 이동하여 작업 드롭다운 메뉴에서 작업을 선택합니다. 여기에서 BMC 세부 정보, 호스트의 MAC 주소 부팅, 전원 관리 활성화 등의 항목을 관리할 수 있습니다. 네트워크 인터페이스의 세부 정보와 호스트에 대한 드라이브도 검토할 수 있습니다.
베어 메탈 호스트를 유지 관리 모드로 이동할 수 있습니다. 호스트를 유지 관리 모드로 이동할 때 스케줄러는 모든 관리 워크로드를 해당 베어 메탈 노드에서 이동합니다. 유지 관리 모드에서는 새 워크로드가 예약되지 않습니다.
웹 콘솔에서 베어 메탈 호스트를 프로비저닝 해제할 수 있습니다. 호스트 프로비저닝 해제는 다음 작업을 수행합니다.
-
cluster.k8s.io/delete-machine: true
를 사용하여 베어 메탈 호스트 CR에 주석을 답니다. - 관련 컴퓨팅 머신 세트를 축소
먼저 데몬 세트와 관리되지 않는 정적 Pod를 다른 노드로 이동하지 않고 호스트의 전원을 끄면 서비스가 중단되고 데이터가 손실될 수 있습니다.
14.2.1. 웹 콘솔을 사용하여 클러스터에 베어 메탈 호스트 추가 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.
사전 요구 사항
- 베어 메탈에 RHCOS 클러스터 설치
-
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
- 웹 콘솔에서 Compute → Bare Metal Hosts로 이동합니다.
- Add Host → New with Dialog를 선택합니다.
- 새 베어 메탈 호스트의 고유 이름을 지정합니다.
- Boot MAC address를 설정합니다.
- Baseboard Management Console (BMC) Address를 설정합니다.
- 호스트의 BMC(Baseboard Management Controller)에 대한 사용자 인증 정보를 입력합니다.
- 생성 후 호스트 전원을 켜도록선택하고 Create를 선택합니다.
- 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. Compute → MachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count을 선택하여 클러스터에서 머신 복제본 수를 늘립니다.
oc scale
명령 및 적절한 베어 메탈 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.
14.2.2. 웹 콘솔에서 YAML을 사용하여 클러스터에 베어 메탈 호스트 추가 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 호스트를 설명하는 YAML 파일을 사용하여 웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.
사전 요구 사항
- 클러스터에 사용할 RHCOS 컴퓨팅 머신을 베어메탈 인프라에 설치합니다.
-
cluster-admin
권한이 있는 사용자로 로그인합니다. -
베어 메탈 호스트의
Secret
CR을 생성합니다.
프로세스
- 웹 콘솔에서 Compute → Bare Metal Hosts로 이동합니다.
- Add Host → New from YAML을 선택합니다.
아래 YAML을 복사하고 붙여넣고 호스트의 세부 정보로 관련 필드를 수정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Create를 선택하여 YAML을 저장하고 새 베어 메탈 호스트를 생성합니다.
사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. Compute → MachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count를 선택하여 클러스터의 머신 수를 늘립니다.
참고oc scale
명령 및 적절한 베어 메탈 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.
14.2.3. 사용 가능한 베어 메탈 호스트 수로 머신 자동 스케일링 링크 복사링크가 클립보드에 복사되었습니다!
사용 가능한 BareMetalHost
오브젝트 수와 일치하는 Machine
오브젝트 수를 자동으로 생성하려면 MachineSet
오브젝트에 metal3.io/autoscale-to-hosts
주석을 추가합니다.
사전 요구 사항
-
클러스터에서 사용할 RHCOS 베어 메탈 컴퓨팅 머신을 설치하고 해당
BareMetalHost
오브젝트를 생성합니다. -
OpenShift Container Platform CLI (
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
metal3.io/autoscale-to-hosts
주석을 추가하여 자동 스케일링을 구성할 머신 세트에 주석을 답니다.<machineset>
를 컴퓨팅 머신 세트의 이름으로 바꿉니다.oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'
$ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새로 확장된 머신이 시작될 때까지 기다립니다.
BareMetalHost
오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가 BareMetalHost
에서 변경되면 Machine
오브젝트가 생성된 MachineSet
에 대해 BareMetalHost
오브젝트가 계속 계산됩니다.
14.2.4. 프로비저너 노드에서 베어 메탈 호스트 제거 링크 복사링크가 클립보드에 복사되었습니다!
특정 상황에서는 프로비저너 노드에서 베어 메탈 호스트를 일시적으로 제거해야 할 수 있습니다. 예를 들어 OpenShift Container Platform 관리 콘솔을 사용하거나 Machine Config Pool 업데이트로 베어 메탈 호스트 재부팅이 트리거되는 경우 OpenShift Container Platform은 통합된 iDrac(Remote Access Controller)에 로그인하여 작업 대기열 삭제를 발행합니다.
사용 가능한 BareMetalHost
오브젝트 수와 일치하는 Machine
오브젝트 수를 관리하지 않으려면 MachineSet
오브젝트에 baremetalhost.metal3.io/detached
주석을 추가합니다.
이 주석은 Provisioned
,ExternallyProvisioned
또는 Ready/Available
상태에 있는 BareMetalHost
오브젝트에만 적용됩니다.
사전 요구 사항
-
클러스터에서 사용할 RHCOS 베어 메탈 컴퓨팅 머신을 설치하고 해당
BareMetalHost
오브젝트를 생성합니다. -
OpenShift Container Platform CLI (
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
baremetalhost.metal3.io/detached
주석을 추가하여 프로비저너 노드에서 제거할 컴퓨팅 머신 세트에 주석을 답니다.oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'
$ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 새 머신이 시작될 때까지 기다립니다.
참고BareMetalHost
오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가BareMetalHost
에서 변경되면Machine
오브젝트가 생성된MachineSet
에 대해BareMetalHost
오브젝트가 계속 계산됩니다.프로비저닝 사용 사례에서 다음 명령을 사용하여 재부팅이 완료된 후 주석을 제거합니다.
oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'
$ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
14.2.5. 베어 메탈 호스트 전원 끄기 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔에서 베어 메탈 클러스터 호스트의 전원을 끄거나 OpenShift CLI(oc
)를 사용하여 클러스터에 패치를 적용하여 수행할 수 있습니다. 호스트의 전원을 끄기 전에 노드를 예약 불가로 표시하고 노드에서 모든 Pod 및 워크로드를 드레이닝해야 합니다.
사전 요구 사항
- 클러스터에서 사용할 RHCOS 컴퓨팅 머신을 베어메탈 인프라에 설치했습니다.
-
cluster-admin
권한이 있는 사용자로 로그인했습니다. -
호스트를 관리하도록 구성하고 클러스터 호스트에 대한 BMC 자격 증명을 추가했습니다. 클러스터에
Secret
CR(사용자 정의 리소스)을 적용하거나 웹 콘솔에 로그인하고 베어 메탈 호스트를 관리하도록 구성하여 BMC 자격 증명을 추가할 수 있습니다.
프로세스
웹 콘솔에서 전원을 끄려는 노드를 예약 불가로 표시합니다. 다음 단계를 수행합니다.
- 노드로 이동하여 전원을 끄려는 노드를 선택합니다. 작업 메뉴를 확장하고 예약 불가로 마크 를 선택합니다.
- Pod 배포를 조정하거나 노드의 워크로드를 0으로 축소하여 노드에서 실행 중인 Pod를 수동으로 삭제하거나 재배치합니다. 드레이닝 프로세스가 완료될 때까지 기다립니다.
- 컴퓨팅 → 베어 메탈 호스트로 이동합니다.
- 전원을 끄려는 베어 메탈 호스트의 옵션 메뉴 를 확장하고 Power Off 를 선택합니다. Immediate power off 를 선택합니다.
또는
oc
를 사용하여 전원을 끄려는 호스트의BareMetalHost
리소스를 패치할 수 있습니다.관리되는 베어 메탈 호스트의 이름을 가져옵니다. 다음 명령을 실행합니다.
oc get baremetalhosts -n openshift-machine-api -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.provisioning.state}{"\n"}{end}'
$ oc get baremetalhosts -n openshift-machine-api -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.provisioning.state}{"\n"}{end}'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드를 예약 불가능으로 표시합니다.
oc adm cordon <bare_metal_host>
$ oc adm cordon <bare_metal_host>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<bare_metal_host
>는 종료하려는 호스트입니다(예:worker-2.example.com
).
노드의 모든 Pod를 드레이닝합니다.
oc adm drain <bare_metal_host> --force=true
$ oc adm drain <bare_metal_host> --force=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 복제 컨트롤러에서 지원하는 Pod는 클러스터의 다른 사용 가능한 노드로 다시 예약됩니다.
베어 메탈 호스트의 전원을 안전하게 끕니다. 다음 명령을 실행합니다.
oc patch <bare_metal_host> --type json -p '[{"op": "replace", "path": "/spec/online", "value": false}]'
$ oc patch <bare_metal_host> --type json -p '[{"op": "replace", "path": "/spec/online", "value": false}]'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트의 전원을 켜면 워크로드에 대해 노드를 예약할 수 있습니다. 다음 명령을 실행합니다.
oc adm uncordon <bare_metal_host>
$ oc adm uncordon <bare_metal_host>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15장. 대규모 페이지의 기능과 애플리케이션에서 대규모 페이지를 사용하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
15.1. 대규모 페이지의 기능 링크 복사링크가 클립보드에 복사되었습니다!
메모리는 페이지라는 블록으로 관리됩니다. 대부분의 시스템에서 한 페이지는 4Ki입니다. 1Mi 메모리는 256페이지와 같고 1Gi 메모리는 256,000페이지에 해당합니다. CPU에는 하드웨어에서 이러한 페이지 목록을 관리하는 내장 메모리 관리 장치가 있습니다. TLB(Translation Lookaside Buffer)는 가상-물리적 페이지 매핑에 대한 소규모 하드웨어 캐시입니다. TLB에 하드웨어 명령어로 전달된 가상 주소가 있으면 매핑을 신속하게 확인할 수 있습니다. 가상 주소가 없으면 TLB 누락이 발생하고 시스템에서 소프트웨어 기반 주소 변환 속도가 느려져 성능 문제가 발생합니다. TLB 크기는 고정되어 있으므로 TLB 누락 가능성을 줄이는 유일한 방법은 페이지 크기를 늘리는 것입니다.
대규모 페이지는 4Ki보다 큰 메모리 페이지입니다. x86_64 아키텍처에서 일반적인 대규모 페이지 크기는 2Mi와 1Gi입니다. 다른 아키텍처에서는 크기가 달라집니다. 대규모 페이지를 사용하려면 애플리케이션이 인식할 수 있도록 코드를 작성해야 합니다. THP(투명한 대규모 페이지)에서는 애플리케이션 지식 없이 대규모 페이지 관리를 자동화하려고 하지만 한계가 있습니다. 특히 페이지 크기 2Mi로 제한됩니다. THP에서는 THP 조각 모음 작업으로 인해 메모리 사용률이 높아지거나 조각화가 발생하여 노드에서 성능이 저하될 수 있으며 이로 인해 메모리 페이지가 잠길 수 있습니다. 이러한 이유로 일부 애플리케이션은 THP 대신 사전 할당된 대규모 페이지를 사용하도록 설계(또는 권장)할 수 있습니다.
OpenShift Container Platform에서는 Pod의 애플리케이션이 사전 할당된 대규모 페이지를 할당하고 사용할 수 있습니다.
15.2. 앱에서 대규모 페이지를 사용하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
노드에서 대규모 페이지 용량을 보고하려면 노드가 대규모 페이지를 사전 할당해야 합니다. 노드는 단일 크기의 대규모 페이지만 사전 할당할 수 있습니다.
대규모 페이지는 hugepages-<size>
리소스 이름으로 컨테이너 수준 리소스 요구사항에 따라 사용할 수 있습니다. 여기서 크기는 특정 노드에서 지원되는 정수 값이 사용된 가장 간단한 바이너리 표현입니다. 예를 들어 노드에서 2,048KiB 페이지 크기를 지원하는 경우 예약 가능한 리소스 hugepages-2Mi
를 공개합니다. CPU 또는 메모리와 달리 대규모 페이지는 초과 커밋을 지원하지 않습니다.
- 1
hugepages
의 메모리 양은 할당할 정확한 양으로 지정하십시오. 이 값을hugepages
의 메모리 양과 페이지 크기를 곱한 값으로 지정하지 마십시오. 예를 들어 대규모 페이지 크기가 2MB이고 애플리케이션에 100MB의 대규모 페이지 지원 RAM을 사용하려면 50개의 대규모 페이지를 할당합니다. OpenShift Container Platform에서 해당 계산을 처리합니다. 위의 예에서와 같이100MB
를 직접 지정할 수 있습니다.
특정 크기의 대규모 페이지 할당
일부 플랫폼에서는 여러 대규모 페이지 크기를 지원합니다. 특정 크기의 대규모 페이지를 할당하려면 대규모 페이지 부팅 명령 매개변수 앞에 대규모 페이지 크기 선택 매개변수 hugepagesz=<size>
를 지정합니다. <size>
값은 바이트 단위로 지정해야 하며 스케일링 접미사 [kKmMgG
]를 선택적으로 사용할 수 있습니다. 기본 대규모 페이지 크기는 default_hugepagesz=<size>
부팅 매개변수로 정의할 수 있습니다.
대규모 페이지 요구사항
- 대규모 페이지 요청은 제한과 같아야 합니다. 제한은 지정되었으나 요청은 지정되지 않은 경우 제한이 기본값입니다.
- 대규모 페이지는 Pod 범위에서 격리됩니다. 컨테이너 격리는 향후 반복에서 계획됩니다.
-
대규모 페이지에서 지원하는
EmptyDir
볼륨은 Pod 요청보다 더 많은 대규모 페이지 메모리를 사용하면 안 됩니다. -
SHM_HUGETLB
로shmget()
를 통해 대규모 페이지를 사용하는 애플리케이션은 proc/sys/vm/hugetlb_shm_group과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.
15.3. Downward API를 사용하여 Huge Page 리소스 사용 링크 복사링크가 클립보드에 복사되었습니다!
Downward API를 사용하여 컨테이너에서 사용하는 Huge Page 리소스에 대한 정보를 삽입할 수 있습니다.
리소스 할당을 환경 변수, 볼륨 플러그인 또는 둘 모두로 삽입할 수 있습니다. 컨테이너에서 개발하고 실행하는 애플리케이션은 지정된 볼륨에서의 환경 변수 또는 파일을 읽고 사용할 수 있는 리소스를 확인할 수 있습니다.
프로세스
다음 예와 유사한
hugepages-volume-pod.yaml
파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow volume-pod.yaml
파일에서 Pod를 생성합니다.oc create -f hugepages-volume-pod.yaml
$ oc create -f hugepages-volume-pod.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
REQUESTS_HUGEPAGES_1GI
환경 변수 값을 확인합니다.oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \ -- env | grep REQUESTS_HUGEPAGES_1GI
$ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \ -- env | grep REQUESTS_HUGEPAGES_1GI
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
REQUESTS_HUGEPAGES_1GI=2147483648
REQUESTS_HUGEPAGES_1GI=2147483648
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /etc/podinfo/hugepages_1G_request
파일의 값을 확인합니다.oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \ -- cat /etc/podinfo/hugepages_1G_request
$ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \ -- cat /etc/podinfo/hugepages_1G_request
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
2
2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.4. 부팅 시 대규모 페이지 구성 링크 복사링크가 클립보드에 복사되었습니다!
노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. 대규모 페이지 예약은 부팅 시 예약하는 방법과 런타임 시 예약하는 방법 두 가지가 있습니다. 부팅 시 예약은 메모리가 아직 많이 조각화되어 있지 않으므로 성공할 가능성이 높습니다. Node Tuning Operator는 현재 특정 노드에서 대규모 페이지에 대한 부팅 시 할당을 지원합니다.
프로세스
노드 재부팅을 최소화하려면 다음 단계를 순서대로 수행해야 합니다.
동일한 대규모 페이지 설정이 필요한 모든 노드에 하나의 레이블을 지정합니다.
oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
$ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 콘텐츠로 파일을 생성하고 이름을
hugepages-tuned-boottime.yaml
로 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Tuned
hugepages
오브젝트를 생성합니다.oc create -f hugepages-tuned-boottime.yaml
$ oc create -f hugepages-tuned-boottime.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 콘텐츠로 파일을 생성하고 이름을
hugepages-mcp.yaml
로 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 머신 구성 풀을 생성합니다.
oc create -f hugepages-mcp.yaml
$ oc create -f hugepages-mcp.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
조각화되지 않은 메모리가 충분한 경우 worker-hp
머신 구성 풀의 모든 노드에 50개의 2Mi 대규모 페이지가 할당되어 있어야 합니다.
oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
TuneD 부트로더 플러그인은 RHCOS(Red Hat Enterprise Linux CoreOS) 작업자 노드만 지원합니다.
15.5. 투명한 대규모 페이지 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
THP(Transparent Huge Pages)는 대규모 페이지를 생성, 관리 및 사용하는 대부분의 측면을 자동화하려고 합니다. THP는 대규모 페이지를 자동으로 관리하므로 모든 유형의 워크로드에 대해 항상 최적으로 처리되는 것은 아닙니다. THP는 많은 애플리케이션이 자체적으로 대규모 페이지를 처리하므로 성능 회귀를 유발할 수 있습니다. 따라서 THP를 비활성화하는 것이 좋습니다. 다음 단계에서는 Node Tuning Operator(NTO)를 사용하여 THP를 비활성화하는 방법을 설명합니다.
프로세스
다음 콘텐츠를 사용하여 파일을 생성하고 이름을
thp-disable-tuned.yaml
로 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Tuned 오브젝트를 생성합니다.
oc create -f thp-disable-tuned.yaml
$ oc create -f thp-disable-tuned.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 활성 프로필 목록을 확인합니다.
oc get profile -n openshift-cluster-node-tuning-operator
$ oc get profile -n openshift-cluster-node-tuning-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
노드 중 하나에 로그인하고 일반 THP 검사를 수행하여 노드가 프로필을 성공적으로 적용했는지 확인합니다.
cat /sys/kernel/mm/transparent_hugepage/enabled
$ cat /sys/kernel/mm/transparent_hugepage/enabled
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
always madvise [never]
always madvise [never]
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16장. 클러스터 노드에 대한 짧은 대기 시간 튜닝 이해 링크 복사링크가 클립보드에 복사되었습니다!
엣지 컴퓨팅은 대기 시간 및 혼잡 문제를 줄이고 통신 및 5G 네트워크 애플리케이션의 애플리케이션 성능을 개선하는 데 중요한 역할을 합니다. 5G의 네트워크 성능 요구 사항을 충족하기 위해서는 대기 시간이 가장 낮은 네트워크 아키텍처를 유지하는 것이 중요합니다. 4G 기술에 비해 평균 대기 시간은 50ms이고 5G는 1ms 이하의 대기 시간에 도달할 수 있습니다. 이렇게 대기 시간이 감소하면 무선 처리량이 10배 증가합니다.
16.1. 낮은 지연 시간에 관하여 링크 복사링크가 클립보드에 복사되었습니다!
Telco 공간에 배포된 많은 애플리케이션에서는 제로 패킷 손실이 가능한 짧은 대기 시간을 요구하고 있습니다. 제로 패킷 손실 튜닝은 네트워크 성능을 저하시키는 고유한 문제를 완화하는 데 도움이 됩니다. 자세한 내용은 Red Hat OpenStack Platform(RHOSP)에서 패킷 손실 없이 튜닝하기(Tuning for Zero Packet Loss)를 참조하세요.
Edge 컴퓨팅 이니셔티브는 대기 시간을 줄이는 데에도 큰 역할을 합니다. 클라우드의 가장자리에 있고 사용자에게 더 가깝다고 생각해 보세요. 이렇게 되면 멀리 있는 데이터 센터와 사용자 간 거리를 크게 줄여 애플리케이션 응답 시간과 성능 대기 시간이 단축됩니다.
관리자는 많은 엣지 사이트와 로컬 서비스를 중앙 집중식으로 관리하여 가능한 한 가장 낮은 관리 비용으로 모든 배포를 실행할 수 있어야 합니다. 또한, 실시간 짧은 대기 시간과 높은 성능을 실현할 수 있도록 클러스터의 특정 노드를 쉽게 배포하고 구성할 수 있어야 합니다. 대기 시간이 짧은 노드는 CNF(클라우드 네이티브 네트워크 기능) 및 DPDK(데이터 플레인 개발 키트)와 같은 애플리케이션에 유용합니다.
OpenShift Container Platform에서는 현재 실시간 실행과 짧은 대기 시간(약 20마이크로초 미만의 반응 시간)을 지원하기 위해 OpenShift Container Platform 클러스터의 소프트웨어를 튜닝하는 메커니즘을 제공합니다. 이 메커니즘에는 커널 및 OpenShift Container Platform 설정 값 튜닝, 커널 설치, 머신 재구성이 포함되어 있습니다. 하지만 이 방법을 사용하려면 4가지 Operator를 설정해야 하며 수동으로 수행할 경우 복잡하고 실수하기 쉬운 많은 구성을 수행해야 합니다.
OpenShift Container Platform은 Node Tuning Operator를 사용하여 자동 튜닝을 구현하여 OpenShift Container Platform 애플리케이션의 저지연 성능을 달성합니다. 클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 더욱 쉽게 수행할 수 있습니다. 관리자는 커널을 kernel-rt로 업데이트할지 여부를 지정하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하여 워크로드를 실행할 수 있습니다.
OpenShift Container Platform은 또한 다양한 산업 환경의 요구 사항을 충족하도록 PerformanceProfile을
조정할 수 있는 노드 튜닝 운영자에 대한 워크로드 힌트를 지원합니다. highPowerConsumption
(전력 소비 증가를 감수하고 대기 시간이 매우 낮음) 및 realTime
(최적의 대기 시간에 우선순위 부여)에 대한 작업 부하 힌트를 사용할 수 있습니다. 이러한 힌트에 대한 참/거짓
설정을 조합하여 애플리케이션별 작업 프로필과 요구 사항을 처리할 수 있습니다.
워크로드 힌트를 통해 산업 부문 설정에 맞춰 성능을 미세하게 조정할 수 있습니다. "모든 사람에게 맞는 단일 크기" 접근 방식 대신 작업 힌트는 다음과 같은 우선 순위를 지정하는 등 사용 패턴에 맞춰 조정될 수 있습니다.
- 낮은 지연 시간
- 실시간 기능
- 전력의 효율적인 사용
이상적으로 이전에 나열된 모든 항목의 우선 순위가 지정됩니다. 하지만 이러한 품목 중 일부는 다른 품목을 희생해서 얻어집니다. 이제 노드 튜닝 운영자는 작업 부하에 대한 기대치를 알고 작업 부하 요구 사항을 더 잘 충족할 수 있습니다. 이제 클러스터 관리자는 해당 작업 부하가 어떤 사용 사례에 속하는지 지정할 수 있습니다. 노드 튜닝 연산자는 PerformanceProfile을
사용하여 작업 부하에 대한 성능 설정을 미세 조정합니다.
애플리케이션이 작동하는 환경은 애플리케이션의 동작에 영향을 미칩니다. 엄격한 대기 시간 요구 사항이 없는 일반적인 데이터 센터의 경우 일부 고성능 워크로드 포드에 대한 CPU 파티셔닝을 활성화하는 최소한의 기본 튜닝만 필요합니다. 지연 시간이 더 높은 우선순위인 데이터 센터와 작업 부하의 경우에도 전력 소비를 최적화하기 위한 조치가 취해집니다. 가장 복잡한 경우는 제조 장비나 소프트웨어 정의 무선 장치와 같이 지연 시간에 민감한 장비에 가까운 클러스터입니다. 이 마지막 배포 유형은 종종 Far edge라고 합니다. Far edge 배포의 경우, 매우 낮은 지연 시간이 최우선 순위이며, 이는 전력 관리를 희생하여 달성됩니다.
16.2. 저지연 및 실시간 애플리케이션을 위한 하이퍼스레딩에 관하여 링크 복사링크가 클립보드에 복사되었습니다!
하이퍼스레딩은 하나의 물리적 CPU 프로세서 코어가 두 개의 논리적 코어처럼 작동하여 두 개의 독립적인 스레드를 동시에 실행할 수 있게 해주는 인텔 프로세서 기술입니다. 하이퍼스레딩은 병렬 처리가 유용한 특정 작업 부하 유형에 대해 더 나은 시스템 처리량을 제공합니다. 기본 OpenShift Container Platform 구성에서는 하이퍼스레딩이 활성화되어 있어야 합니다.
통신 애플리케이션의 경우 가능한 한 대기 시간을 최소화하도록 애플리케이션 인프라를 설계하는 것이 중요합니다. 하이퍼스레딩은 성능 시간을 늦추고 낮은 지연 시간이 필요한 컴퓨팅 집약적 작업의 처리량에 부정적인 영향을 미칠 수 있습니다. 하이퍼스레딩을 비활성화하면 예측 가능한 성능이 보장되고 이러한 작업 부하에 대한 처리 시간이 단축될 수 있습니다.
하이퍼스레딩 구현 및 구성은 OpenShift Container Platform을 실행하는 하드웨어에 따라 다릅니다. 해당 하드웨어에 맞는 하이퍼스레딩 구현에 대한 자세한 내용은 해당 호스트 하드웨어 튜닝 정보를 참조하세요. 하이퍼스레딩을 비활성화하면 클러스터의 코어당 비용이 증가할 수 있습니다.
17장. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 성능 프로필을 사용하여 노드를 낮은 지연 시간으로 조정합니다. 인프라 및 애플리케이션 컨테이너의 CPU를 제한하고, 대규모 페이지, 하이퍼 스레딩을 구성하고, 대기 시간에 민감한 프로세스를 위해 CPU 파티션을 구성할 수 있습니다.
17.1. 성능 프로파일 작성 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile Creator) 도구를 사용하여 클러스터 성능 프로필을 만들 수 있습니다. PPC는 노드 튜닝 연산자의 기능입니다.
PPC는 클러스터에 대한 정보와 사용자가 제공한 구성을 결합하여 하드웨어, 토폴로지 및 사용 사례에 적합한 성능 프로필을 생성합니다.
성능 프로필은 클러스터가 기본 하드웨어 리소스에 직접 액세스할 수 있는 베어 메탈 환경에만 적용됩니다. 단일 노드 OpenShift와 다중 노드 클러스터 모두에 대해 성능 프로필을 구성할 수 있습니다.
다음은 클러스터에서 성능 프로필을 만들고 적용하기 위한 고급 워크플로입니다.
-
성능 구성의 대상으로 삼을 노드에 대한 머신 구성 풀(MCP)을 만듭니다. 단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나만 있으므로
마스터
MCP를 사용해야 합니다. -
must-gather
명령을 사용하여 클러스터에 대한 정보를 수집합니다. 다음 방법 중 하나를 사용하여 PPC 도구를 사용하여 성과 프로필을 만듭니다.
- Podman을 사용하여 PPC 도구를 실행합니다.
- 래퍼 스크립트를 사용하여 PPC 도구를 실행합니다.
- 사용 사례에 맞게 성능 프로필을 구성하고 클러스터에 성능 프로필을 적용합니다.
17.1.1. 성능 프로파일 작성툴 정보 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile Creator)는 노드 튜닝 연산자와 함께 제공되는 명령줄 도구로, 클러스터의 성능 프로필을 만드는 데 도움이 됩니다.
처음에는 PPC 도구를 사용하여 다음 정보를 포함하여 클러스터의 주요 성능 구성을 표시하기 위해 반드시 수집해야 하는
데이터를 처리할 수 있습니다.
- 할당된 CPU ID를 사용한 NUMA 셀 분할
- 하이퍼스레딩 노드 구성
이 정보를 사용하여 성능 프로필을 구성할 수 있습니다.
PPC 실행
PPC 도구에 성능 구성 인수를 지정하여 하드웨어, 토폴로지 및 사용 사례에 적합한 제안된 성능 프로필을 생성합니다.
다음 방법 중 하나를 사용하여 PPC를 실행할 수 있습니다.
- Podman을 사용하여 PPC를 실행하세요
- 래퍼 스크립트를 사용하여 PPC를 실행합니다.
래퍼 스크립트를 사용하면 보다 세부적인 Podman 작업 중 일부를 실행 가능한 스크립트로 추상화할 수 있습니다. 예를 들어, 래퍼 스크립트는 필요한 컨테이너 이미지를 끌어와 실행하고, 컨테이너에 디렉터리를 마운트하고, Podman을 통해 컨테이너에 직접 매개변수를 제공하는 등의 작업을 처리합니다. 두 방법 모두 같은 결과를 얻습니다.
17.1.2. 성능 조정을 위한 대상 노드에 대한 머신 구성 풀 생성 링크 복사링크가 클립보드에 복사되었습니다!
다중 노드 클러스터의 경우 성능 프로필로 구성하려는 대상 노드를 식별하기 위해 MCP(머신 구성 풀)를 정의할 수 있습니다.
단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나만 있으므로 마스터
MCP를 사용해야 합니다. 단일 노드 OpenShift 클러스터의 경우 별도의 MCP를 만들 필요가 없습니다.
사전 요구 사항
-
클러스터 관리자
역할 액세스 권한이 있습니다. -
OpenShift CLI(
oc
)를 설치합니다.
프로세스
다음 명령을 실행하여 구성할 대상 노드에 레이블을 지정합니다.
oc label node <node_name> node-role.kubernetes.io/worker-cnf=""
$ oc label node <node_name> node-role.kubernetes.io/worker-cnf=""
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>을
노드 이름으로 바꾸세요. 이 예제에서는worker-cnf
레이블을 적용합니다.
대상 노드를 포함하는
MachineConfigPool
리소스를 만듭니다.MachineConfigPool
리소스를 정의하는 YAML 파일을 만듭니다.mcp-worker-cnf.yaml
파일 예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
MachineConfigPool
리소스를 적용합니다.oc apply -f mcp-worker-cnf.yaml
$ oc apply -f mcp-worker-cnf.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
machineconfigpool.machineconfiguration.openshift.io/worker-cnf created
machineconfigpool.machineconfiguration.openshift.io/worker-cnf created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 클러스터의 머신 구성 풀을 확인하세요.
oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c7c3c1b4ed5ffef95234d451490 True False False 3 3 3 0 6h46m worker rendered-worker-168f52b168f151e4f853259729b6azc4 True False False 2 2 2 0 6h46m worker-cnf rendered-worker-cnf-168f52b168f151e4f853259729b6azc4 True False False 1 1 1 0 73s
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c7c3c1b4ed5ffef95234d451490 True False False 3 3 3 0 6h46m worker rendered-worker-168f52b168f151e4f853259729b6azc4 True False False 2 2 2 0 6h46m worker-cnf rendered-worker-cnf-168f52b168f151e4f853259729b6azc4 True False False 1 1 1 0 73s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.3. PPC에 대한 클러스터에 대한 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile creator) 툴에는 must-gather
데이터가 필요합니다. 클러스터 관리자로서 must-gather
명령을 실행하여 클러스터에 대한 정보를 캡처합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)를 설치합니다. - 성능 프로필로 구성하려는 대상 MCP를 식별했습니다.
프로세스
-
must-gather
데이터를 저장하려는 디렉터리로 이동합니다. 다음 명령을 실행하여 클러스터 정보를 수집합니다.
oc adm must-gather
$ oc adm must-gather
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은 로컬 디렉토리에
must-gather
데이터가 포함된 폴더를 다음과 유사한 이름 형식으로 생성합니다:must-gather.local.1971646453781853027
.선택 사항:
must-gather
디렉토리에서 압축 파일을 만듭니다.tar cvaf must-gather.tar.gz <must_gather_folder>
$ tar cvaf must-gather.tar.gz <must_gather_folder>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
필수 수집
데이터 폴더의 이름으로 바꿉니다.
참고Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.
17.1.4. Podman을 사용하여 성능 프로필 생성기 실행 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Podman을 Performance Profile Creator(PPC)와 함께 사용하여 성능 프로필을 만들 수 있습니다.
PPC 인수에 대한 자세한 내용은 "성능 프로필 생성자 인수" 섹션을 참조하세요.
PPC는 클러스터에서 수집해야 하는
데이터를 사용하여 성능 프로필을 작성합니다. 성능 구성을 위한 노드의 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 반드시 수집해야 하는
데이터를 다시 만들어야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
podman
과 OpenShift CLI(oc
)를 설치했습니다. - 노드 튜닝 운영자 이미지에 액세스합니다.
- 구성을 위한 대상 노드가 포함된 머신 구성 풀을 식별했습니다.
-
클러스터에
필요한 필수
데이터에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 머신 구성 풀을 확인하세요.
oc get mcp
$ oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c8c3c0b4ed5feef95434d455490 True False False 3 3 3 0 8h worker rendered-worker-668f56a164f151e4a853229729b6adc4 True False False 2 2 2 0 8h worker-cnf rendered-worker-cnf-668f56a164f151e4a853229729b6adc4 True False False 1 1 1 0 79m
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-58433c8c3c0b4ed5feef95434d455490 True False False 3 3 3 0 8h worker rendered-worker-668f56a164f151e4a853229729b6adc4 True False False 2 2 2 0 8h worker-cnf rendered-worker-cnf-668f56a164f151e4a853229729b6adc4 True False False 1 1 1 0 79m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Podman을 사용하여
registry.redhat.io
에 인증합니다.podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Username: <user_name> Password: <password>
Username: <user_name> Password: <password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 다음 명령을 실행하여 PPC 도구에 대한 도움말을 표시합니다.
podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19 -h
$ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19 -h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여
log
인수와 함께 PPC 도구를 실행합니다.podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19 info --must-gather-dir-path /must-gather
$ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19 info --must-gather-dir-path /must-gather
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
--entrypoint performance-profile-creator는
성능 프로필 생성기를podman
에 대한 새로운 진입점으로 정의합니다. -v <path_to_must_gather>는
다음 구성 요소 중 하나에 대한 경로를 지정합니다.-
반드시 수집해야 하는
데이터가 들어 있는 디렉토리입니다. must-gather
압축 해제된 .tar 파일이 들어 있는 기존 디렉토리입니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
-
다음 명령을 실행하여 성능 프로필을 만듭니다. 이 예제에서는 샘플 PPC 인수와 값을 사용합니다.
podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
$ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -v <path_to_must_gather>는
다음 구성 요소 중 하나에 대한 경로를 지정합니다.-
반드시 수집해야 하는
데이터가 들어 있는 디렉토리입니다. -
must-gather
압축 해제된 .tar 파일이 들어 있는 디렉토리입니다.
-
-
--mcp-name=worker-cnf는
worker-cnf
머신 구성 풀을 지정합니다. -
--reserved-cpu-count=1은
예약된 CPU 하나를 지정합니다. -
--rt-kernel=true는
실시간 커널을 활성화합니다. -
--split-reserved-cpus-across-numa=false는
예약된 CPU가 NUMA 노드에 분할되는 것을 비활성화합니다. -
--power-consumption-mode=ultra-low-latency는
전력 소비가 증가하는 대신 최소한의 대기 시간을 지정합니다. --offlined-cpu-count=1은
오프라인 CPU 하나를 지정합니다.참고이 예제의
mcp-name
인수는oc get mcp
명령의 출력에 따라worker-cnf
로 설정됩니다. 단일 노드 OpenShift의 경우--mcp-name=master 를
사용합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 생성된 YAML 파일을 검토하세요.
cat my-performance-profile.yaml
$ cat my-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 생성된 프로필을 적용합니다.
oc apply -f my-performance-profile.yaml
$ oc apply -f my-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
performanceprofile.performance.openshift.io/performance created
performanceprofile.performance.openshift.io/performance created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.5. Performance Profile Creator 래퍼 스크립트 실행 링크 복사링크가 클립보드에 복사되었습니다!
래퍼 스크립트는 PPC(Performance Profile Creator) 도구를 사용하여 성능 프로필을 만드는 과정을 단순화합니다. 스크립트는 필요한 컨테이너 이미지를 끌어오고 실행하고, 컨테이너에 디렉터리를 마운트하고, Podman을 통해 컨테이너에 직접 매개변수를 제공하는 등의 작업을 처리합니다.
성능 프로필 생성자 인수에 대한 자세한 내용은 "성능 프로필 생성자 인수" 섹션을 참조하세요.
PPC는 클러스터에서 수집해야 하는
데이터를 사용하여 성능 프로필을 작성합니다. 성능 구성을 위한 노드의 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 반드시 수집해야 하는
데이터를 다시 만들어야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
podman
과 OpenShift CLI(oc
)를 설치했습니다. - 노드 튜닝 운영자 이미지에 액세스합니다.
- 구성을 위한 대상 노드가 포함된 머신 구성 풀을 식별했습니다.
-
must-gather
tarball에 액세스합니다.
프로세스
예를 들어 다음과 같이
run-perf-profile-creator.sh
라는 이름의 파일을 로컬 시스템에 생성합니다vi run-perf-profile-creator.sh
$ vi run-perf-profile-creator.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 코드를 파일에 붙여넣습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 스크립트에 모든 사용자에 대한 실행 권한을 추가합니다.
chmod a+x run-perf-profile-creator.sh
$ chmod a+x run-perf-profile-creator.sh
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Podman을 사용하여
registry.redhat.io
에 인증합니다.podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Username: <user_name> Password: <password>
Username: <user_name> Password: <password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 다음 명령을 실행하여 PPC 도구에 대한 도움말을 표시합니다.
./run-perf-profile-creator.sh -h
$ ./run-perf-profile-creator.sh -h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고-p
옵션을 사용하여 Node Tuning Operator 이미지의 경로를 설정할 수 있습니다. 경로를 설정하지 않으면 래퍼 스크립트는 기본 이미지인registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.19
를 사용합니다.클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여
log
인수와 함께 PPC 도구를 실행합니다../run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log
$ ./run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -t /<path_to_must_gather_dir>/must-gather.tar.gz는
must-gather tarball이 들어 있는 디렉토리의 경로를 지정합니다. 이것은 래퍼 스크립트의 필수 인수입니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 성능 프로필을 만듭니다.
./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
$ ./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예제에서는 샘플 PPC 인수와 값을 사용합니다.
-
--mcp-name=worker-cnf는
worker-cnf
머신 구성 풀을 지정합니다. -
--reserved-cpu-count=1은
예약된 CPU 하나를 지정합니다. -
--rt-kernel=true는
실시간 커널을 활성화합니다. -
--split-reserved-cpus-across-numa=false는
예약된 CPU가 NUMA 노드에 분할되는 것을 비활성화합니다. -
--power-consumption-mode=ultra-low-latency는
전력 소비가 증가하는 대신 최소한의 대기 시간을 지정합니다. --offlined-cpu-count=1은
오프라인 CPU 하나를 지정합니다.참고이 예제의
mcp-name
인수는oc get mcp
명령의 출력에 따라worker-cnf
로 설정됩니다. 단일 노드 OpenShift의 경우--mcp-name=master 를
사용합니다.
-
다음 명령을 실행하여 생성된 YAML 파일을 검토하세요.
cat my-performance-profile.yaml
$ cat my-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 생성된 프로필을 적용합니다.
oc apply -f my-performance-profile.yaml
$ oc apply -f my-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
performanceprofile.performance.openshift.io/performance created
performanceprofile.performance.openshift.io/performance created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.1.6. Performance Profile Creator 인수 링크 복사링크가 클립보드에 복사되었습니다!
인수 | 설명 |
---|---|
|
MCP의 이름입니다. 예를 들어, 대상 머신에 해당하는 |
| 수집해야 할 디렉토리의 경로입니다.
이 인수는 Podman을 사용하여 PPC 도구를 실행하는 경우에만 필요합니다. 래퍼 스크립트와 함께 PPC를 사용하는 경우 이 인수를 사용하지 마세요. 대신, 래퍼 스크립트에 |
| 예약된 CPU 수입니다. 0보다 큰 자연수를 사용하세요. |
| 실시간 커널을 활성화합니다.
가능한 값: |
인수 | 설명 |
---|---|
| 하이퍼스레딩을 비활성화합니다.
가능한 값:
기본값: 주의
이 인수를 |
하드웨어 튜닝 활성화 | 최대 CPU 주파수 설정을 활성화합니다. 이 기능을 활성화하려면 다음 두 필드 모두에 대해 격리되고 예약된 CPU에서 실행되는 애플리케이션의 최대 주파수를 설정하세요.
이는 고급 기능입니다. 하드웨어 튜닝을 구성하는 경우 생성된 |
|
이는 클러스터 정보를 캡처합니다. 이 인수에는 가능한 값은 다음과 같습니다.
기본값: |
| 오프라인된 CPU의 수. 참고 0보다 큰 자연수를 사용하세요. 충분한 논리적 프로세서가 오프라인 상태가 되지 않으면 오류 메시지가 기록됩니다. 메시지는 다음과 같습니다. Error: failed to compute the reserved and isolated CPUs: please ensure that reserved-cpu-count plus offlined-cpu-count should be in the range [0,1]
Error: failed to compute the reserved and isolated CPUs: please specify the offlined CPU count in the range [0,1]
|
| 전력 소비 모드입니다. 가능한 값은 다음과 같습니다.
기본값: |
|
포드별 전원 관리를 활성화합니다.
가능한 값:
기본값: |
| 생성할 성능 프로파일의 이름입니다.
기본값: |
| NUMA 노드에서 예약된 CPU를 분할합니다.
가능한 값:
기본값: |
| 생성할 성능 프로필의 Kubelet Topology Manager 정책입니다. 가능한 값은 다음과 같습니다.
기본값: |
| DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.
가능한 값:
기본값: |
17.1.7. 성능 프로필 참조 링크 복사링크가 클립보드에 복사되었습니다!
다음 참조 성능 프로필을 기반으로 사용하여 고유한 사용자 지정 프로필을 개발할 수 있습니다.
17.1.7.1. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 성능 프로필 템플릿 입니다. 링크 복사링크가 클립보드에 복사되었습니다!
RHOSP(Red Hat OpenStack Platform)에서 OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch를 사용하는 클러스터의 머신 성능을 최대화하려면 성능 프로필을 사용할 수 있습니다.
다음 성능 프로필 템플릿을 사용하여 배포에 대한 프로필을 생성할 수 있습니다.
OVS-DPDK를 사용하는 클러스터의 성능 프로필 템플릿
CPU_ISOLATED
,CPU_RESERVED
및 HUGEPAGES_COUNT
키에 대한 구성에 적합한 값을 삽입합니다.
17.1.7.2. Telco RAN DU 참조 성능 프로파일 링크 복사링크가 클립보드에 복사되었습니다!
다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 Telco RAN DU 워크로드를 호스팅합니다.
Telco RAN DU 참조 성능 프로파일
17.1.7.3. Telco 코어 참조 성능 프로파일 링크 복사링크가 클립보드에 복사되었습니다!
다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 통신 핵심 워크로드를 호스팅합니다.
Telco 코어 참조 성능 프로파일
17.2. 지원되는 성능 프로필 API 버전 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator는 성능 프로필 apiVersion
필드에 대해 v2
,v1
, v1alpha1
을 지원합니다. v1 및 v1alpha1 API는 동일합니다. v2 API에는 기본값인 false
값을 사용하여 선택적 부울 필드 loballyDisableIrqLoadBalancing
이 포함됩니다.
장치 인터럽트 처리를 사용하기 위해 성능 프로파일을 업그레이드
Performance Addon Operator 성능 프로필 CRD(사용자 정의 리소스 정의)를 v1 또는 v1alpha1에서 v2 로 업그레이드하는 경우 기존 프로필에서 globallyDisableIrqLoadBalancing
이 true
로 설정됩니다.
globallyDisableIrqLoadBalancing
은 Isolated CPU 세트에 대해 IRQ 로드 밸런싱이 비활성화됩니다. 옵션이 true
로 설정되면 Isolated CPU 세트에 대한 IRQ 로드 밸런싱이 비활성화됩니다. 옵션을 false
로 설정하면 모든 CPU에서 IRQ를 분산할 수 있습니다.
Node Tuning Operator API를 v1alpha1에서 v1로 업그레이드
Node Tuning Operator API 버전을 v1alpha1에서 v1로 업그레이드할 때 "None" 변환 전략을 사용하여 v1alpha1 성능 프로파일이 즉시 변환되고 API 버전 v1을 사용하여 Node Tuning Operator에 제공됩니다.
Node Tuning Operator API를 v1alpha1 또는 v1에서 v2로 업그레이드
이전 Performance Addon Operator API 버전에서 업그레이드할 때 기존 v1 및 v1alpha1 성능 프로파일은 true
값으로 globallyDisableIrqLoadBalancing
필드에 삽입하는 변환 Webhook를 사용하여 변환됩니다.
17.3. 워크로드 힌트를 사용하여 노드 전력 소비 및 실시간 처리 구성 링크 복사링크가 클립보드에 복사되었습니다!
프로세스
-
PPC(
Performance Profile
Creator) 툴을 사용하여 환경 하드웨어 및 토폴로지에 적합한 PerformanceProfile을 생성합니다. 다음 표에서는 PPC 툴과 관련된power-consumption-mode
플래그 및 적용된 워크로드 팁에 대해 설정된 가능한 값을 설명합니다.
Performance Profile creator 설정 | 팁 | 환경 | 설명 |
---|---|---|---|
Default |
workloadHints: highPowerConsumption: false realTime: false
| 대기 시간 요구 사항이 없는 처리량 클러스터 | CPU 파티셔닝을 통해서만 성능 달성. |
낮은 대기 시간 |
workloadHints: highPowerConsumption: false realTime: true
| 지역 데이터 센터 | 전력 관리, 대기 시간 및 처리량 간의 손상 등 에너지 절약과 대기 시간이 단축되는 것이 좋습니다. |
Ultra-low-latency |
workloadHints: highPowerConsumption: true realTime: true
| 원거리 엣지 클러스터, 대기 시간 중요한 워크로드 | 전력 소비 증가의 비용으로 절대 최소 대기 시간 및 최대 결정론에 최적화되어 있습니다. |
Pod별 전원 관리 |
workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
| 심각 및 중요하지 않은 워크로드 | Pod당 전원 관리를 허용합니다. |
예
다음 구성은 일반적으로 통신사 RAN DU 배포에 사용됩니다.
- 1
- 시스템 지연에 영향을 줄 수 있는 일부 디버깅 및 모니터링 기능을 비활성화합니다.
성능 프로필에서 실시간
워크로드 힌트 플래그가 true
로 설정된 경우 고정된 CPU가 있는 모든 보장된 Pod에 cpu-quota.crio.io:disable
주석을 추가합니다. 이 주석은 포드 내에서 프로세스 성능 저하를 방지하는 데 필요합니다. 실시간
워크로드 힌트가 명시적으로 설정되지 않으면 기본적으로 true
로 설정됩니다.
전력 소비와 실시간 설정의 조합이 대기 시간에 어떤 영향을 미치는지에 대한 자세한 내용은 워크로드 힌트 이해를 참조하세요.
17.4. 공동 배치된 높은 우선 순위 및 낮은 우선 순위 작업 부하를 실행하는 노드에 대한 전력 절약 구성 링크 복사링크가 클립보드에 복사되었습니다!
우선순위가 낮은 워크로드가 우선순위가 높은 워크로드와 함께 배치된 노드에 대해 전력 절감을 활성화해도 우선순위가 높은 워크로드의 대기 시간이나 처리량에 영향을 주지 않습니다. 작업 부하 자체를 수정하지 않고도 전력을 절약할 수 있습니다.
이 기능은 Intel Ice Lake 및 이후 세대 Intel CPU에서 지원됩니다. 프로세서의 성능은 우선순위가 높은 작업의 대기 시간과 처리량에 영향을 미칠 수 있습니다.
사전 요구 사항
- BIOS에서 C-상태와 운영 체제 제어 P-상태를 활성화했습니다.
프로세스
per-pod-power-management
인수를true
로 설정하여PerformanceProfile을
생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
per-pod-power-management
인수가true
로 설정된 경우power-consumption-mode
인수는default
또는low-latency
여야 합니다.
perPodPowerManagement를
사용한PerformanceProfile
예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow PerformanceProfile
사용자 정의 리소스(CR)에서 기본cpufreq
관리자를 추가 커널 인수로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
schedutil
가버너를 사용하는 것이 좋지만,ondemand
또는powersave
가버너와 같은 다른 가버너를 사용할 수도 있습니다.
TunedPerformancePatch
CR에서 최대 CPU 주파수를 설정하세요.spec: profile: - data: | [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x>
spec: profile: - data: | [sysfs] /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
max_perf_pct
는cpufreq
드라이버가 설정할 수 있는 최대 주파수를 최대 지원 CPU 주파수의 백분율로 제어합니다. 이 값은 모든 CPU에 적용됩니다. 지원되는 최대 주파수는/sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq
에서 확인할 수 있습니다. 시작점으로, 모든 CPU를All Cores Turbo
주파수로 제한하는 백분율을 사용할 수 있습니다.모든 코어 터보
주파수는 모든 코어가 완전히 사용되었을 때 실행되는 주파수입니다.
17.5. 인프라 및 애플리케이션 컨테이너의 CPU 제한 링크 복사링크가 클립보드에 복사되었습니다!
일반적인 하우스키핑 및 워크로드 작업은 대기 시간에 민감한 프로세스에 영향을 줄 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하므로 컨텍스트 전환과 지연 시간 급증이 발생할 수 있습니다. CPU를 분할하면 지연 시간에 민감한 프로세스를 서로 분리하여 노이즈가 많은 프로세스가 지연 시간에 민감한 프로세스를 방해하는 것을 방지할 수 있습니다. 다음 표에서는 노드 튜닝 연산자를 사용하여 노드를 튜닝한 후 CPU에서 프로세스가 실행되는 방식을 설명합니다.
프로세스 유형 | 세부 정보 |
---|---|
| 저지연 작업 부하가 실행되는 경우를 제외한 모든 CPU에서 실행됩니다. |
인프라 포드 | 저지연 작업 부하가 실행되는 경우를 제외한 모든 CPU에서 실행됩니다. |
인터럽트 | 예약된 CPU로 리디렉션(OpenShift Container Platform 4.7 이상에서는 선택 사항) |
커널 프로세스 | 예약된 CPU에 대한 핀 |
지연 시간에 민감한 워크로드 포드 | 격리된 풀에서 특정 독점 CPU 세트에 대한 핀 |
OS 프로세스/systemd 서비스 | 예약된 CPU에 대한 핀 |
모든 QoS 프로세스 유형( Burstable
, BestEffort
또는 Guaranteed
)의 포드에 대한 노드의 코어 할당 가능 용량은 격리된 풀의 용량과 같습니다. 예약된 풀의 용량은 클러스터와 운영 체제 정리 작업에 사용할 수 있도록 노드의 총 코어 용량에서 제거됩니다.
예시 1
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 격리된 풀에 50개의 코어를 할당하고, 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장
포드에 25개의 코어를 할당하고 BestEffort
또는 Burstable
포드에 25개의 코어를 할당합니다. 이는 격리된 풀의 용량과 일치합니다.
예시 2
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 격리된 풀에 50개의 코어를 할당하고, 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장된
Pod에 50개의 코어를 할당하고 BestEffort
또는 Burstable
Pod의 코어 1개를 할당합니다. 이는 격리된 풀의 용량보다 코어 1개를 초과합니다. CPU 용량이 부족하여 Pod 스케줄링이 실패합니다.
사용할 정확한 파티셔닝 패턴은 하드웨어, 작업 부하 특성, 예상 시스템 부하와 같은 여러 요인에 따라 달라집니다. 일부 샘플 사용 사례는 다음과 같습니다.
- 지연 시간에 민감한 워크로드가 네트워크 인터페이스 컨트롤러(NIC)와 같은 특정 하드웨어를 사용하는 경우, 격리된 풀의 CPU가 이 하드웨어에 최대한 가깝게 위치하는지 확인하세요. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 작업 부하를 배치해야 합니다.
- 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 의존하는 경우 모든 수신 패킷 인터럽트를 처리할 수 있을 만큼 충분한 크기의 예비 풀을 할당합니다. 4.19 및 이후 버전에서는 워크로드를 선택적으로 중요함으로 표시할 수 있습니다.
예약된 파티션과 격리된 파티션에 어떤 특정 CPU를 사용해야 할지 결정하려면 세부적인 분석과 측정이 필요합니다. 장치와 메모리의 NUMA 친화성과 같은 요소가 역할을 합니다. 선택은 작업 아키텍처와 특정 사용 사례에 따라서도 달라집니다.
예약된 CPU 풀과 격리된 CPU 풀은 겹치지 않아야 하며, 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
하우스키핑 작업과 작업 부하가 서로 간섭하지 않도록 하려면 성능 프로필의 사양
섹션에서 두 그룹의 CPU를 지정하세요.
-
isolated
- 애플리케이션 컨테이너 워크로드에 대한 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다. -
예약됨
- 클러스터 및 운영 체제 정리 작업에 필요한 CPU를 지정합니다.예약된
그룹의 스레드는 종종 바쁘다.예약된
그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 지연 시간에 민감한 애플리케이션은격리된
그룹에서 실행됩니다.
프로세스
- 해당 환경의 하드웨어와 토폴로지에 적합한 성능 프로필을 만듭니다.
인프라 및 애플리케이션 컨테이너에 대해
reserved
및isolated
하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.6. 클러스터에 대한 하이퍼스레딩 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터에 대해 하이퍼스레딩을 구성하려면 성능 프로필의 CPU 스레드를 예약된 CPU 풀이나 격리된 CPU 풀에 구성된 코어와 동일하게 설정합니다.
성능 프로필을 구성한 후 호스트의 하이퍼스레딩 구성을 변경하는 경우 PerformanceProfile
YAML에서 CPU 격리
및 예약
필드를 새 구성과 일치하도록 업데이트해야 합니다.
이전에 활성화된 호스트 하이퍼스레딩 구성을 비활성화하면 PerformanceProfile
YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift CLI(oc)를 설치합니다.
프로세스
구성할 호스트의 모든 CPU에서 실행중인 스레드를 확인합니다.
클러스터에 로그인하고 다음 명령을 실행하여 호스트 CPU에서 실행중인 스레드를 볼 수 있습니다.
lscpu --all --extended
$ lscpu --all --extended
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.
또는 특정 물리적 CPU 코어(아래 예에서는
cpu0
)에 설정된 스레드를 보려면 셸 프롬프트를 열고 다음을 실행합니다.cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
$ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
0-4
0-4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow PerformanceProfile
YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어, 논리 코어 CPU0 및 CPU4를격리됨으로
설정하고, 논리 코어 CPU1~CPU3 및 CPU5~CPU7을예약됨으로
설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
... cpu: isolated: 0,4 reserved: 1-3,5-7 ...
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약된 CPU 풀과 격리된 CPU 풀은 겹치지 않아야 하며, 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
대부분의 인텔 프로세서에서는 하이퍼스레딩이 기본적으로 활성화되어 있습니다. 하이퍼스레딩을 활성화하면 특정 코어에서 처리하는 모든 스레드는 분리되거나 동일한 코어에서 처리되어야 합니다.
하이퍼스레딩이 활성화된 경우, 모든 보장된 포드는 여러 개의 동시 멀티스레딩(SMT) 수준을 사용해야 포드가 실패할 수 있는 "노이즈 이웃" 상황을 방지할 수 있습니다. 자세한 내용은 정적 정책 옵션을 참조하세요.
17.6.1. 저지연 애플리케이션에 대한 하이퍼스레딩 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
저지연 처리를 위해 클러스터를 구성하는 경우 클러스터를 배포하기 전에 하이퍼스레딩을 비활성화할지 여부를 고려하세요. 하이퍼스레딩을 비활성화하려면 다음 단계를 수행하세요.
- 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
nosmt
를 추가 커널 인수로 설정합니다. 다음 성능 프로파일 예에서는 이 설정에 대해 설명합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.
17.7. 보장된 pod 분리 CPU의 장치 중단 처리 관리 링크 복사링크가 클립보드에 복사되었습니다!
노드 튜닝 오퍼레이터는 클러스터 및 운영 체제 정리 업무를 위해 예약된 CPU, 포드 인프라 컨테이너, 워크로드를 실행하기 위한 애플리케이션 컨테이너를 위한 격리된 CPU 등으로 나누어 호스트 CPU를 관리할 수 있습니다. 이를 통해 대기 시간이 짧은 워크로드의 CPU를 분리된 상태로 설정할 수 있습니다.
장치 중단은 보장된 pod가 실행 중인 CPU를 제외하고 CPU의 과부하를 방지하기 위해 모든 분리된 CPU와 예약된 CPU 간에 균형을 유지합니다. pod에 관련 주석이 설정되어 있으면 보장된 Pod CPU가 장치 인터럽트를 처리하지 못합니다.
새로운 성능 프로파일 필드 globallyDisableIrqLoadBalancing
은 장치 중단을 처리할지 여부를 관리하는 데 사용할 수 있습니다. 특정 작업 부하의 경우, 예약된 CPU만으로는 장치 인터럽트를 처리할 수 없는 경우가 있습니다. 이러한 이유로 격리된 CPU에서는 장치 인터럽트가 전역적으로 비활성화되지 않습니다. 기본적으로 Node Tuning Operator는 격리된 CPU에서 장치 인터럽트를 비활성화하지 않습니다.
17.7.1. 노드에 대한 효과적인 IRQ 친화도 설정 찾기 링크 복사링크가 클립보드에 복사되었습니다!
일부 IRQ 컨트롤러는 IRQ 친화성 설정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 노출합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다.
다음은 Red Hat이 IRQ 친화도 설정을 지원하지 않는다고 알고 있는 드라이버와 하드웨어의 예입니다. 이 목록은 결코 완전하지 않습니다.
-
megaraid_sas
와 같은 일부 RAID 컨트롤러 드라이버 - 많은 비휘발성 메모리 익스프레스(NVMe) 드라이버
- 마더보드의 일부 LAN(LOM) 네트워크 컨트롤러
-
드라이버는
managed_irqs를
사용합니다
IRQ 친화성 설정을 지원하지 않는 이유는 프로세서 유형, IRQ 컨트롤러 또는 마더보드의 회로 연결과 같은 요소와 관련이 있을 수 있습니다.
IRQ의 효과적인 친화도가 격리된 CPU로 설정된 경우, 일부 하드웨어나 드라이버가 IRQ 친화도 설정을 지원하지 않는다는 신호일 수 있습니다. 효과적인 친화도를 찾으려면 호스트에 로그인하고 다음 명령을 실행하세요.
find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;
$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;
출력 예
일부 드라이버는 manages_irqs를
사용합니다. 이 irq의 친화성은 커널에서 내부적으로 관리되며 사용자 공간에서는 친화성을 변경할 수 없습니다. 어떤 경우에는 이러한 IRQ가 분리된 CPU에 할당될 수 있습니다. 관리되는 인터럽트
에 대한 자세한 내용은 격리된 CPU를 대상으로 하더라도 관리되는 인터럽트의 친화성을 변경할 수 없음을 참조하세요.
17.7.2. 노드 인터럽트 친화성 구성 링크 복사링크가 클립보드에 복사되었습니다!
IRQ 동적 부하 분산을 위한 클러스터 노드를 구성하여 어떤 코어가 장치 인터럽트 요청(IRQ)을 수신할 수 있는지 제어합니다.
사전 요구 사항
- 코어 격리를 위해 모든 서버 하드웨어 구성 요소가 IRQ 친화성을 지원해야 합니다. 서버의 하드웨어 구성 요소가 IRQ 친화성을 지원하는지 확인하려면 서버의 하드웨어 사양을 보거나 하드웨어 공급업체에 문의하세요.
프로세스
- cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
-
performance.openshift.io/v2
를 사용하도록 성능 프로파일의apiVersion
을 설정합니다. -
globallyDisableIrqLoadBalancing
필드를 삭제제거하거나false
로 설정합니다. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 CPU를 예약하는 프로파일을 보여줍니다.
isolated
CPU 세트에서 실행되는 Pod에 대해 IRQ 로드 밸런싱이 활성화됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약되고 격리된 CPU를 구성하면 운영 체제 프로세스, 커널 프로세스 및 systemd 서비스가 예약된 CPU에서 실행됩니다. 인프라 포드는 저지연 워크로드가 실행되는 CPU를 제외한 모든 CPU에서 실행됩니다. 저지연 워크로드 포드는 격리된 풀의 전용 CPU에서 실행됩니다. 자세한 내용은 "인프라 및 애플리케이션 컨테이너에 대한 CPU 제한"을 참조하세요.
17.8. 메모리 페이지 크기 구성 링크 복사링크가 클립보드에 복사되었습니다!
메모리 페이지 크기를 구성하면 시스템 관리자는 작업 부하 요구 사항에 맞게 특정 노드에서 보다 효율적인 메모리 관리를 구현할 수 있습니다. 노드 튜닝 연산자는 성능 프로필을 사용하여 대규모 페이지와 커널 페이지 크기를 구성하는 방법을 제공합니다.
17.8.1. 커널 페이지 크기 구성 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필에서 kernelPageSize
사양을 사용하여 특정 노드의 커널 페이지 크기를 구성합니다. 메모리를 많이 사용하는 고성능 작업 부하의 경우 더 큰 커널 페이지 크기를 지정하세요.
x86_64 또는 AMD64 아키텍처를 사용하는 노드의 경우 kernelPageSize
사양에 대해 4k
만 지정할 수 있습니다. AArch64 아키텍처를 사용하는 노드의 경우 kernelPageSize
사양에 4k
또는 64k를
지정할 수 있습니다. 64k
옵션을 사용하려면 실시간 커널을 비활성화해야 합니다. 기본값은 4k
입니다.
사전 요구 사항
-
cluster-admin
역할을 가진 사용자로 클러스터에 액세스합니다. -
OpenShift CLI(
oc
)를 설치합니다.
프로세스
PerformanceProfile
리소스를 정의하는 YAML 파일을 만들어 커널 페이지 크기를 구성하려는 대상 노드에 대한 성능 프로필을 만듭니다.pp-kernel-pages.yaml
파일 예시Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터에 성능 프로필을 적용합니다.
oc create -f pp-kernel-pages.yaml
$ oc create -f pp-kernel-pages.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
performanceprofile.performance.openshift.io/example-performance-profile created
performanceprofile.performance.openshift.io/example-performance-profile created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 성능 프로필을 적용한 노드에서 디버그 세션을 시작합니다.
oc debug node/<node_name>
$ oc debug node/<node_name>
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
<node_name>을
성능 프로필이 적용된 노드의 이름으로 바꿉니다.
다음 명령을 실행하여 커널 페이지 크기가 성능 프로필에 지정한 값으로 설정되었는지 확인하세요.
getconf PAGESIZE
$ getconf PAGESIZE
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
65536
65536
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.8.2. 대규모 페이지 구성 링크 복사링크가 클립보드에 복사되었습니다!
노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. 노드 튜닝 연산자를 사용하여 특정 노드에 대용량 페이지를 할당합니다.
OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. 노드 튜닝 연산자는 성능 프로필을 사용하여 이를 수행하는 더 쉬운 방법을 제공합니다.
예를 들어 성능 프로필의 hugepages
pages
섹션에서 size
, count
및 node
(선택사항)로 된 여러 블록을 지정할 수 있습니다.
- 1
node
는 대규모 페이지가 할당된 NUMA 노드입니다.node
를 생략하면 페이지가 모든 NUMA 노드에 균등하게 분산됩니다.
관련 머신 구성 풀 상태에 업데이트가 완료된 것으로 나타날 때까지 기다립니다.
대규모 페이지를 할당하기 위해 수행해야 하는 구성 단계는 이것이 전부입니다.
검증
구성을 검증하려면 노드의
/proc/meminfo
파일을 참조하십시오.oc debug node/ip-10-0-141-105.ec2.internal
$ oc debug node/ip-10-0-141-105.ec2.internal
Copy to Clipboard Copied! Toggle word wrap Toggle overflow grep -i huge /proc/meminfo
# grep -i huge /proc/meminfo
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe
를 사용하여 새 크기를 보고합니다.oc describe node worker-0.ocp4poc.example.com | grep -i huge
$ oc describe node worker-0.ocp4poc.example.com | grep -i huge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
hugepages-1g=true hugepages-###: ### hugepages-###: ###
hugepages-1g=true hugepages-###: ### hugepages-###: ###
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.8.3. 여러 대규모 페이지 크기 할당 링크 복사링크가 클립보드에 복사되었습니다!
동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.
예를 들어, 1G
와 2M
크기를 정의하면 노드 튜닝 운영자가 다음과 같이 노드에서 두 크기를 모두 구성합니다.
17.9. 노드 튜닝 연산자를 사용하여 NIC 대기열 줄이기 링크 복사링크가 클립보드에 복사되었습니다!
노드 튜닝 오퍼레이터는 NIC 대기열을 줄여 성능을 향상시킵니다. 성능 프로필을 사용하여 조정이 이루어지므로 다양한 네트워크 장치에 맞게 대기열을 사용자 정의할 수 있습니다.
17.9.1. 성능 프로파일을 사용하여 NIC 큐 조정 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로파일을 사용하면 각 네트워크 장치의 대기열 수를 조정할 수 있습니다.
지원되는 네트워크 장치는 다음과 같습니다.
- 비가상 네트워크 장치
- 멀티 큐(채널)를 지원하는 네트워크 장치
지원되지 않는 네트워크 장치는 다음과 같습니다.
- Pure Software 네트워크 인터페이스
- 블록 장치
- Intel DPDK 가상 기능
사전 요구 사항
-
cluster-admin
역할을 가진 사용자로 클러스터에 액세스합니다. -
OpenShift CLI(
oc
)를 설치합니다.
프로세스
-
클러스터 관리자
권한이 있는 사용자로 Node Tuning Operator를 실행하는 OpenShift Container Platform 클러스터에 로그인합니다. - 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.
생성된 성능 프로파일을 편집합니다.
oc edit -f <your_profile_name>.yaml
$ oc edit -f <your_profile_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec
필드를net
오브젝트로 채웁니다. 오브젝트 목록에는 다음 두 개의 필드가 포함될 수 있습니다.-
userLevelNetworking
은 부울 플래그로 지정된 필수 필드입니다.userLevelNetworking
이true
인 경우 지원되는 모든 장치에 대해 대기열 수가 예약된 CPU 수로 설정됩니다. 기본값은false
입니다. devices
는 예약된 CPU 수로 큐를 설정할 장치 목록을 지정하는 선택적 필드입니다. 장치 목록이 비어 있으면 구성이 모든 네트워크 장치에 적용됩니다. 구성은 다음과 같습니다.interfacename
: 이 필드는 인터페이스 이름을 지정하고, 양수 또는 음수일 수 있는 쉘 스타일 와일드카드를 지원합니다.-
와일드카드 구문의 예는 다음과 같습니다.
<string> .*
-
음수 규칙 앞에는 느낌표가 붙습니다. 제외된 목록이 아닌 모든 장치에 넷 큐 변경 사항을 적용하려면
!<device>
를 사용합니다(예:!eno1
).
-
와일드카드 구문의 예는 다음과 같습니다.
-
vendorID
: 접두사가0x
인 16비트 16진수로 표시되는 네트워크 장치 공급업체 ID입니다. deviceID
:0x
접두사가 있는 16비트 16진수로 표시되는 네트워크 장치 ID(모델)입니다.참고deviceID
가 지정되어 있는 경우vendorID
도 정의해야 합니다. 장치 항목interfaceName
,vendorID
,vendorID
및deviceID
의 쌍에 지정된 모든 장치 식별자와 일치하는 장치는 네트워크 장치로 간주됩니다. 그러면 이 네트워크 장치의 네트워크 대기열 수가 예약된 CPU 수로 설정됩니다.두 개 이상의 장치가 지정되면 네트워크 대기열 수가 해당 장치 중 하나와 일치하는 모든 네트워크 장치로 설정됩니다.
-
다음 예제 성능 프로필을 사용하여 대기열 수를 모든 장치에 예약된 CPU 수로 설정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제 성능 프로필을 사용하여 정의된 장치 식별자와 일치하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제 성능 프로필을 사용하여 인터페이스 이름
eth
로 시작하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예제 성능 프로필을 사용하여 이름이
eno1
이외의 인터페이스가 있는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인터페이스 이름
eth0
,0x1af4
의vendorID
및0x1000
의deviceID
는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다. 성능 프로파일 예는 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트된 성능 프로필을 적용합니다.
oc apply -f <your_profile_name>.yaml
$ oc apply -f <your_profile_name>.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
17.9.2. 대기열 상태 확인 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 다양한 성능 프로필과 변경 사항이 적용되었는지 확인하는 방법에 대한 여러 예시가 있습니다.
예시 1
이 예에서 네트워크 대기열 수는 지원되는 모든 장치에 대해 예약된 CPU 수(2)로 설정됩니다.
성능 프로필의 관련 섹션은 다음과 같습니다.
다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.
참고성능 프로필이 적용된 노드에서 이 명령을 실행합니다.
ethtool -l <device>
$ ethtool -l <device>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로필을 적용하기 전에 대기열 상태를 확인합니다.
ethtool -l ens4
$ ethtool -l ens4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로필이 적용된 후 대기열 상태를 확인합니다.
ethtool -l ens4
$ ethtool -l ens4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
- 결합된 채널은 지원되는 모든 장치에 대해 예약된 CPU의 총 수가 2임을 보여줍니다. 이는 성능 프로필에 구성된 항목과 일치합니다.
예시 2
이 예에서 네트워크 대기열 수는 특정 vendorID
가 있는 지원되는 모든 네트워크 장치에 대해 예약된 CPU 수(2)로 설정됩니다.
성능 프로필의 관련 섹션은 다음과 같습니다.
다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.
참고성능 프로필이 적용된 노드에서 이 명령을 실행합니다.
ethtool -l <device>
$ ethtool -l <device>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로필이 적용된 후 대기열 상태를 확인합니다.
ethtool -l ens4
$ ethtool -l ens4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 1
vendorID=0x1af4
를 사용하는 지원되는 모든 장치에 대해 예약된 CPU의 총 수는 2입니다. 예를 들어vendorID=0x1af4
가 있는 다른 네트워크 장치ens2
가 별도로 존재하는 경우 총 네트워크 대기열 수는 2입니다. 이는 성능 프로필에 구성된 항목과 일치합니다.
예시 3
이 예에서 네트워크 대기열 수는 정의된 장치 식별자와 일치하는 지원되는 모든 네트워크 장치에 대해 예약된 CPU 수(2)로 설정됩니다.
udevadm info
는 장치에 대한 자세한 보고서를 제공합니다. 이 예에서 장치는 다음과 같습니다.
interfaceName
이eth0
인 장치 및 다음 성능 프로필이 있는vendorID=0x1af4
가 있는 모든 장치에 대해 네트워크 대기열을 2로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로필이 적용된 후 대기열 상태를 확인합니다.
ethtool -l ens4
$ ethtool -l ens4
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
vendorID=0x1af4
를 사용하는 지원되는 모든 장치에 대해 예약된 CPU의 총 개수가 2로 설정됩니다. 예를 들어vendorID=0x1af4
가 있는 다른 네트워크 장치ens2
가 있는 경우 총 네트워크 대기열도 2로 설정됩니다. 마찬가지로interfaceName
이eth0
인 장치에는 총 네트워크 대기열이 2로 설정됩니다.
17.9.3. NIC 대기열 조정과 관련된 로깅 링크 복사링크가 클립보드에 복사되었습니다!
할당된 장치를 자세히 설명하는 로그 메시지는 각 Tuned 데몬 로그에 기록됩니다. /var/log/tuned/tuned.log
파일에 다음 메시지가 기록될 수 있습니다.
성공적으로 할당된 장치를 자세히 설명하는
INFO
메시지가 기록됩니다.INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 장치를 할당할 수 없는 경우
WARNING
메시지가 기록됩니다.WARNING tuned.plugins.base: instance net_test: no matching devices available
WARNING tuned.plugins.base: instance net_test: no matching devices available
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18장. 성능 프로필을 사용하여 낮은 대기 시간을 위한 호스팅 제어 평면 조정 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필을 적용하여 호스팅된 제어 평면을 낮은 지연 시간으로 조정합니다. 성능 프로필을 사용하면 인프라 및 애플리케이션 컨테이너의 CPU를 제한하고 지연에 민감한 프로세스에 대해 대규모 페이지, 하이퍼스레딩 및 CPU 파티션을 구성할 수 있습니다.
18.1. 호스팅된 제어 평면에 대한 성능 프로필 생성 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile Creator) 도구를 사용하여 클러스터 성능 프로필을 만들 수 있습니다. PPC는 노드 튜닝 연산자의 기능입니다.
PPC는 클러스터에 대한 정보와 사용자가 제공한 구성을 결합하여 하드웨어, 토폴로지, 사용 사례에 적합한 성능 프로필을 생성합니다.
다음은 클러스터에서 성능 프로필을 만들고 적용하기 위한 고급 워크플로입니다.
-
must-gather
명령을 사용하여 클러스터에 대한 정보를 수집합니다. - PPC 도구를 사용하여 성과 프로필을 만듭니다.
- 클러스터에 성능 프로필을 적용합니다.
18.1.1. PPC에 대한 호스팅된 제어 평면 클러스터에 대한 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile creator) 툴에는 must-gather
데이터가 필요합니다. 클러스터 관리자로서 must-gather
명령을 실행하여 클러스터에 대한 정보를 캡처합니다.
사전 요구 사항
-
관리 클러스터에 대한
클러스터 관리자
역할 액세스 권한이 있습니다. -
OpenShift CLI(
oc
)를 설치합니다.
프로세스
다음 명령을 실행하여 관리 클러스터
kubeconfig
파일을 내보냅니다.export MGMT_KUBECONFIG=<path_to_mgmt_kubeconfig>
$ export MGMT_KUBECONFIG=<path_to_mgmt_kubeconfig>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 모든 네임스페이스의 모든 노드 풀을 나열합니다.
oc --kubeconfig="$MGMT_KUBECONFIG" get np -A
$ oc --kubeconfig="$MGMT_KUBECONFIG" get np -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters democluster-us-east-1a democluster 1 1 False False 4.17.0 False True
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters democluster-us-east-1a democluster 1 1 False False 4.17.0 False True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
출력에서는
NodePool
리소스가 정의된 관리 클러스터의 네임스페이스클러스터가
표시됩니다. -
NodePool
리소스의 이름(예:demcluster-us-east-1a)
입니다. -
이
NodePool
이 속한HostedCluster
입니다. 예를 들어,democluster
.
-
출력에서는
관리 클러스터에서 다음 명령을 실행하여 사용 가능한 비밀을 나열합니다.
oc get secrets -n clusters
$ oc get secrets -n clusters
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터의
kubeconfig
파일을 추출합니다.oc get secret <secret_name> -n <cluster_namespace> -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
$ oc get secret <secret_name> -n <cluster_namespace> -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예
oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
$ oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 호스팅된 클러스터에 대한
필수 수집
번들을 생성하려면 별도의 터미널 창을 열고 다음 명령을 실행하세요.호스팅된 클러스터
kubeconfig
파일을 내보냅니다.export HC_KUBECONFIG=<path_to_hosted_cluster_kubeconfig>
$ export HC_KUBECONFIG=<path_to_hosted_cluster_kubeconfig>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예
export HC_KUBECONFIG=~/hostedcpkube/hosted-cluster-kubeconfig
$ export HC_KUBECONFIG=~/hostedcpkube/hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
must-gather
데이터를 저장하려는 디렉터리로 이동합니다. 호스팅된 클러스터에 대한 문제 해결 데이터를 수집하세요.
oc --kubeconfig="$HC_KUBECONFIG" adm must-gather
$ oc --kubeconfig="$HC_KUBECONFIG" adm must-gather
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 디렉토리에서 생성된
must-gather
디렉토리에서 압축 파일을 만듭니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.tar -czvf must-gather.tar.gz must-gather.local.1203869488012141147
$ tar -czvf must-gather.tar.gz must-gather.local.1203869488012141147
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.1.2. Podman을 사용하여 호스팅된 클러스터에서 성능 프로필 생성기 실행 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 Podman을 Performance Profile Creator(PPC) 도구와 함께 사용하여 성능 프로필을 만들 수 있습니다.
PPC 인수에 대한 자세한 내용은 "성과 프로필 생성자 인수"를 참조하세요.
PPC 도구는 호스팅 클러스터를 인식하도록 설계되었습니다. 필수 수집
데이터에서 호스팅된 클러스터를 감지하면 자동으로 다음 작업을 수행합니다.
- MCP(머신 구성 풀)가 없다는 것을 인식합니다.
- MCP 대신 컴퓨팅 노드 구성의 진실의 원천으로 노드 풀을 사용합니다.
-
특정 풀을 타겟으로 삼지 않는 한,
node-pool-name
값을 명시적으로 지정할 필요가 없습니다.
PPC는 호스팅된 클러스터에서 수집해야 하는
데이터를 사용하여 성능 프로필을 작성합니다. 성능 구성을 위한 노드의 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 반드시 수집해야 하는
데이터를 다시 만들어야 합니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 호스팅된 클러스터가 설치되었습니다.
-
Podman과 OpenShift CLI(
oc
) 설치. - 노드 튜닝 운영자 이미지에 액세스합니다.
-
클러스터에
필요한 필수
데이터에 액세스합니다.
프로세스
호스팅된 클러스터에서 다음 명령을 실행하여 Podman을 사용하여
registry.redhat.io
에 인증합니다.podman login registry.redhat.io
$ podman login registry.redhat.io
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Username: <user_name> Password: <password>
Username: <user_name> Password: <password>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에서 성능 프로필을 만듭니다. 이 예제에서는 샘플 PPC 인수와 값을 사용합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 생성된 YAML 파일을 검토하세요.
cat my-hosted-cp-performance-profile
$ cat my-hosted-cp-performance-profile
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
18.1.3. 호스팅된 클러스터에서 저지연 튜닝 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스팅된 클러스터의 노드에서 성능 프로필로 낮은 대기 시간을 설정하려면 노드 튜닝 연산자를 사용할 수 있습니다. 호스팅된 제어 평면에서 튜닝된
객체를 포함하는 구성 맵을 만들고 노드 풀에서 해당 구성 맵을 참조하여 저지연 튜닝을 구성할 수 있습니다. 이 경우 조정된 개체는 노드 풀의 노드에 적용하려는 성능 프로필을 정의하는 PerformanceProfile
개체입니다.
프로세스
다음 명령을 실행하여 관리 클러스터
kubeconfig
파일을 내보냅니다.export MGMT_KUBECONFIG=<path_to_mgmt_kubeconfig>
$ export MGMT_KUBECONFIG=<path_to_mgmt_kubeconfig>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 관리 클러스터에
ConfigMap
객체를 만듭니다.oc --kubeconfig="$MGMT_KUBECONFIG" apply -f my-hosted-cp-performance-profile.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" apply -f my-hosted-cp-performance-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
클러스터
네임스페이스의NodePool
객체를 편집하여spec.tuningConfig
필드와 해당 필드에 생성된 성능 프로필의 이름을 추가합니다.oc edit np -n clusters
$ oc edit np -n clusters
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고여러 노드 풀에서 동일한 프로필을 참조할 수 있습니다. 호스팅된 제어 평면에서 노드 튜닝 연산자는 노드 풀 이름과 네임스페이스의 해시를
튜닝된
사용자 지정 리소스의 이름에 추가하여 이를 구별합니다. 변경 사항을 적용한 후 시스템은 구성 변경이 필요하다는 것을 감지하고 해당 풀의 노드에 대한 롤링 업데이트를 시작하여 새 구성을 적용합니다.
검증
다음 명령을 실행하여 모든 네임스페이스의 모든 노드 풀을 나열합니다.
oc --kubeconfig="$MGMT_KUBECONFIG" get np -A
$ oc --kubeconfig="$MGMT_KUBECONFIG" get np -A
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters democluster-us-east-1a democluster 1 1 False False 4.17.0 False True
NAMESPACE NAME CLUSTER DESIRED NODES CURRENT NODES AUTOSCALING AUTOREPAIR VERSION UPDATINGVERSION UPDATINGCONFIG MESSAGE clusters democluster-us-east-1a democluster 1 1 False False 4.17.0 False True
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고UPDATINGCONFIG
필드는 노드 풀이 구성을 업데이트하는 중인지 여부를 나타냅니다. 이 업데이트 중에 노드 풀 상태의UPDATINGCONFIG
필드가True가
됩니다. 새로운 구성은UPDATINGCONFIG
필드가False
로 반환될 때만 완전히 적용된 것으로 간주됩니다.다음 명령을 실행하여
clusters-democluster
네임스페이스의 모든 구성 맵을 나열합니다.oc --kubeconfig="$MGMT_KUBECONFIG" get cm -n clusters-democluster
$ oc --kubeconfig="$MGMT_KUBECONFIG" get cm -n clusters-democluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력에서는 kubeletconfig
kubeletconfig-performance-democluster-us-east-1a
와 성능 프로필performance-democluster-us-east-1a가
생성되었음을 보여줍니다. 노드 튜닝 운영자는튜닝된
객체를 호스팅된 클러스터에 동기화합니다. 어떤Tuned
객체가 정의되어 있는지, 그리고 각 노드에 어떤 프로필이 적용되어 있는지 확인할 수 있습니다.다음 명령을 실행하여 관리 클러스터에서 사용 가능한 비밀을 나열합니다.
oc get secrets -n clusters
$ oc get secrets -n clusters
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터의
kubeconfig
파일을 추출합니다.oc get secret <secret_name> -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
$ oc get secret <secret_name> -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예
oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
$ oc get secret democluster-admin-kubeconfig -n clusters -o jsonpath='{.data.kubeconfig}' | base64 -d > hosted-cluster-kubeconfig
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터 kubeconfig를 내보냅니다.
export HC_KUBECONFIG=<path_to_hosted-cluster-kubeconfig>
$ export HC_KUBECONFIG=<path_to_hosted-cluster-kubeconfig>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 kubeletconfig가 호스팅된 클러스터에 미러링되었는지 확인하세요.
oc --kubeconfig="$HC_KUBECONFIG" get cm -n openshift-config-managed | grep kubelet
$ oc --kubeconfig="$HC_KUBECONFIG" get cm -n openshift-config-managed | grep kubelet
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
kubelet-serving-ca 1 79m kubeletconfig-performance-democluster-us-east-1a 1 15m
kubelet-serving-ca 1 79m kubeletconfig-performance-democluster-us-east-1a 1 15m
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 호스팅된 클러스터에
단일 numa 노드
정책이 설정되었는지 확인하세요.oc --kubeconfig="$HC_KUBECONFIG" get cm kubeletconfig-performance-democluster-us-east-1a -o yaml -n openshift-config-managed | grep single
$ oc --kubeconfig="$HC_KUBECONFIG" get cm kubeletconfig-performance-democluster-us-east-1a -o yaml -n openshift-config-managed | grep single
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
topologyManagerPolicy: single-numa-node
topologyManagerPolicy: single-numa-node
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19장. 실시간 및 짧은 대기 시간 워크로드 프로비저닝 링크 복사링크가 클립보드에 복사되었습니다!
많은 조직에서는 특히 금융 및 통신 산업 분야에서 고성능 컴퓨팅과 낮고 예측 가능한 지연 시간이 필요합니다.
OpenShift Container Platform은 OpenShift Container Platform 애플리케이션에 대한 낮은 지연 성능과 일관된 응답 시간을 달성하기 위한 자동 튜닝을 구현하는 노드 튜닝 연산자를 제공합니다. 이러한 변경을 하려면 성능 프로필 구성을 사용합니다. 커널을 kernel-rt로 업데이트하고, 포드 인프라 컨테이너를 포함한 클러스터 및 운영 체제 정리 작업을 위해 CPU를 예약하고, 워크로드를 실행하기 위해 애플리케이션 컨테이너의 CPU를 격리하고, 사용되지 않는 CPU를 비활성화하여 전력 소비를 줄일 수 있습니다.
애플리케이션을 작성할 때는 RHEL의 실시간 프로세스 및 스레드 에 설명된 일반적인 권장 사항을 따르세요.
19.1. 실시간 기능을 갖춘 작업자에게 저지연 작업 스케줄링 링크 복사링크가 클립보드에 복사되었습니다!
실시간 기능을 구성하는 성능 프로필이 적용되는 작업자 노드에 대기 시간이 짧은 워크로드를 예약할 수 있습니다.
특정 노드에서 작업 부하를 예약하려면 Pod
사용자 정의 리소스(CR)에서 레이블 선택기를 사용합니다. 레이블 선택기는 노드 튜닝 운영자가 낮은 지연 시간을 위해 구성한 머신 구성 풀에 연결된 노드와 일치해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
클러스터 관리자
권한이 있는 사용자로 로그인했습니다. - 저지연 작업 부하에 맞춰 작업자 노드를 조정하는 성능 프로필을 클러스터에 적용했습니다.
프로세스
저지연 작업 부하에 대한
Pod
CR을 생성하고 클러스터에 적용합니다. 예:실시간 처리를 사용하도록 구성된
Pod
사양 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<profile_name>은
PerformanceProfile
YAML의이름
이며, performance-<profile_name> 형식으로 podruntimeClassName을
입력합니다. 이전 예에서이름
은performance-dynamic-low-latency-profile
입니다. Pod가 올바르게 실행되고 있는지 확인합니다. 상태가
running
이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.oc get pod -o wide
$ oc get pod -o wide
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
NAME READY STATUS RESTARTS AGE IP NODE dynamic-low-latency-pod 1/1 Running 0 5h33m 10.131.0.10 cnf-worker.example.com
NAME READY STATUS RESTARTS AGE IP NODE dynamic-low-latency-pod 1/1 Running 0 5h33m 10.131.0.10 cnf-worker.example.com
Copy to Clipboard Copied! Toggle word wrap Toggle overflow IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.
oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
$ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Cpus_allowed_list: 2-3
Cpus_allowed_list: 2-3
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
노드 구성이 올바르게 적용되었는지 확인합니다.
구성을 확인하려면 노드에 로그인하세요.
oc debug node/<node-name>
$ oc debug node/<node-name>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 파일 시스템을 사용할 수 있는지 확인합니다.
chroot /host
sh-4.4# chroot /host
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
sh-4.4#
sh-4.4#
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 시스템 CPU 친화성 마스크에
동적 저지연 포드
CPU(예: CPU 2 및 3)가 포함되지 않도록 합니다.cat /proc/irq/default_smp_affinity
sh-4.4# cat /proc/irq/default_smp_affinity
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
33
33
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 시스템 IRQ가
dynamic-low-latency-pod
CPU에서 실행되도록 구성되지 않았는지 확인하세요.find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
sh-4.4# find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
낮은 지연 시간을 위해 노드를 조정할 때 보장된 CPU가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 지연 시간이 급증할 수 있습니다. 적절하게 구성된 네트워크 프로브 세트와 같은 다른 프로브를 대안으로 사용하세요.
19.2. QoS 클래스가 보장된 포드 생성 링크 복사링크가 클립보드에 복사되었습니다!
고성능 작업 부하의 경우 QoS(서비스 품질) 클래스가 보장된
Pod를 생성할 수 있습니다. QoS 클래스를 보장하여
Pod를 구성하면 Pod가 지정된 CPU 및 메모리 리소스에 우선적으로 액세스할 수 있습니다.
QoS 클래스가 보장된
포드를 생성하려면 다음 사양을 적용해야 합니다.
- 포드의 각 컨테이너에 대해 메모리 제한 및 메모리 요청 필드에 동일한 값을 설정합니다.
- 포드의 각 컨테이너에 대해 CPU 제한 및 CPU 요청 필드에 동일한 값을 설정합니다.
일반적으로 QoS 클래스가 보장된
포드는 노드에서 추방되지 않습니다. 한 가지 예외는 시스템 데몬이 예약된 리소스를 초과하여 리소스 경합이 발생하는 경우입니다. 이 시나리오에서 kubelet은
노드 안정성을 유지하기 위해 가장 낮은 우선순위의 Pod부터 Pod를 제거할 수 있습니다.
사전 요구 사항
-
cluster-admin
역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
OpenShift CLI(
oc
)
프로세스
다음 명령을 실행하여 Pod의 네임스페이스를 생성합니다.
oc create namespace qos-example
$ oc create namespace qos-example
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 예에서는
qos-example
네임스페이스를 사용합니다.
출력 예
namespace/qos-example created
namespace/qos-example created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod
리소스를 생성합니다.Pod
리소스를 정의하는 YAML 파일을 생성합니다.qos-example.yaml
파일 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 예에서는 공개
hello-openshift
이미지를 사용합니다. - 2
- 메모리 제한을 200MB로 설정합니다.
- 3
- CPU 제한을 1 CPU로 설정합니다.
- 4
- 메모리 요청을 200MB로 설정합니다.
- 5
- CPU 요청을 1 CPU로 설정합니다.참고
컨테이너에 메모리 제한을 지정하고 메모리 요청을 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로 컨테이너의 CPU 제한을 지정하고 CPU 요청을 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.
다음 명령을 실행하여 리소스를 생성합니다.
oc apply -f qos-example.yaml --namespace=qos-example
$ oc apply -f qos-example.yaml --namespace=qos-example
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
pod/qos-demo created
pod/qos-demo created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 Pod의
qosClass
값을 확인합니다.oc get pod qos-demo --namespace=qos-example --output=yaml | grep qosClass
$ oc get pod qos-demo --namespace=qos-example --output=yaml | grep qosClass
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
qosClass: Guaranteed
qosClass: Guaranteed
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3. Pod에서 CPU 로드 밸런싱 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
CPU 부하 분산을 비활성화하거나 활성화하는 기능은 CRI-O 수준에서 구현됩니다. CRI-O 아래의 코드는 다음 요구사항이 충족되는 경우에만 CPU 부하 분산을 비활성화하거나 활성화합니다.
Pod는
performance-<profile-name>
런타임 클래스를 사용해야 합니다. 다음과 같이 성능 프로필의 상태를 보고 적절한 이름을 가져올 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Performance Addon Operator는 관련 노드 아래에 고성능 런타임 처리기 구성 스니펫을 생성해야 하고 클러스터 아래에 고성능 런타임 클래스를 생성해야 합니다. CPU 부하 분산 구성 기능을 활성화하는 것을 제외하고는 기본 런타임 처리기와 콘텐츠가 동일합니다.
Pod에 대해 CPU 부하 분산을 비활성화하려면 Pod
사양에 다음 필드가 포함되어야 합니다.
CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 그렇지 않은 경우 CPU 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.
19.4. 우선순위가 높은 Pod의 전원 저장 모드 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
워크로드가 실행되는 노드에 대한 절전을 구성할 때 우선 순위가 높은 워크로드가 영향을 받지 않도록 Pod를 구성할 수 있습니다.
절전 구성으로 노드를 구성할 때 Pod 수준에서 성능 구성으로 높은 우선 순위 워크로드를 구성해야 합니다. 즉, 구성이 Pod에서 사용하는 모든 코어에 적용됩니다.
Pod 수준에서 P-state 및 C-state를 비활성화하면 최상의 성능과 짧은 대기 시간을 위해 높은 우선 순위의 워크로드를 구성할 수 있습니다.
주석 | 가능한 값은 다음과 같습니다. | 설명 |
---|---|---|
|
|
이 주석을 사용하면 각 CPU에 대해 C-state를 활성화하거나 비활성화할 수 있습니다. 또는 C 상태에 대해 최대 대기 시간을 microseconds로 지정할 수도 있습니다. 예를 들어 |
|
지원되는 모든 |
각 CPU에 |
사전 요구 사항
- 우선 순위가 높은 워크로드 Pod가 예약된 노드의 성능 프로필에 절전을 구성했습니다.
프로세스
우선순위가 높은 워크로드 Pod에 필요한 주석을 추가합니다. 주석은
기본
설정을 재정의합니다.우선순위가 높은 워크로드 주석의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Pod를 다시 시작하여 주석을 적용합니다.
19.5. CPU CFS 할당량 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
고정 Pod의 CPU 제한을 제거하려면 cpu-quota.crio.io: "disable"
주석이 있는 Pod를 생성합니다. 이 주석은 Pod가 실행될 때 CPU를 완전히 공정 스케줄러(CFS) 할당량을 비활성화합니다.
cpu-quota.crio.io
가 비활성화된 Pod 사양의 예
CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 예를 들어 CPU 고정 컨테이너가 포함된 Pod입니다. 그렇지 않으면 CPU CFS 할당량을 비활성화하면 클러스터의 다른 컨테이너 성능에 영향을 미칠 수 있습니다.
19.6. 고정된 컨테이너가 실행 중인 CPU에 대한 인터럽트 처리 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
작업 부하에 대한 낮은 대기 시간을 달성하기 위해 일부 컨테이너는 고정된 CPU가 장치 인터럽트를 처리하지 않아야 합니다. 포드 주석인 irq-load-balancing.crio.io
는 고정된 컨테이너가 실행 중인 CPU에서 장치 인터럽트를 처리할지 여부를 정의하는 데 사용됩니다. 구성된 경우, CRI-O는 Pod 컨테이너가 실행 중인 장치 인터럽트를 비활성화합니다.
개별 포드에 속한 컨테이너가 고정된 CPU에 대한 인터럽트 처리를 비활성화하려면 성능 프로필에서 globalDisableIrqLoadBalancing
이 false
로 설정되어 있는지 확인하세요. 그런 다음 Pod 사양에서 irq-load-balancing.crio.io
Pod 주석을 비활성화
로 설정합니다.
다음 포드 사양에는 이 주석이 포함되어 있습니다.
20장. 저지연 노드 튜닝 상태 디버깅 링크 복사링크가 클립보드에 복사되었습니다!
PerformanceProfile
사용자 정의 리소스(CR) 상태 필드를 사용하여 클러스터 노드에서 튜닝 상태를 보고하고 지연 문제를 디버깅합니다.
20.1. 짧은 대기 시간 CNF 튜닝 상태 디버깅 링크 복사링크가 클립보드에 복사되었습니다!
PerformanceProfile
CR(사용자 정의 리소스)에는 튜닝 상태를 보고하고 대기 시간 성능 저하 문제를 디버깅하기 위한 상태 필드가 있습니다. 이러한 필드는 상태를 보고하여 Operator 조정 기능의 상태에 대해 설명합니다.
일반적으로 성능 프로필에 연결된 머신 구성 풀의 상태가 성능 저하 상태이면 PerformanceProfile
이 성능 저하 상태가 되는 문제가 발생할 수 있습니다. 이 경우 머신 구성 풀에서 실패 메시지를 발행합니다.
노드 튜닝 연산자에는 performanceProfile.spec.status.Conditions
상태 필드가 포함되어 있습니다.
Status
필드에는 성능 프로필의 상태를 나타내는 Type
값을 지정하는 Conditions
가 포함되어 있습니다.
Available
- 모든 머신 구성 및 Tuned 프로필이 성공적으로 생성되었으며 구성 요소에서 처리해야 하는 클러스터에 사용할 수 있습니다(NTO, MCO, Kubelet).
Upgradeable
- Operator에서 유지보수하는 리소스가 업그레이드하기에 안전한 상태인지를 나타냅니다.
Progressing
- 성능 프로필의 배포 프로세스가 시작되었음을 나타냅니다.
Degraded
다음과 같은 경우 오류를 표시합니다.
- 성능 프로필 검증에 실패했습니다.
- 모든 관련 구성 요소 생성이 성공적으로 완료되지 않았습니다.
이러한 각 유형에는 다음 필드가 포함되어 있습니다.
상태
-
특정 유형의 상태(
true
또는false
)입니다. Timestamp
- 트랜잭션 타임스탬프입니다.
Reason string
- 머신에서 읽을 수 있는 이유입니다.
Message string
- 상태 및 오류 세부 정보(있는 경우)를 설명하는 사람이 읽을 수 있는 이유입니다.
20.1.1. 머신 구성 풀 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필 및 생성된 제품은 연관 MCP(머신 구성 풀)에 따라 노드에 적용됩니다. MCP는 커널 인수, kube 구성, 대규모 페이지 할당, rt-kernel 배포를 포함하는 성능 프로필에 의해 생성된 머신 구성을 적용하는 진행 상황에 대한 귀중한 정보를 보유하고 있습니다. 성능 프로필 컨트롤러는 MCP의 변경 사항을 모니터링하고 이에 따라 성능 프로필 상태를 업데이트합니다.
MCP가 성능 프로필 상태에 반환하는 유일한 조건은 MCP가 저하된
경우이며, 이 경우 performanceProfile.status.condition.Degraded = true가
됩니다.
예제
다음은 생성된 연관 머신 구성 풀(worker-cnf
)이 있는 성능 프로필의 예입니다.
연관 머신 구성 풀이 성능 저하 상태입니다.
oc get mcp
# oc get mcp
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-2ee57a93fa6c9181b546ca46e1571d2d True False False 3 3 3 0 2d21h worker rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f True False False 2 2 2 0 2d21h worker-cnf rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c False True True 2 1 1 1 2d20h
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-2ee57a93fa6c9181b546ca46e1571d2d True False False 3 3 3 0 2d21h worker rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f True False False 2 2 2 0 2d21h worker-cnf rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c False True True 2 1 1 1 2d20h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow MCP의
describe
섹션은 이유를 보여줍니다.oc describe mcp worker-cnf
# oc describe mcp worker-cnf
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Message: Node node-worker-cnf is reporting: "prepping update: machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found" Reason: 1 nodes are reporting degraded status on sync
Message: Node node-worker-cnf is reporting: "prepping update: machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found" Reason: 1 nodes are reporting degraded status on sync
Copy to Clipboard Copied! Toggle word wrap Toggle overflow degraded = true
로 표시된 성능 프로필status
필드 아래에도 성능 저하 상태가 표시되어야 합니다.oc describe performanceprofiles performance
# oc describe performanceprofiles performance
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
20.2. Red Hat 지원을 받기 위한 짧은 대기 시간 튜닝 디버깅 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.
must-gather
툴을 사용하면 노드 튜닝과 NUMA 토폴로지, 짧은 대기 시간 설정으로 인한 문제를 디버깅하는 데 필요한 다른 정보를 비롯하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.
즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 짧은 대기 시간 튜닝 둘 다에 대한 진단 정보를 제공하십시오.
20.2.1. must-gather 툴 정보 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather
CLI 명령은 다음과 같이 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터 정보를 수집합니다.
- 리소스 정의
- 감사 로그
- 서비스 로그
--image
인수를 포함하여 명령을 실행하는 경우 이미지를 하나 이상 지정할 수 있습니다. 이미지를 지정하면 툴에서 해당 기능 또는 제품과 관련된 데이터를 수집합니다. oc adm must-gather
를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local
로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 디렉터리에 생성됩니다.
20.2.2. 저지연 튜닝 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather
CLI 명령을 사용하여 다음과 같은 짧은 대기 시간 튜닝과 연관된 기능 및 오브젝트를 포함한 클러스터 정보를 수집합니다.
- 노드 튜닝 연산자 네임스페이스와 자식 개체.
-
MachineConfigPool
및 연관MachineConfig
오브젝트. - Node Tuning Operator 및 연관 Tuned 오브젝트.
- Linux 커널 명령줄 옵션.
- CPU 및 NUMA 토폴로지.
- 기본 PCI 장치 정보 및 NUMA 위치.
사전 요구 사항
-
cluster-admin
역할을 가진 사용자로 클러스터에 액세스합니다. - OpenShift Container Platform CLI(oc)가 설치되어 있어야 합니다.
프로세스
-
must-gather
데이터를 저장하려는 디렉터리로 이동합니다. 다음 명령을 실행하여 디버깅 정보를 수집합니다.
oc adm must-gather
$ oc adm must-gather
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업 디렉터리에 생성된
must-gather
디렉터리의 압축 파일을 생성합니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.tar cvaf must-gather.tar.gz must-gather-local.5421342344627712289
$ tar cvaf must-gather.tar.gz must-gather-local.5421342344627712289
1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
must-gather-local.5421342344627712289//
를must-gather
도구에서 생성한 디렉토리 이름으로 바꿉니다.
참고지원 사례에 데이터를 첨부하거나 성능 프로필을 생성할 때 Performance Profile Creator 래퍼 스크립트와 함께 사용하려면 압축 파일을 만듭니다.
- Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.
21장. 플랫폼 검증을 위한 지연 테스트 수행 링크 복사링크가 클립보드에 복사되었습니다!
CNF(클라우드 기반 네트워크 기능) 테스트 이미지를 사용하면 CNF 워크로드를 실행하는 데 필요한 모든 구성 요소가 설치된 CNF 지원 OpenShift Container Platform 클러스터에서 지연 시간 테스트를 실행할 수 있습니다. 작업 부하에 대한 노드 튜닝을 검증하기 위해 대기 시간 테스트를 실행합니다.
cnf-tests
컨테이너 이미지는 registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19
에서 사용할 수 있습니다.
21.1. 지연 시간 테스트를 실행하기 위한 전제 조건 링크 복사링크가 클립보드에 복사되었습니다!
지연 시간 테스트를 실행하려면 클러스터가 다음 요구 사항을 충족해야 합니다.
-
필요한 CNF 구성을 모두 적용했습니다. 여기에는
PerformanceProfile
클러스터와 참조 설계 사양(RDS) 또는 귀하의 특정 요구 사항에 따른 기타 구성이 포함됩니다. -
podman login
명령을 사용하여 고객 포털 자격 증명으로registry.redhat.io
에 로그인했습니다.
21.2. 지연 시간 측정 링크 복사링크가 클립보드에 복사되었습니다!
cnf-tests
이미지는 세 가지 도구를 사용하여 시스템 지연 시간을 측정합니다.
-
hwlatdetect
-
순환 테스트
-
oslat
각 도구에는 특정한 용도가 있습니다. 신뢰할 수 있는 테스트 결과를 얻으려면 도구를 순서대로 사용하세요.
- hwlatdetect
-
베어메탈 하드웨어가 달성할 수 있는 기준을 측정합니다. 다음 지연 시간 테스트를 진행하기 전에
hwlatdetect
에서 보고된 지연 시간이 필요한 임계값을 충족하는지 확인하세요. 운영 체제를 조정하여 하드웨어 지연 시간 급증을 해결할 수 없기 때문입니다. - cyclictest
-
hwlatdetect가
검증을 통과한 후 실시간 커널 스케줄러 지연 시간을 확인합니다.cycltest
도구는 반복 타이머를 예약하고 원하는 트리거 시간과 실제 트리거 시간의 차이를 측정합니다. 이러한 차이점을 통해 인터럽트나 프로세스 우선순위로 인해 발생하는 튜닝의 기본적인 문제를 발견할 수 있습니다. 해당 도구는 실시간 커널에서 실행되어야 합니다. - oslat
- CPU를 많이 사용하는 DPDK 애플리케이션과 유사하게 동작하며 CPU를 많이 사용하는 데이터 처리를 시뮬레이션하는 바쁜 루프에 대한 모든 중단과 교란을 측정합니다.
테스트에서는 다음과 같은 환경 변수를 도입합니다.
환경 변수 | 설명 |
---|---|
| 테스트가 실행되기 시작할 때까지의 시간을 초 단위로 지정합니다. 변수를 사용하면 CPU 관리자 조정 루프가 기본 CPU 풀을 업데이트하도록 할 수 있습니다. 기본값은 0입니다. |
| 지연 테스트를 실행하는 Pod가 사용하는 CPU 수를 지정합니다. 변수를 설정하지 않으면 기본 구성에는 모든 분리된 CPU가 포함됩니다. |
| 지연 시간 테스트를 실행해야 하는 시간을 초 단위로 지정합니다. 기본값은 300초입니다. 참고
지연 테스트가 완료되기 전에 Ginkgo 2.0 테스트 모음의 시간이 초과되는 것을 방지하려면 |
|
작업 부하와 운영 체제에 대해 허용되는 최대 하드웨어 지연 시간을 마이크로초 단위로 지정합니다. |
|
|
|
|
| 최대 허용 지연 시간을 마이크로초 단위로 지정하는 통합 변수입니다. 사용 가능한 모든 지연 도구에 적용됩니다. |
지연 도구에 특정한 변수는 통합 변수보다 우선합니다. 예를 들어, OSLAT_MAXIMUM_LATENCY가
30마이크로초로 설정되고 MAXIMUM_LATENCY가
10마이크로초로 설정된 경우 oslat
테스트는 최대 허용 지연 시간인 30마이크로초로 실행됩니다.
21.3. 대기 시간 테스트 실행 링크 복사링크가 클립보드에 복사되었습니다!
클라우드 기반 네트워크 기능(CNF) 워크로드에 대한 노드 튜닝을 검증하려면 클러스터 지연 시간 테스트를 실행합니다.
루트가 아니거나 권한이 없는 사용자로 podman
명령을 실행하면 마운트 경로가 권한 거부
오류로 인해 실패할 수 있습니다. 로컬 운영 체제와 SELinux 구성에 따라 홈 디렉토리에서 이러한 명령을 실행하는 데 문제가 발생할 수도 있습니다. podman
명령을 작동시키려면 home/<username> 디렉토리가 아닌 폴더에서 명령을 실행하고 볼륨 생성에 :Z를
추가하세요. 예를 들어, -v $(pwd)/:/kubeconfig:Z
. 이를 통해 podman은
SELinux를 적절히 재레이블링할 수 있습니다.
이 절차에서는 hwlatdetect
, cycltest
, oslat
의 세 가지 개별 테스트를 실행합니다. 개별 테스트에 대한 자세한 내용은 해당 섹션을 참조하세요.
프로세스
kubeconfig
파일이 있는 디렉토리에서 셸 프롬프트를 엽니다.현재 디렉토리에 있는
kubeconfig
파일과 관련$KUBECONFIG
환경 변수를 볼륨을 통해 마운트하여 테스트 이미지를 제공합니다. 이를 통해 실행 중인 컨테이너는 컨테이너 내부에서kubeconfig
파일을 사용할 수 있습니다.참고다음 명령에서는 로컬
kubeconfig가
cnf-tests 컨테이너의 kubeconfig/kubeconfig에 마운트되어 클러스터에 액세스할 수 있습니다.지연 시간 테스트를 실행하려면 다음 명령을 실행하고 적절한 변수 값을 대체합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=600\ -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 /usr/bin/test-run.sh \ --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=600\ -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 /usr/bin/test-run.sh \ --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LATENCY_TEST_RUNTIME은 초 단위로 표시되며, 이 경우 600초(10분)입니다. 최대 관찰 지연 시간이 MAXIMUM_LATENCY(20μs)보다 낮으면 테스트가 성공적으로 실행됩니다.
결과가 지연 임계값을 초과하면 테스트가 실패합니다.
-
선택 사항:
--ginkgo.dry-run
플래그를 추가하여 드라이런 모드로 지연 테스트를 실행합니다. 이는 테스트에서 어떤 명령을 실행하는지 확인하는 데 유용합니다. -
선택 사항:
--ginkgo.v
플래그를 추가하여 테스트를 더 자세하게 실행합니다. 선택 사항:
--ginkgo.timeout="24h"
플래그를 추가하여 지연 테스트가 완료되기 전에 Ginkgo 2.0 테스트 모음의 시간이 초과되지 않도록 합니다.중요표시된 대로 테스트하는 동안에는 더 짧은 기간을 사용하여 테스트를 실행할 수 있습니다. 그러나 최종 검증 및 유효한 결과를 얻으려면 테스트를 최소 12시간(43,200초) 동안 실행해야 합니다.
21.3.1. hwlatdetect 실행 링크 복사링크가 클립보드에 복사되었습니다!
hwlatdetect
도구는 Red Hat Enterprise Linux(RHEL) 9.x의 일반 구독을 통해 rt-kernel
패키지에서 사용할 수 있습니다.
루트가 아니거나 권한이 없는 사용자로 podman
명령을 실행하면 마운트 경로가 권한 거부
오류로 인해 실패할 수 있습니다. 로컬 운영 체제와 SELinux 구성에 따라 홈 디렉토리에서 이러한 명령을 실행하는 데 문제가 발생할 수도 있습니다. podman
명령을 작동시키려면 home/<username> 디렉토리가 아닌 폴더에서 명령을 실행하고 볼륨 생성에 :Z를
추가하세요. 예를 들어, -v $(pwd)/:/kubeconfig:Z
. 이를 통해 podman은
SELinux를 적절히 재레이블링할 수 있습니다.
사전 요구 사항
- 지연 시간 테스트를 실행하기 위한 전제 조건을 검토했습니다.
프로세스
hwlatdetect
테스트를 실행하려면 다음 명령을 실행하고 적절한 변수 값을 대체합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.focus="hwlatdetect" --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow hwlatdetect
테스트는 10분(600초) 동안 실행됩니다. 최대 관찰 지연 시간이MAXIMUM_LATENCY
(20μs)보다 낮으면 테스트가 성공적으로 실행됩니다.결과가 지연 임계값을 초과하면 테스트가 실패합니다.
중요표시된 대로 테스트하는 동안에는 더 짧은 기간을 사용하여 테스트를 실행할 수 있습니다. 그러나 최종 검증 및 유효한 결과를 얻으려면 테스트를 최소 12시간(43,200초) 동안 실행해야 합니다.
실패 출력 예시
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
hwlatdetect 테스트 결과 예시
다음과 같은 유형의 결과를 캡처할 수 있습니다.
- 테스트 전반에 걸쳐 변경된 사항에 대한 영향 기록을 작성하기 위해 각 실행 후 수집된 대략적인 결과입니다.
- 가장 좋은 결과와 구성 설정을 적용한 대략적인 테스트를 결합한 세트입니다.
좋은 결과의 예
hwlatdetect
도구는 샘플이 지정된 임계값을 초과하는 경우에만 출력을 제공합니다.
나쁜 결과의 예
hwlatdetect
의 출력은 여러 샘플이 임계값을 초과함을 보여줍니다. 그러나 동일한 출력이라도 다음 요소에 따라 다른 결과를 나타낼 수 있습니다.
- 시험 기간
- CPU 코어 수
- 호스트 펌웨어 설정
다음 지연 시간 테스트를 진행하기 전에 hwlatdetect
에서 보고된 지연 시간이 필요한 임계값을 충족하는지 확인하세요. 하드웨어로 인해 발생하는 지연 시간을 해결하려면 시스템 공급업체 지원팀에 문의해야 할 수도 있습니다.
모든 지연 시간 급증이 하드웨어와 관련된 것은 아닙니다. 작업 부하 요구 사항을 충족하도록 호스트 펌웨어를 조정하세요. 자세한 내용은 시스템 튜닝을 위한 펌웨어 매개변수 설정을 참조하세요.
21.3.2. cyclitect 실행 링크 복사링크가 클립보드에 복사되었습니다!
cycltest
도구는 지정된 CPU에서 실시간 커널 스케줄러 지연 시간을 측정합니다.
루트가 아니거나 권한이 없는 사용자로 podman
명령을 실행하면 마운트 경로가 권한 거부
오류로 인해 실패할 수 있습니다. 로컬 운영 체제와 SELinux 구성에 따라 홈 디렉토리에서 이러한 명령을 실행하는 데 문제가 발생할 수도 있습니다. podman
명령을 작동시키려면 home/<username> 디렉토리가 아닌 폴더에서 명령을 실행하고 볼륨 생성에 :Z를
추가하세요. 예를 들어, -v $(pwd)/:/kubeconfig:Z
. 이를 통해 podman은
SELinux를 적절히 재레이블링할 수 있습니다.
사전 요구 사항
- 지연 시간 테스트를 실행하기 위한 전제 조건을 검토했습니다.
프로세스
cycltest를
수행하려면 다음 명령을 실행하고 적절한 변수 값을 대체합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.focus="cyclictest" --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.focus="cyclictest" --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은
cycltest
도구를 10분(600초) 동안 실행합니다. 최대 관찰 지연 시간이MAXIMUM_LATENCY
(이 예에서는 20μs)보다 낮으면 테스트가 성공적으로 실행됩니다. 일반적으로 20μs 이상의 지연 시간 급증은 통신사 RAN 워크로드에 허용되지 않습니다.결과가 지연 임계값을 초과하면 테스트가 실패합니다.
중요표시된 대로 테스트하는 동안에는 더 짧은 기간을 사용하여 테스트를 실행할 수 있습니다. 그러나 최종 검증 및 유효한 결과를 얻으려면 테스트를 최소 12시간(43,200초) 동안 실행해야 합니다.
실패 출력 예시
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
순환테스트 결과 예시
동일한 출력이라도 작업 부하에 따라 다른 결과가 나타날 수 있습니다. 예를 들어, 최대 18μs의 스파이크는 4G DU 워크로드에는 허용되지만 5G DU 워크로드에는 허용되지 않습니다.
좋은 결과의 예
나쁜 결과의 예
21.3.3. 오슬랫을 달리다 링크 복사링크가 클립보드에 복사되었습니다!
oslat
테스트는 CPU를 많이 사용하는 DPDK 애플리케이션을 시뮬레이션하고 모든 중단과 교란을 측정하여 클러스터가 CPU를 많이 사용하는 데이터 처리를 어떻게 처리하는지 테스트합니다.
루트가 아니거나 권한이 없는 사용자로 podman
명령을 실행하면 마운트 경로가 권한 거부
오류로 인해 실패할 수 있습니다. 로컬 운영 체제와 SELinux 구성에 따라 홈 디렉토리에서 이러한 명령을 실행하는 데 문제가 발생할 수도 있습니다. podman
명령을 작동시키려면 home/<username> 디렉토리가 아닌 폴더에서 명령을 실행하고 볼륨 생성에 :Z를
추가하세요. 예를 들어, -v $(pwd)/:/kubeconfig:Z
. 이를 통해 podman은
SELinux를 적절히 재레이블링할 수 있습니다.
사전 요구 사항
- 지연 시간 테스트를 실행하기 위한 전제 조건을 검토했습니다.
프로세스
oslat
테스트를 수행하려면 다음 명령을 실행하고 변수 값을 적절하게 대체합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.focus="oslat" --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.focus="oslat" --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow LATENCY_TEST_CPUS는
oslat
명령으로 테스트할 CPU 수를 지정합니다.이 명령은
oslat
도구를 10분(600초) 동안 실행합니다. 최대 관찰 지연 시간이MAXIMUM_LATENCY
(20μs)보다 낮으면 테스트가 성공적으로 실행됩니다.결과가 지연 임계값을 초과하면 테스트가 실패합니다.
중요표시된 대로 테스트하는 동안에는 더 짧은 기간을 사용하여 테스트를 실행할 수 있습니다. 그러나 최종 검증 및 유효한 결과를 얻으려면 테스트를 최소 12시간(43,200초) 동안 실행해야 합니다.
실패 출력 예시
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 예에서 측정된 지연 시간은 허용되는 최대값을 벗어납니다.
21.4. 지연 테스트 실패 보고서 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 JUnit 지연 테스트 출력과 테스트 실패 보고서를 생성하세요.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
클러스터 관리자
권한이 있는 사용자로 로그인했습니다.
프로세스
--report
매개변수에 보고서가 덤프되는 경로를 전달하여 클러스터 상태 및 문제 해결을 위한 리소스에 대한 정보가 포함된 테스트 실패 보고서를 만듭니다.podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v
$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --report <report_folder_path> --ginkgo.v
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <report_folder_path>
- 보고서가 생성되는 폴더의 경로입니다.
21.5. JUnit 지연 테스트 보고서 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 JUnit 지연 테스트 출력과 테스트 실패 보고서를 생성하세요.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
클러스터 관리자
권한이 있는 사용자로 로그인했습니다.
프로세스
--junit
매개변수와 보고서가 덤프되는 경로를 함께 전달하여 JUnit 호환 XML 보고서를 만듭니다.참고이 명령을 실행하기 전에
junit
폴더를 만들어야 합니다.podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junit:/junit \ -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.junit-report junit/<file_name>.xml --ginkgo.v
$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junit:/junit \ -e KUBECONFIG=/kubeconfig/kubeconfig registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.junit-report junit/<file_name>.xml --ginkgo.v
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
file_name
- XML 보고서 파일의 이름입니다.
21.6. 단일 노드 OpenShift 클러스터에서 대기 시간 테스트 실행 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행할 수 있습니다.
루트가 아니거나 권한이 없는 사용자로 podman
명령을 실행하면 마운트 경로가 권한 거부
오류로 인해 실패할 수 있습니다. podman
명령을 작동시키려면 볼륨 생성에 :Z를
추가합니다. 예: -v $(pwd)/:/kubeconfig:Z
. 이를 통해 podman은
SELinux를 적절히 재레이블링할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
클러스터 관리자
권한이 있는 사용자로 로그인했습니다. - 노드 튜닝 연산자를 사용하여 클러스터 성능 프로필을 적용했습니다.
프로세스
단일 노드 OpenShift 클러스터에서 지연 테스트를 실행하려면 다음 명령을 실행하세요.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고각 테스트의 기본 런타임은 300초입니다. 유효한 지연 테스트 결과를 얻으려면
LATENCY_TEST_RUNTIME
변수를 업데이트하여 최소 12시간 동안 테스트를 실행하세요. 버킷 대기 시간 검증 단계를 실행하려면 최대 대기 시간을 지정해야 합니다. 최대 지연 시간 변수에 대한 자세한 내용은 "지연 시간 측정" 섹션의 표를 참조하세요.테스트 모음을 실행한 후에는 모든 무위 리소스가 정리됩니다.
21.7. 연결이 끊긴 클러스터에서 대기 시간 테스트 실행 링크 복사링크가 클립보드에 복사되었습니다!
CNF 테스트 이미지는 외부 레지스트리에 접속할 수 없는 연결이 끊긴 클러스터에서 테스트를 실행할 수 있습니다. 여기에는 두 단계가 필요합니다.
-
cnf-tests
이미지를 사용자 정의 연결 해제 레지스트리로 미러링합니다. - 사용자 정의 연결 해제 레지스트리에서 이미지를 사용하도록 테스트에 지시합니다.
클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링
테스트 이미지를 로컬 레지스트리에 미러링하기 위해 oc
에서 필요한 입력을 제공하기 위해 미러
실행 파일이 이미지에 포함되어 제공됩니다.
클러스터와 registry.redhat.io 에 액세스할 수 있는 중간 머신에서 다음 명령을 실행합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <disconnected_registry>
-
연결이 끊긴 미러 레지스트리가 구성되었습니까(예:
my.local.registry:5000/
).
연결이 끊긴 레지스트리에
cnf-tests
이미지를 미러링한 경우 테스트를 실행할 때 이미지를 가져오는 데 사용된 원래 레지스트리를 재정의해야 합니다. 예:podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e IMAGE_REGISTRY="<disconnected_registry>" \ -e CNF_TESTS_IMAGE="cnf-tests-rhel9:v4.19" \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ <disconnected_registry>/cnf-tests-rhel9:v4.19 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e IMAGE_REGISTRY="<disconnected_registry>" \ -e CNF_TESTS_IMAGE="cnf-tests-rhel9:v4.19" \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ <disconnected_registry>/cnf-tests-rhel9:v4.19 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
사용자 정의 레지스트리의 이미지를 사용하도록 테스트 구성
CNF_TESTS_IMAGE
및 IMAGE_REGISTRY
변수를 사용하여 사용자 정의 테스트 이미지와 이미지 레지스트리를 사용하여 지연 테스트를 실행할 수 있습니다.
사용자 지정 테스트 이미지와 이미지 레지스트리를 사용하도록 대기 시간 테스트를 구성하려면 다음 명령을 실행하세요.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e IMAGE_REGISTRY="<custom_image_registry>" \ -e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e IMAGE_REGISTRY="<custom_image_registry>" \ -e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <custom_image_registry>
-
사용자 정의 이미지 레지스트리는 다음과 같습니다.
custom.registry:5000/
. - <custom_cnf-tests_image>
-
사용자 정의 cnf-tests 이미지입니다(예:
custom-cnf-tests-image:latest )
.
클러스터 OpenShift 이미지 레지스트리에 이미지 미러링
OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 내장 컨테이너 이미지 레지스트리를 제공합니다.
프로세스
경로를 통해 레지스트리를 공개하여 레지스트리에 대한 외부 액세스 권한을 얻습니다.
oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 레지스트리 엔드포인트를 가져옵니다.
REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
$ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이미지를 공개하는 데 사용할 네임스페이스를 생성합니다.
oc create ns cnftests
$ oc create ns cnftests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 테스트에 사용된 모든 네임스페이스에서 이미지 스트림을 사용할 수 있도록 합니다. 이는 테스트 네임스페이스가
cnf-tests
이미지 스트림에서 이미지를 가져올 수 있도록 하는 데 필요합니다. 다음 명령을 실행하세요.oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
$ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
$ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 docker 비밀 이름과 인증 토큰을 검색합니다.
SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
$ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
Copy to Clipboard Copied! Toggle word wrap Toggle overflow TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')
$ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어
dockerauth.json
파일을 만듭니다.echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json
$ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이미지 미러링을 수행합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/mirror -registry $REGISTRY/cnftests | oc image mirror --insecure=true \ -a=$(pwd)/dockerauth.json -f -
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ /usr/bin/mirror -registry $REGISTRY/cnftests | oc image mirror --insecure=true \ -a=$(pwd)/dockerauth.json -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 테스트를 실행합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUNTIME=<time_in_seconds> \ -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests cnf-tests-local:latest /usr/bin/test-run.sh --ginkgo.v --ginkgo.timeout="24h"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다른 테스트 이미지 세트 미러링
지연 테스트를 위해 미러링되는 기본 업스트림 이미지를 선택적으로 변경할 수 있습니다.
프로세스
mirror
명령은 기본적으로 업스트림 이미지를 미러링하려고 시도합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 예를 들어, 파일을 로컬에
images.json
으로 저장하는 것처럼미러
명령에 전달합니다. 다음 명령을 사용하면 로컬 경로가 컨테이너 내/kubeconfig
에 마운트되어 mirror 명령에 전달될 수 있습니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 /usr/bin/mirror \ --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \ | oc image mirror -f -
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 /usr/bin/mirror \ --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \ | oc image mirror -f -
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
21.8. cnf-tests 컨테이너 오류 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
지연 시간 테스트를 실행하려면 cnf-tests
컨테이너 내에서 클러스터에 액세스할 수 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
클러스터 관리자
권한이 있는 사용자로 로그인했습니다.
프로세스
다음 명령을 실행하여
cnf-tests
컨테이너 내부에서 클러스터에 액세스할 수 있는지 확인하세요.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ oc get nodes
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel9:v4.19 \ oc get nodes
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령이 작동하지 않으면 DNS, MTU 크기 또는 방화벽 액세스와 관련된 오류가 발생했을 수 있습니다.
22장. 작업자 지연 프로필을 사용하여 높은 지연 환경에서 클러스터 안정성 개선 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자가 플랫폼 검증을 위해 지연 시간 테스트를 수행한 경우, 높은 지연 시간이 발생하는 경우 안정성을 보장하기 위해 클러스터 운영을 조정해야 할 필요성을 발견할 수 있습니다. 클러스터 관리자는 파일에 기록된 하나의 매개변수만 변경하면 됩니다. 이 매개변수는 감독 프로세스가 클러스터의 상태를 읽고 상태를 해석하는 방법에 영향을 미치는 네 가지 매개변수를 제어합니다. 매개변수 하나만 변경하면 클러스터를 쉽고 지원 가능한 방식으로 튜닝할 수 있습니다.
Kubelet
프로세스는 클러스터 상태를 모니터링하기 위한 시작점을 제공합니다. Kubelet은
OpenShift Container Platform 클러스터의 모든 노드에 대한 상태 값을 설정합니다. Kubernetes Controller Manager( kube controller
)는 기본적으로 10초마다 상태 값을 읽습니다. Kube 컨트롤러가
노드 상태 값을 읽을 수 없는 경우 구성된 기간 후에 해당 노드와의 연결이 끊어집니다. 기본 동작은 다음과 같습니다.
-
제어 평면의 노드 컨트롤러는 노드 상태를
'건강하지 않음'
으로 업데이트하고 노드준비
상태를 '알 수 없음'으로 표시합니다. - 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다.
-
Node Lifecycle Controller는
NoExecute
효과가 있는node.kubernetes.io/unreachable
테인트를 노드에 추가하고 기본적으로 5분 후에 제거하도록 노드에 Pod를 예약합니다.
특히 네트워크 가장자리에 노드가 있는 경우 네트워크에 지연 문제가 발생하기 쉬운 경우 이러한 동작으로 인해 문제가 발생할 수 있습니다. 어떤 경우에는 Kubernetes Controller Manager가 네트워크 지연으로 인해 정상 노드에서 업데이트를 받지 못할 수 있습니다. 노드가 정상이더라도 Kubelet은
노드에서 포드를 제거합니다.
이 문제를 방지하려면 작업자 지연 프로필을 사용하여 Kubelet
과 Kubernetes Controller Manager가 작업을 수행하기 전에 상태 업데이트를 기다리는 빈도를 조정할 수 있습니다. 이러한 조정은 제어 평면과 작업자 노드 간의 네트워크 지연이 최적이 아닌 경우 클러스터가 제대로 실행되도록 보장하는 데 도움이 됩니다.
이러한 작업자 지연 프로필에는 클러스터가 지연 증가에 반응하는 방식을 제어하기 위해 신중하게 조정된 값으로 미리 정의된 세 가지 매개변수 세트가 포함되어 있습니다. 수동으로 최상의 값을 실험적으로 찾을 필요는 없습니다.
클러스터를 설치할 때 또는 클러스터 네트워크에서 지연 시간이 증가하는 것을 발견할 때마다 작업자 지연 시간 프로필을 구성할 수 있습니다.
22.1. 작업자 지연 프로필 이해 링크 복사링크가 클립보드에 복사되었습니다!
작업자 지연 프로필은 신중하게 조정된 매개변수의 네 가지 다른 범주입니다. 이러한 값을 구현하는 4개의 매개변수는 node-status-update-frequency
,node-monitor-grace-period
,default-not-ready-toleration-seconds
및 default-unreachable-toleration-seconds
입니다. 이러한 매개변수는 수동 방법을 사용하여 최적의 값을 결정하지 않고도 클러스터가 지연 문제에 반응하는 방식을 제어할 수 있는 값을 사용할 수 있습니다.
이러한 매개변수를 수동으로 설정하는 것은 지원되지 않습니다. 잘못된 매개변수 설정은 클러스터 안정성에 부정적인 영향을 미칩니다.
모든 작업자 지연 프로필은 다음 매개변수를 구성합니다.
- node-status-update-frequency
- kubelet이 API 서버에 노드 상태를 게시하는 빈도를 지정합니다.
- node-monitor-grace-period
-
Kubernetes Controller Manager가 노드를 비정상으로 표시하고
node.kubernetes.io/not-ready
또는node.kubernetes.io/unreachable
오염을 노드에 추가하기 전에 kubelet의 업데이트를 기다리는 시간(초)을 지정합니다. - default-not-ready-toleration-seconds
- Kube API 서버 운영자가 노드를 비정상으로 표시한 후 해당 노드에서 포드를 내보내기 전까지 기다리는 시간(초)을 지정합니다.
- default-unreachable-toleration-seconds
- Kube API 서버 운영자가 노드를 도달 불가능으로 표시한 후 해당 노드에서 포드를 내보내기 전까지 기다리는 시간(초)을 지정합니다.
다음 운영자는 작업자 지연 프로필의 변경 사항을 모니터링하고 그에 따라 대응합니다.
-
MCO(Machine Config Operator)는 작업자 노드에서
node-status-update-frequency
매개변수를 업데이트합니다. -
Kubernetes Controller Manager는 제어 평면 노드에서
node-monitor-grace-period
매개변수를 업데이트합니다. -
Kubernetes API 서버 운영자는 제어 평면 노드에서
default-not-ready-toleration-seconds
및default-unreachable-toleration-seconds
매개변수를 업데이트합니다.
대부분의 경우 기본 구성이 작동하지만 OpenShift Container Platform은 네트워크에서 평소보다 더 긴 지연 시간이 발생하는 상황을 대비해 두 가지 다른 작업자 지연 프로필을 제공합니다. 다음 섹션에서는 세 가지 작업자 지연 프로필에 대해 설명합니다.
- 기본 작업자 대기 시간 프로필
기본
프로필을 사용하면 각Kubelet이
10초마다 상태를 업데이트합니다(node-status-update-frequency
).Kube Controller Manager는
5초마다Kubelet
의 상태를 확인합니다.Kubernetes Controller Manager는
Kubelet
의 상태 업데이트를 40초(node-monitor-grace-period
) 동안 기다린 후Kubelet을
비정상으로 간주합니다. Kubernetes Controller Manager에서 사용 가능한 상태가 없으면 해당 노드를node.kubernetes.io/not-ready
또는node.kubernetes.io/unreachable
오염으로 표시하고 해당 노드의 포드를 제거합니다.Pod가
NoExecute
오염이 있는 노드에 있는 경우 Pod는tolerationSeconds
에 따라 실행됩니다. 노드에 오염이 없으면 300초 후에 제거됩니다(Kube API 서버
의default-not-ready-toleration-seconds
및default-unreachable-toleration-seconds
설정).Expand 프로필 Component 매개변수 현재의 Default
kubelet
node-status-update-frequency
10s
Kubelet 컨트롤러 관리자
node-monitor-grace-period
40s
Kubernetes API Server Operator
default-not-ready-toleration-seconds
300s
Kubernetes API Server Operator
default-unreachable-toleration-seconds
300s
- 중간 작업자 대기 시간 프로필
네트워크 지연 시간이 평소보다 약간 높은 경우
MediumUpdateAverageReaction
프로필을 사용하세요.MediumUpdateAverageReaction
프로필은 kubelet 업데이트 빈도를 20초로 줄이고 Kubernetes Controller Manager가 업데이트를 기다리는 기간을 2분으로 변경합니다. 해당 노드의 포드에 대한 포드 퇴거 기간이 60초로 단축됩니다. 포드에tolerationSeconds
매개변수가 있는 경우, 해당 매개변수에서 지정한 기간 동안 추방이 대기합니다.Kubernetes Controller Manager는 노드가 비정상적이라고 간주하기 위해 2분간 기다립니다. 1분 후에 퇴거 절차가 시작됩니다.
Expand 프로필 Component 매개변수 현재의 MediumUpdateAverageReaction
kubelet
node-status-update-frequency
20대
Kubelet 컨트롤러 관리자
node-monitor-grace-period
2m
Kubernetes API Server Operator
default-not-ready-toleration-seconds
60년대
Kubernetes API Server Operator
default-unreachable-toleration-seconds
60년대
- 낮은 작업자 지연 프로필
네트워크 지연 시간이 매우 긴 경우
LowUpdateSlowReaction
프로필을 사용하세요.LowUpdateSlowReaction
프로필은 kubelet 업데이트 빈도를 1분으로 줄이고 Kubernetes Controller Manager가 업데이트를 기다리는 기간을 5분으로 변경합니다. 해당 노드의 포드에 대한 포드 퇴거 기간이 60초로 단축됩니다. 포드에tolerationSeconds
매개변수가 있는 경우, 해당 매개변수에서 지정한 기간 동안 추방이 대기합니다.Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 5분 정도 기다립니다. 다른 분 후에 제거 프로세스가 시작됩니다.
Expand 프로필 Component 매개변수 현재의 LowUpdateSlowReaction
kubelet
node-status-update-frequency
1m
kubelet Controller Manager
node-monitor-grace-period
5m
Kubernetes API Server Operator
default-not-ready-toleration-seconds
60s
Kubernetes API Server Operator
default-unreachable-toleration-seconds
60s
대기 시간 프로필은 사용자 정의 머신 구성 풀을 지원하지 않으며 기본 작업자 머신 구성 풀만 지원합니다.
22.2. 클러스터 생성 시 작업자 대기 시간 프로필 구현 링크 복사링크가 클립보드에 복사되었습니다!
설치 프로그램의 구성을 편집하려면 먼저 openshift-install create manifests
명령을 사용하여 기본 노드 매니페스트 및 기타 매니페스트 YAML 파일을 생성합니다. 이 파일 구조는 workerLatencyProfile
을 추가하기 전에 존재해야 합니다. 설치 중인 플랫폼에는 다양한 요구 사항이 있을 수 있습니다. 특정 플랫폼에 대한 설명서의 설치 섹션을 참조하십시오.
workerLatencyProfile
은 다음 순서로 매니페스트에 추가해야 합니다.
- 설치에 적합한 폴더 이름을 사용하여 클러스터를 빌드하는 데 필요한 매니페스트를 생성합니다.
-
YAML 파일을 생성하여
config.node
를 정의합니다. 파일은manifests
디렉터리에 있어야 합니다. -
매니페스트에
workerLatencyProfile
을 처음 정의할 때 클러스터 생성 시기본
,mediumUpdateAverageReaction
또는LowUpdateSlowReaction
.
검증
다음은 매니페스트 파일에서
spec.workerLatencyProfile
기본값
을 보여주는 매니페스트 생성 예시입니다.openshift-install create manifests --dir=<cluster-install-dir>
$ openshift-install create manifests --dir=<cluster-install-dir>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 매니페스트를 편집하고 값을 추가합니다. 이 예제에서는
vi
를 사용하여 "Default"workerLatencyProfile
값이 추가된 매니페스트 파일 예제를 표시합니다.vi <cluster-install-dir>/manifests/config-node-default-profile.yaml
$ vi <cluster-install-dir>/manifests/config-node-default-profile.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
22.3. 작업자 대기 시간 프로필 사용 및 변경 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 지연을 처리하기 위해 작업자 지연 프로필을 변경하려면 node.config
객체를 편집하여 프로필 이름을 추가합니다. 대기 시간이 늘어나거나 줄어들면 언제든지 프로필을 변경할 수 있습니다.
한 번에 하나의 작업자 지연 프로필을 이동해야 합니다. 예를 들어, 기본
프로필에서 LowUpdateSlowReaction
작업자 대기 시간 프로필로 직접 이동할 수 없습니다. 먼저 기본
작업자 지연 프로필에서 MediumUpdateAverageReaction
프로필로 이동한 다음 LowUpdateSlowReaction
으로 이동해야 합니다. 마찬가지로 기본
프로필로 돌아갈 때는 먼저 낮은 프로필에서 중간 프로필로 이동한 다음 기본 프로필
로 이동해야 합니다.
OpenShift Container Platform 클러스터를 설치할 때 작업자 대기 시간 프로필을 구성할 수도 있습니다.
프로세스
기본 작업자 대기 시간 프로필에서 이동하려면:
중간 작업자 대기 시간 프로필로 이동:
node.config
객체를 편집합니다.oc edit nodes.config/cluster
$ oc edit nodes.config/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Add
spec.workerLatencyProfile: MediumUpdateAverageReaction
:예제
node.config
객체Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 중간 작업자 대기 시간 정책을 지정합니다.
변경 사항이 적용됨에 따라 각 작업자 노드의 스케줄링이 비활성화됩니다.
선택 사항: 낮은 작업자 지연 프로필로 이동:
node.config
객체를 편집합니다.oc edit nodes.config/cluster
$ oc edit nodes.config/cluster
Copy to Clipboard Copied! Toggle word wrap Toggle overflow spec.workerLatencyProfile
값을LowUpdateSlowReaction
으로 변경합니다.예제
node.config
객체Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 낮은 작업자 대기 시간 정책 사용을 지정합니다.
변경 사항이 적용됨에 따라 각 작업자 노드의 스케줄링이 비활성화됩니다.
검증
모든 노드가
준비
상태로 돌아오면 다음 명령을 사용하여 Kubernetes Controller Manager에서 해당 명령이 적용되었는지 확인할 수 있습니다.oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
$ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 프로필이 적용되고 활성화되었음을 지정합니다.
중간 프로필을 기본값으로 변경하거나 기본값을 중간으로 변경하려면 node.config
객체를 편집하고 spec.workerLatencyProfile
매개변수를 적절한 값으로 설정합니다.
22.4. workerLatencyProfile의 결과 값을 표시하는 단계의 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 명령을 사용하여 workerLatencyProfile
의 값을 표시할 수 있습니다.
검증
Kube API 서버에서 출력된
default-not-ready-toleration-seconds
및default-unreachable-toleration-seconds
필드를 확인하세요.oc get KubeAPIServer -o yaml | grep -A 1 default-
$ oc get KubeAPIServer -o yaml | grep -A 1 default-
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
default-not-ready-toleration-seconds: - "300" default-unreachable-toleration-seconds: - "300"
default-not-ready-toleration-seconds: - "300" default-unreachable-toleration-seconds: - "300"
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kube Controller Manager에서
node-monitor-grace-period
필드의 값을 확인하세요.oc get KubeControllerManager -o yaml | grep -A 1 node-monitor
$ oc get KubeControllerManager -o yaml | grep -A 1 node-monitor
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
node-monitor-grace-period: - 40s
node-monitor-grace-period: - 40s
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Kubelet에서
nodeStatusUpdateFrequency
값을 확인합니다. 디버그 셸에서 루트 디렉토리로/host
디렉토리를 설정합니다. root 디렉토리를/host
로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.oc debug node/<worker-node-name> chroot /host cat /etc/kubernetes/kubelet.conf|grep nodeStatusUpdateFrequency
$ oc debug node/<worker-node-name> $ chroot /host # cat /etc/kubernetes/kubelet.conf|grep nodeStatusUpdateFrequency
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
“nodeStatusUpdateFrequency”: “10s”
“nodeStatusUpdateFrequency”: “10s”
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이러한 출력은 Worker Latency Profile에 대한 타이밍 변수 집합의 유효성을 검사합니다.
23장. 워크로드 분할 링크 복사링크가 클립보드에 복사되었습니다!
워크로드 분할은 컴퓨팅 노드 CPU 리소스를 여러 개의 별개 CPU 세트로 분리합니다. 주요 목적은 고객 워크로드가 실행되는 CPU를 방해하지 않도록 지정된 코어에 플랫폼 포드를 유지하는 것입니다.
워크로드 분할은 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 포드를 격리하여 예약된 CPU 세트에서 실행합니다. 이렇게 하면 클러스터 배포에 남아 있는 CPU가 손상되지 않고 플랫폼이 아닌 워크로드에만 독점적으로 사용할 수 있습니다. 클러스터 관리에 필요한 최소 예약된 CPU 수는 4개의 CPU Hyper-Threads(HT)입니다.
작업 부하 분할을 활성화하고 CPU 리소스를 효과적으로 관리한다는 맥락에서 올바르게 구성되지 않은 노드는 노드 승인 웹훅을 통해 클러스터에 가입할 수 없습니다. 작업 분할 기능이 활성화되면 제어 평면과 작업자에 대한 머신 구성 풀에 노드에서 사용할 구성이 제공됩니다. 이러한 풀에 새 노드를 추가하면 클러스터에 가입하기 전에 노드가 올바르게 구성되었는지 확인할 수 있습니다.
현재, 노드는 풀 내의 모든 노드에 올바른 CPU 친화성이 설정되도록 머신 구성 풀당 균일한 구성을 가져야 합니다. 승인 후, 클러스터 내의 노드는 management.workload.openshift.io/cores
라는 새로운 리소스 유형을 지원하는 것으로 자신을 식별하고 CPU 용량을 정확하게 보고합니다. 워크로드 분할은 클러스터 설치 중에만 활성화할 수 있으며 , install-config.yaml
파일에 추가 필드 cpuPartitioningMode를
추가합니다.
작업 부하 분할이 활성화되면 management.workload.openshift.io/cores
리소스를 통해 스케줄러가 기본 cpuset
뿐 아니라 호스트의 cpushares
용량을 기준으로 포드를 올바르게 할당할 수 있습니다. 이를 통해 작업 분할 시나리오에서 리소스를 더욱 정확하게 할당할 수 있습니다.
워크로드 분할은 Pod 구성에 지정된 CPU 요청과 제한이 준수되도록 보장합니다. OpenShift Container Platform 4.16 이상에서는 CPU 분할을 통해 플랫폼 포드에 대한 정확한 CPU 사용량 한도가 설정됩니다. 워크로드 분할은 management.workload.openshift.io/cores
의 사용자 정의 리소스 유형을 사용하므로 Kubernetes에서 확장 리소스가 필요하기 때문에 요청 및 제한 값이 동일합니다. 그러나 워크로드 분할로 수정된 주석은 원하는 한도를 올바르게 반영합니다.
확장된 리소스는 과도하게 할당될 수 없으므로 컨테이너 사양에 둘 다 있는 경우 요청과 제한이 동일해야 합니다.
23.1. 워크로드 분할 활성화 링크 복사링크가 클립보드에 복사되었습니다!
워크로드 파티셔닝을 사용하면 클러스터 관리 Pod에 지정된 CPU 선호도로 올바르게 파티션할 수 있습니다. 이러한 포드는 성능 프로필의 예약된 값에 지정된 최소 크기 CPU 구성 내에서 정상적으로 작동합니다. 플랫폼에 예약된 CPU 코어 수를 계산할 때 워크로드 분할을 활용하는 추가적인 Day 2 운영자를 고려해야 합니다.
워크로드 분할은 표준 Kubernetes 스케줄링 기능을 사용하여 사용자 워크로드를 플랫폼 워크로드로부터 분리합니다.
클러스터 설치 중에만 워크로드 분할을 활성화할 수 있습니다. 설치 후에는 워크로드 분할을 비활성화할 수 없습니다. 하지만 예약된
CPU와 격리된
CPU의 CPU 구성은 설치 후에 변경할 수 있습니다.
워크로드 파티셔닝 클러스터 범위를 활성화하려면 다음 절차를 사용하십시오.
프로세스
install-config.yaml
파일에서 추가 필드cpuPartitioningMode를
추가하고 이를AllNodes
로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 설치 시 CPU 파티셔닝을 위한 클러스터를 설정합니다. 기본값은
None
입니다.
23.2. 성능 프로필 및 작업 분할 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필을 적용하면 작업 분할 기능을 활용할 수 있습니다. 적절하게 구성된 성능 프로필은 격리된
CPU와 예약된
CPU를 지정합니다. 성과 프로필을 만드는 데 권장되는 방법은 성과 프로필 생성기(PPC) 도구를 사용하여 성과 프로필을 만드는 것입니다.
23.3. 샘플 성능 프로필 구성 링크 복사링크가 클립보드에 복사되었습니다!
PerformanceProfile CR 필드 | 설명 |
---|---|
|
|
|
|
| 격리된 CPU를 설정합니다. 모든 하이퍼스레딩 쌍이 일치하는지 확인하세요. 중요 예약된 CPU 풀과 격리된 CPU 풀은 겹치지 않아야 하며, 사용 가능한 모든 코어에 걸쳐 있어야 합니다. 계산되지 않은 CPU 코어로 인해 시스템에서 정의되지 않은 동작이 발생합니다. |
| 예약된 CPU를 설정합니다. 작업 부하 분할이 활성화되면 시스템 프로세스, 커널 스레드, 시스템 컨테이너 스레드가 해당 CPU로 제한됩니다. 분리되지 않은 모든 CPU를 예약해야 합니다. |
|
|
|
실시간 커널을 사용하려면 |
|
|
24장. 노드 관찰 연산자 사용 링크 복사링크가 클립보드에 복사되었습니다!
Node Observability Operator는 컴퓨팅 노드의 스크립트에서 CRI-O 및 Kubelet 프로파일링 또는 메트릭을 수집하고 저장합니다.
Node Observability Operator를 사용하면 프로파일링 데이터를 쿼리하여 CRI-O 및 Kubelet의 성능 추세를 분석할 수 있습니다. 사용자 지정 리소스 정의의 실행
필드를 사용하여 성능 관련 문제를 디버깅하고 네트워크 메트릭에 대한 내장 스크립트를 실행하는 기능을 지원합니다. CRI-O 및 Kubelet 프로파일링이나 스크립팅을 활성화하려면 사용자 지정 리소스 정의에서 유형
필드를 구성할 수 있습니다.
노드 관찰 연산자는 기술 미리보기 기능에 불과합니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
24.1. 노드 관찰 연산자의 워크플로 링크 복사링크가 클립보드에 복사되었습니다!
다음 워크플로는 노드 관찰 연산자를 사용하여 프로파일링 데이터를 쿼리하는 방법을 간략하게 설명합니다.
- OpenShift Container Platform 클러스터에 Node Observability Operator를 설치합니다.
- 선택한 작업자 노드에서 CRI-O 프로파일링을 활성화하려면 NodeObservability 사용자 지정 리소스를 만듭니다.
- 프로파일링 쿼리를 실행하여 프로파일링 데이터를 생성합니다.
24.2. 노드 관찰 연산자 설치 링크 복사링크가 클립보드에 복사되었습니다!
Node Observability Operator는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. OpenShift Container Platform CLI나 웹 콘솔을 사용하여 Node Observability Operator를 설치할 수 있습니다.
24.2.1. CLI를 사용하여 Node Observability Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift CLI(oc)를 사용하여 Node Observability Operator를 설치할 수 있습니다.
사전 요구 사항
- OpenShift CLI(oc)가 설치되어 있습니다.
-
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 Node Observability Operator를 사용할 수 있는지 확인하세요.
oc get packagemanifests -n openshift-marketplace node-observability-operator
$ oc get packagemanifests -n openshift-marketplace node-observability-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CATALOG AGE node-observability-operator Red Hat Operators 9h
NAME CATALOG AGE node-observability-operator Red Hat Operators 9h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
node-observability-operator
네임스페이스를 만듭니다.oc new-project node-observability-operator
$ oc new-project node-observability-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup
개체 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 네임스페이스를 Operator에 구독하려면
구독
개체 YAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 설치 계획 이름을 확인하세요.
oc -n node-observability-operator get sub node-observability-operator -o yaml | yq '.status.installplan.name'
$ oc -n node-observability-operator get sub node-observability-operator -o yaml | yq '.status.installplan.name'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
install-dt54w
install-dt54w
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 설치 계획 상태를 확인하세요.
oc -n node-observability-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
$ oc -n node-observability-operator get ip <install_plan_name> -o yaml | yq '.status.phase'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow <install_plan_name>
은 이전 명령의 출력에서 얻은 설치 계획 이름입니다.출력 예
COMPLETE
COMPLETE
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Node Observability Operator가 실행 중인지 확인하세요.
oc get deploy -n node-observability-operator
$ oc get deploy -n node-observability-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY UP-TO-DATE AVAILABLE AGE node-observability-operator-controller-manager 1/1 1 1 40h
NAME READY UP-TO-DATE AVAILABLE AGE node-observability-operator-controller-manager 1/1 1 1 40h
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
24.2.2. 웹 콘솔을 사용하여 Node Observability Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔에서 Node Observability Operator를 설치할 수 있습니다.
사전 요구 사항
-
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
프로세스
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
- 관리자 탐색 패널에서 Operator → OperatorHub 를 확장합니다.
- 모든 항목 필드에 노드 관찰 연산자를 입력하고 노드 관찰 연산자 타일을 선택합니다.
- 설치를 클릭합니다.
설치 운영자 페이지에서 다음 설정을 구성합니다.
- 업데이트 채널 영역에서 알파를 클릭합니다.
- 설치 모드 영역에서 클러스터의 특정 네임스페이스를 클릭합니다.
- 설치된 네임스페이스 목록에서 node-observability-operator를 선택합니다.
- 업데이트 승인 영역에서 자동을 선택합니다.
- 설치를 클릭합니다.
검증
- 관리자 탐색 패널에서 Operator → 설치된 Operator 를 확장합니다.
- 노드 관찰 연산자가 연산자 목록에 나열되어 있는지 확인하세요.
24.3. Node Observability Operator를 사용하여 CRI-O 및 Kubelet 프로파일링 데이터 요청 링크 복사링크가 클립보드에 복사되었습니다!
CRI-O 및 Kubelet 프로파일링 데이터를 수집하기 위한 Node Observability 사용자 정의 리소스를 생성합니다.
24.3.1. 노드 관찰성 사용자 정의 리소스 만들기 링크 복사링크가 클립보드에 복사되었습니다!
프로파일링 쿼리를 실행하기 전에 NodeObservability
사용자 정의 리소스(CR)를 만들고 실행해야 합니다. NodeObservability
CR을 실행하면 nodeSelector
와 일치하는 작업자 노드에서 CRI-O 프로파일링을 활성화하는 데 필요한 머신 구성 및 머신 구성 풀 CR이 생성됩니다.
작업자 노드에서 CRI-O 프로파일링이 활성화되어 있지 않으면 NodeObservabilityMachineConfig
리소스가 생성됩니다. NodeObservability
CR에 지정된 nodeSelector
와 일치하는 작업자 노드가 다시 시작됩니다. 완료하는 데 10분 이상 걸릴 수 있습니다.
Kubelet 프로파일링은 기본적으로 활성화되어 있습니다.
노드의 CRI-O 유닉스 소켓은 에이전트 포드에 마운트되어 있으며, 이를 통해 에이전트는 CRI-O와 통신하여 pprof 요청을 실행할 수 있습니다. 마찬가지로 kubelet-serving-ca
인증서 체인은 에이전트 포드에 마운트되어 에이전트와 노드의 kubelet 엔드포인트 간의 안전한 통신이 가능합니다.
사전 요구 사항
- 노드 관찰 연산자를 설치했습니다.
- OpenShift CLI(oc)가 설치되어 있습니다.
-
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 OpenShift Container Platform CLI에 로그인합니다.
oc login -u kubeadmin https://<HOSTNAME>:6443
$ oc login -u kubeadmin https://<HOSTNAME>:6443
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
node-observability-operator
네임스페이스로 다시 전환합니다.oc project node-observability-operator
$ oc project node-observability-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 텍스트를 포함하는
nodeobservability.yaml
이라는 CR 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeObservability
CR을 실행합니다.oc apply -f nodeobservability.yaml
oc apply -f nodeobservability.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
nodeobservability.olm.openshift.io/cluster created
nodeobservability.olm.openshift.io/cluster created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodeObservability
CR의 상태를 검토하세요.oc get nob/cluster -o yaml | yq '.status.conditions'
$ oc get nob/cluster -o yaml | yq '.status.conditions'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeObservability
CR 실행은 이유가Ready
이고 상태가True일
때 완료됩니다.
24.3.2. 프로파일링 쿼리 실행 링크 복사링크가 클립보드에 복사되었습니다!
프로파일링 쿼리를 실행하려면 NodeObservabilityRun
리소스를 만들어야 합니다. 프로파일링 쿼리는 30초 동안 CRI-O 및 Kubelet 프로파일링 데이터를 가져오는 차단 작업입니다. 프로파일링 쿼리가 완료되면 컨테이너 파일 시스템 /run/node-observability
디렉토리 내에서 프로파일링 데이터를 검색해야 합니다. 데이터의 수명은 emptyDir
볼륨을 통해 에이전트 포드에 바인딩되므로 에이전트 포드가 실행
상태인 동안 프로파일링 데이터에 액세스할 수 있습니다.
언제든지 프로파일링 쿼리를 한 번만 요청할 수 있습니다.
사전 요구 사항
- 노드 관찰 연산자를 설치했습니다.
-
NodeObservability
사용자 정의 리소스(CR)를 생성했습니다. -
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다.
프로세스
다음 텍스트를 포함하는
nodeobservabilityrun.yaml
이라는 이름의NodeObservabilityRun
리소스 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeObservabilityRun
리소스를 실행하여 프로파일링 쿼리를 트리거합니다.oc apply -f nodeobservabilityrun.yaml
$ oc apply -f nodeobservabilityrun.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodeObservabilityRun
의 상태를 검토하세요.oc get nodeobservabilityrun nodeobservabilityrun -o yaml | yq '.status.conditions'
$ oc get nodeobservabilityrun nodeobservabilityrun -o yaml | yq '.status.conditions'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 상태가
True
이면 프로파일링 쿼리가 완료되고 유형이완료됨
.다음 bash 스크립트를 실행하여 컨테이너의
/run/node-observability
경로에서 프로파일링 데이터를 검색합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
24.4. 노드 관찰 연산자 스크립팅 링크 복사링크가 클립보드에 복사되었습니다!
스크립팅을 사용하면 현재의 Node Observability Operator와 Node Observability Agent를 사용하여 미리 구성된 bash 스크립트를 실행할 수 있습니다.
이러한 스크립트는 CPU 부하, 메모리 부족, 워커 노드 문제와 같은 주요 지표를 모니터링합니다. 또한 SAR 보고서와 맞춤형 성과 지표도 수집합니다.
24.4.1. 스크립팅을 위한 Node Observability 사용자 정의 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
스크립팅을 실행하기 전에 NodeObservability
사용자 정의 리소스(CR)를 만들고 실행해야 합니다. NodeObservability
CR을 실행하면 nodeSelector
레이블과 일치하는 컴퓨팅 노드에서 스크립팅 모드로 에이전트가 활성화됩니다.
사전 요구 사항
- 노드 관찰 연산자를 설치했습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다.
프로세스
다음 명령을 실행하여 OpenShift Container Platform 클러스터에 로그인합니다.
oc login -u kubeadmin https://<host_name>:6443
$ oc login -u kubeadmin https://<host_name>:6443
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
node-observability-operator
네임스페이스로 전환합니다.oc project node-observability-operator
$ oc project node-observability-operator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 내용을 포함하는
nodeobservability.yaml
이라는 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodeObservability
CR을 만듭니다.oc apply -f nodeobservability.yaml
$ oc apply -f nodeobservability.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
nodeobservability.olm.openshift.io/cluster created
nodeobservability.olm.openshift.io/cluster created
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodeObservability
CR의 상태를 검토하세요.oc get nob/cluster -o yaml | yq '.status.conditions'
$ oc get nob/cluster -o yaml | yq '.status.conditions'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeObservability
CR 실행은이유가
준비
이고상태가
"참"
일 때 완료됩니다.
24.4.2. 노드 Observability Operator 스크립팅 구성 링크 복사링크가 클립보드에 복사되었습니다!
사전 요구 사항
- 노드 관찰 연산자를 설치했습니다.
-
NodeObservability
사용자 정의 리소스(CR)를 생성했습니다. -
cluster-admin
권한이 있는 클러스터에 액세스할 수 있습니다.
프로세스
다음 내용을 포함하는
nodeobservabilityrun-script.yaml
이라는 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요다음 스크립트만 요청할 수 있습니다.
-
metrics.sh
-
network-metrics.sh
(monitor.sh
사용)
-
다음 명령으로
NodeObservabilityRun
리소스를 만들어 스크립팅을 트리거합니다.oc apply -f nodeobservabilityrun-script.yaml
$ oc apply -f nodeobservabilityrun-script.yaml
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodeObservabilityRun
스크립팅의 상태를 검토하세요.oc get nodeobservabilityrun nodeobservabilityrun-script -o yaml | yq '.status.conditions'
$ oc get nodeobservabilityrun nodeobservabilityrun-script -o yaml | yq '.status.conditions'
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 상태
가True
이고유형
이Finished
이면 스크립팅이 완료됩니다.다음 bash 스크립트를 실행하여 컨테이너의 루트 경로에서 스크립팅 데이터를 검색합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Legal Notice
링크 복사링크가 클립보드에 복사되었습니다!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.