확장 및 성능
프로덕션 환경에서 OpenShift Container Platform 클러스터 스케일링 및 성능 튜닝
초록
1장. OpenShift Container Platform 확장성 및 성능 개요 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 클러스터의 성능 및 규모를 최적화하는 데 도움이 되는 모범 사례와 툴을 제공합니다. 다음 문서에서는 권장 성능 및 확장성 사례, 참조 설계 사양, 최적화 및 짧은 대기 시간 튜닝에 대한 정보를 제공합니다.
Red Hat 지원에 문의하려면 지원 받기를 참조하십시오.
일부 성능 및 확장성 Operator에는 OpenShift Container Platform 릴리스 사이클과 독립적인 릴리스 사이클이 있습니다. 자세한 내용은 Openshift Operator 를 참조하십시오.
권장 성능 및 확장성 사례
계획, 최적화 및 측정
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) 및 버스트 비율은 현재 각각 5 및 10 으로 설정됩니다. 이러한 값은 OpenShift Container Platform에서 수정할 수 없습니다.
2.1.2. 컨트롤 플레인 노드 크기 조정 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인 노드 리소스 요구 사항은 클러스터의 노드 및 오브젝트 수와 유형에 따라 다릅니다. 다음 컨트롤 플레인 노드 크기 권장 사항은 컨트롤 플레인 밀도 중심 테스트 또는 Cluster-density 테스트 결과를 기반으로 합니다. 이 테스트에서는 지정된 수의 네임스페이스에서 다음 오브젝트를 생성합니다.
- 이미지 스트림 1개
- 빌드 한 개
-
5개의 배포:
수면상태의 Pod 복제본 2개, 시크릿 4개, 구성 맵 4개, 각각 1개의 하향 API 볼륨 1개 사용 - 5개의 서비스, 각각 이전 배포 중 하나의 TCP/8080 및 TCP/8443 포트를 가리키는 서비스
- 1 이전 서비스의 첫 번째 경로를 가리키는 경로
- 2048 임의의 문자열 문자를 포함하는 10개의 보안
- 2048 임의의 문자열 문자를 포함하는 구성 맵 10
| 작업자 노드 수 | cluster-density(네임스페이스) | CPU 코어 수 | 메모리(GB) |
|---|---|---|---|
| 24 | 500 | 4 | 16 |
| 120 | 1000 | 8 | 32 |
| 252 | 4000 | 16하지만 OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 24개 | OVN-Kubernetes 네트워크 플러그인을 사용하는 경우 64이지만 128 |
| 501 그러나 OVN-Kubernetes 네트워크 플러그인에서는 테스트되지 않았습니다. | 4000 | 16 | 96 |
위의 표의 데이터는 AWS 상단에서 실행되는 OpenShift Container Platform을 기반으로 하며 r5.4xlarge 인스턴스를 control-plane 노드로 사용하고 m5.2xlarge 인스턴스를 작업자 노드로 사용합니다.
3개의 컨트롤 플레인 노드가 있는 대규모 및 밀도가 높은 클러스터에서는 노드 중 하나가 중지, 재부팅 또는 실패할 때 CPU 및 메모리 사용량이 증가합니다. 전원, 네트워크, 기본 인프라 또는 비용 절감을 위해 클러스터를 종료한 후 클러스터를 다시 시작하는 의도적인 사례로 인해 오류가 발생할 수 있습니다. 나머지 두 컨트롤 플레인 노드는 고가용성이 되기 위해 부하를 처리하여 리소스 사용량을 늘려야 합니다. 이는 컨트롤 플레인 노드가 직렬로 연결, 드레이닝, 재부팅되어 운영 체제 업데이트를 적용하고 컨트롤 플레인 Operator 업데이트를 적용하기 때문에 업그레이드 중에도 이 문제가 발생할 수 있습니다. 단계적 오류를 방지하려면 컨트롤 플레인 노드에서 전체 CPU 및 메모리 리소스 사용량을 사용 가능한 모든 용량의 최대 60 %로 유지하여 리소스 사용량 급증을 처리합니다. 리소스 부족으로 인한 다운타임을 방지하기 위해 컨트롤 플레인 노드에서 CPU 및 메모리를 늘립니다.
노드 크기 조정은 클러스터의 노드 수와 개체 수에 따라 달라집니다. 또한 클러스터에서 개체가 현재 생성되는지에 따라 달라집니다. 개체 생성 중에 컨트롤 플레인은 개체가 running 단계에 있을 때보다 리소스 사용량 측면에서 더 활성화됩니다.
OLM(Operator Lifecycle Manager)은 컨트롤 플레인 노드에서 실행되며, 메모리 공간은 OLM이 클러스터에서 관리해야 하는 네임스페이스 및 사용자 설치된 Operator 수에 따라 다릅니다. OOM이 종료되지 않도록 컨트를 플레인 노드의 크기를 적절하게 조정해야 합니다. 다음 데이터 지점은 클러스터 최대값 테스트 결과를 기반으로 합니다.
| 네임스페이스 수 | 유휴 상태의 OLM 메모리(GB) | 5명의 사용자 operator가 설치된 OLM 메모리(GB) |
|---|---|---|
| 500 | 0.823 | 1.7 |
| 1000 | 1.2 | 2.5 |
| 1500 | 1.7 | 3.2 |
| 2000 | 2 | 4.4 |
| 3000 | 2.7 | 5.6 |
| 4000 | 3.8 | 7.6 |
| 5000 | 4.2 | 9.02 |
| 6000 | 5.8 | 11.3 |
| 7000 | 6.6 | 12.9 |
| 8000 | 6.9 | 14.8 |
| 9000 | 8 | 17.7 |
| 10,000 | 9.9 | 21.6 |
실행 중인 OpenShift Container Platform 4.12 클러스터에서만 컨트롤 플레인 노드 크기를 수정할 수 있습니다.
- 사용자 프로비저닝 설치 방법으로 설치된 클러스터입니다.
- 설치 관리자 프로비저닝 인프라 설치 방법으로 설치된 AWS 클러스터
- 컨트롤 플레인 머신 세트를 사용하여 컨트롤 플레인 시스템을 관리하는 클러스터입니다.
다른 모든 구성의 경우 총 노드 수를 추정하고 설치 중에 제안된 컨트롤 플레인 노드 크기를 사용해야 합니다.
권장 사항은 OpenShift SDN이 있는 OpenShift Container Platform 클러스터에서 네트워크 플러그인으로 캡처된 데이터 포인트를 기반으로 합니다.
OpenShift Container Platform 4.12에서 CPU 코어의 절반(500밀리코어)은 OpenShift Container Platform 3.11 및 이전 버전과 비교되어 기본적으로 시스템에 의해 예약되어 있습니다. 이러한 점을 고려하여 크기가 결정됩니다.
2.1.2.1. 컨트롤 플레인 머신에 더 큰 Amazon Web Services 인스턴스 유형 선택 링크 복사링크가 클립보드에 복사되었습니다!
AWS(Amazon Web Services) 클러스터의 컨트롤 플레인 시스템에 더 많은 리소스가 필요한 경우 사용할 컨트롤 플레인 시스템의 더 큰 AWS 인스턴스 유형을 선택할 수 있습니다.
컨트롤 플레인 머신 세트를 사용하는 클러스터의 절차는 컨트롤 플레인 머신 세트를 사용하지 않는 클러스터의 절차와 다릅니다.
클러스터에서 ControlPlaneMachineSet CR의 상태에 대해 확신이 있는 경우 CR 상태를 확인할 수 있습니다.
2.1.2.1.1. 컨트롤 플레인 머신 세트를 사용하여 Amazon Web Services 인스턴스 유형 변경 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인 머신 세트 CR(사용자 정의 리소스)에서 사양을 업데이트하여 컨트롤 플레인 시스템이 사용하는 AWS(Amazon Web Services) 인스턴스 유형을 변경할 수 있습니다.
사전 요구 사항
- AWS 클러스터는 컨트롤 플레인 머신 세트를 사용합니다.
절차
다음 명령을 실행하여 컨트롤 플레인 머신 세트 CR을 편집합니다.
oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster
$ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io clusterCopy 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 콘솔에서 인스턴스 유형을 업데이트하여 사용하는 AWS(Amazon Web Services) 인스턴스 유형을 변경할 수 있습니다.
사전 요구 사항
- 클러스터의 EC2 인스턴스를 수정하는 데 필요한 권한을 사용하여 AWS 콘솔에 액세스할 수 있습니다.
-
cluster-admin역할의 사용자로 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
절차
- AWS 콘솔을 열고 컨트롤 플레인 시스템의 인스턴스를 가져옵니다.
컨트롤 플레인 시스템 인스턴스 하나를 선택합니다.
- 선택한 컨트롤 플레인 시스템의 경우 etcd 스냅샷을 생성하여 etcd 데이터를 백업하십시오. 자세한 내용은 "Backing up 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의 지표 또는 시계열 수가 증가할 수 있기 때문입니다. 다음 인프라 노드 크기 권장 사항은 컨트롤 플레인 노드 크기 조정 섹션에 자세히 설명된 클러스터 밀도 테스트에서 관찰된 결과를 기반으로 합니다. 여기서 모니터링 스택 및 기본 ingress-controller가 이러한 노드로 이동되었습니다.
| 작업자 노드 수 | 클러스터 밀도 또는 네임스페이스 수 | CPU 코어 수 | 메모리(GB) |
|---|---|---|---|
| 27 | 500 | 4 | 24 |
| 120 | 1000 | 8 | 48 |
| 252 | 4000 | 16 | 128 |
| 501 | 4000 | 32 | 128 |
일반적으로 클러스터당 세 개의 인프라 노드를 사용하는 것이 좋습니다.
이러한 크기 조정 권장 사항은 지침으로 사용해야 합니다. Prometheus는 고도의 메모리 집약적 애플리케이션입니다. 리소스 사용량은 노드 수, 오브젝트, Prometheus 지표 스크래핑 간격, 지표 또는 시계열, 클러스터 사용 기간 등 다양한 요인에 따라 달라집니다. 또한 라우터 리소스 사용은 경로 수 및 인바운드 요청의 양/유형의 영향을 받을 수 있습니다.
이러한 권장 사항은 클러스터 생성 중에 설치된 모니터링, Ingress 및 레지스트리 인프라 구성 요소를 호스팅하는 인프라 노드에만 적용됩니다.
OpenShift Container Platform 4.12에서 CPU 코어의 절반(500밀리코어)은 OpenShift Container Platform 3.11 및 이전 버전과 비교되어 기본적으로 시스템에 의해 예약되어 있습니다. 명시된 크기 조정 권장 사항은 이러한 요인의 영향을 받습니다.
2.2.2. Cluster Monitoring Operator 스케일링 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은CMO(Cluster Monitoring Operator)가 수집하여 Prometheus 기반 모니터링 스택에 저장하는 지표를 노출합니다. 관리자는 Observe → Dashboards 로 이동하여 OpenShift Container Platform 웹 콘솔의 시스템 리소스, 컨테이너 및 구성 요소 지표에 대한 대시보드를 볼 수 있습니다.
2.2.3. Prometheus 데이터베이스 스토리지 요구사항 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 다양한 규모에 대해 다양한 테스트를 수행했습니다.
- 다음 Prometheus 스토리지 요구 사항은 규범이 아니며 참조로 사용해야 합니다. Prometheus에서 수집한 메트릭을 노출하는 Pod, 컨테이너, 경로 또는 기타 리소스 수를 포함하여 워크로드 활동 및 리소스 밀도에 따라 클러스터에서 리소스 사용량이 증가할 수 있습니다.
- 스토리지 요구 사항에 맞게 크기 기반 데이터 보존 정책을 구성할 수 있습니다.
| 노드 수 | Pod 수 (2 Pod당 컨테이너) | 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의 스토리지 용량을 늘리려면 다음을 수행합니다.
YAML 구성 파일
cluster-monitoring-config.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 접미사 중 하나를 사용하는 고정 지점 정수일 수 있습니다. Ei, Pi, Ti, Gi, Mi, Ki의 power-of-two를 사용할 수도 있습니다. - 5
- 일반적인 값은
ALERTMANAGER_STORAGE_SIZE=20Gi입니다. 스토리지 값은 일반 정수 또는 E, P, T, G, M, K 접미사 중 하나를 사용하는 고정 지점 정수일 수 있습니다. Ei, Pi, Ti, Gi, Mi, Ki의 power-of-two를 사용할 수도 있습니다.
- 보존 기간, 스토리지 클래스 및 스토리지 크기에 대한 값을 추가합니다.
- 파일을 저장합니다.
다음을 실행하여 변경사항을 적용합니다.
oc create -f cluster-monitoring-config.yaml
$ oc create -f cluster-monitoring-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3. etcd 관련 권장 사례 링크 복사링크가 클립보드에 복사되었습니다!
이 주제에서는 OpenShift Container Platform의 etcd에 대한 성능 및 확장성 관련 권장 사례를 설명합니다.
2.3.1. etcd 관련 권장 사례 링크 복사링크가 클립보드에 복사되었습니다!
etcd는 디스크에 데이터를 쓰고 디스크에 제안을 유지하므로 디스크 성능에 따라 성능이 달라집니다. etcd는 특별히 I/O 집약적이 아니지만 성능과 안정성을 최적화하려면 대기 시간이 짧은 블록 장치가 필요합니다. etcd의 비관성 프로토콜은 메타데이터를 로그에 영구적으로 저장하는 데 따라 달라지므로 etcd는 디스크 쓰기 대기 시간에 민감합니다. 디스크 속도가 느리고 다른 프로세스의 디스크 활동이 길어지면 fsync 대기 시간이 길어질 수 있습니다.
이러한 대기 시간 동안 etcd가 하트비트를 놓치고 새 제안을 제때 디스크에 커밋하지 않고 궁극적으로 요청 시간 초과 및 임시 리더 손실이 발생할 수 있습니다. 또한 쓰기 대기 시간이 길면 OpenShift API 속도가 느려 클러스터 성능에 영향을 미칩니다. 이러한 이유로 I/O 민감하거나 집약적이며 동일한 기본 I/O 인프라를 공유하는 컨트롤 플레인 노드에서 다른 워크로드를 배치하지 마십시오.
대기 시간에서는 블록 장치 위에서 etcd를 실행하여 8000바이트 이상의 IOPS를 순차적으로 작성할 수 있습니다. 즉, 대기 시간이 10ms인 경우 fdatasync를 사용하여 WAL의 각 쓰기를 동기화하는 것을 염두에 두십시오. 로드된 클러스터의 경우 8000바이트(2ms)의 순차적 500 IOPS를 사용하는 것이 좋습니다. 이 숫자를 측정하려면 fio와 같은 벤치마킹 도구를 사용할 수 있습니다.
이러한 성능을 얻으려면 대기 시간이 짧고 처리량이 높은 SSD 또는 NVMe 디스크가 지원되는 머신에서 etcd를 실행하십시오. 메모리 셀당 1 비트를 제공하고, 내구성이 있고 신뢰할 수 있으며 쓰기 집약적인 워크로드에 이상적입니다.
etcd의 로드는 노드 및 Pod 수와 같은 정적 요인과 Pod 자동 스케일링, Pod 재시작, 작업 실행 및 기타 워크로드 관련 이벤트로 인한 끝점 변경 등 동적 요인에서 발생합니다. etcd 설정의 크기를 정확하게 조정하려면 워크로드의 특정 요구 사항을 분석해야 합니다. etcd의 로드에 영향을 미치는 노드, 포드 및 기타 관련 요인을 고려하십시오.
다음 하드 디스크 기능은 최적의 etcd 성능을 제공합니다.
- 빠른 읽기 작업을 지원하기 위한 짧은 대기 시간.
- 높은 대역폭은 더 빠른 압축 및 조각 모음을 위한 쓰기입니다.
- 대역폭이 높아지면 오류로부터 보다 신속하게 복구할 수 있습니다.
- Solid state drives as a minimum selection, however NVMe 드라이브가 선호됩니다.
- 안정성을 높이기 위해 다양한 제조 업체의 서버 수준 하드웨어.
- 성능 향상을 위한 RAID 0 기술.
- etcd 전용 드라이브 로그 파일 또는 기타 과도한 워크로드를 etcd 드라이브에 배치하지 마십시오.
NAS 또는 SAN 설정 및 회전 드라이브를 사용하지 마십시오. Ceph Rados Block Device(RBD) 및 기타 유형의 네트워크 연결 스토리지로 인해 네트워크 대기 시간이 예측할 수 없습니다. 대규모 etcd 노드에 빠른 스토리지를 제공하려면 PCI 패스스루를 사용하여 NVM 장치를 노드에 직접 전달합니다.
항상 fio와 같은 유틸리티를 사용하여 벤치마크를 수행합니다. 이러한 유틸리티를 사용하여 증가에 따라 클러스터 성능을 지속적으로 모니터링할 수 있습니다.
NFS(Network File System) 프로토콜 또는 기타 네트워크 기반 파일 시스템을 사용하지 마십시오.
배포된 OpenShift Container Platform 클러스터에서 모니터링하기 위한 몇 가지 주요 메트릭은 etcd 디스크 미리 쓰기 시 미리 쓰기 시간 및 etcd 리더 변경 횟수입니다. 이러한 지표를 추적하려면 Prometheus를 사용하십시오.
etcd 멤버 데이터베이스 크기는 일반 작업 중에 클러스터에서 다를 수 있습니다. 이 차이점은 리더 크기가 다른 멤버와 다른 경우에도 클러스터 업그레이드에는 영향을 미치지 않습니다.
OpenShift Container Platform 클러스터를 생성하기 전이나 후에 etcd 하드웨어를 확인하려면 fio를 사용할 수 있습니다.
사전 요구 사항
- Podman 또는 Docker와 같은 컨테이너 런타임은 테스트 중인 머신에 설치됩니다.
-
데이터는
/var/lib/etcd경로에 작성됩니다.
절차
Fio를 실행하고 결과를 분석합니다.
Podman을 사용하는 경우 다음 명령을 실행합니다.
sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
$ sudo podman run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perfCopy to Clipboard Copied! Toggle word wrap Toggle overflow Docker를 사용하는 경우 다음 명령을 실행합니다.
sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perf
$ sudo docker run --volume /var/lib/etcd:/var/lib/etcd:Z quay.io/cloud-bulldozer/etcd-perfCopy to Clipboard Copied! Toggle word wrap Toggle overflow
실행에서 캡처된 fsync 지표의 99번째 백분위수를 비교하여 10ms 미만인지 확인하여 디스크 속도가 etcd를 호스팅하기에 충분한지 여부를 출력에서 보고합니다. I/O 성능의 영향을 받을 수 있는 가장 중요한 etcd 지표 중 일부는 다음과 같습니다.
-
etcd_disk_wal_fsync_duration_seconds_bucket지표가 etcd의 WAL fsync 기간 보고 -
etcd_disk_backend_commit_duration_seconds_bucket지표에서 etcd 백엔드 커밋 대기 시간 보고 -
etcd_server_leader_changes_seen_total지표에서 리더 변경을 보고
etcd는 모든 멤버 간에 요청을 복제하므로 성능은 네트워크 입력/출력(I/O) 대기 시간에 따라 크게 달라집니다. 네트워크 대기 시간이 길면 etcd 하트비트가 선택 시간 초과보다 오래 걸리므로 리더 선택이 발생하여 클러스터가 손상될 수 있습니다. 배포된 OpenShift Container Platform 클러스터에서 모니터링되는 주요 메트릭은 각 etcd 클러스터 멤버에서 etcd 네트워크 피어 대기 시간의 99번째 백분위 수입니다. 이러한 메트릭을 추적하려면 Prometheus를 사용하십시오.
histogram_quantile(0.99, rate(etcd_network_peer_round_trip_time_seconds_bucket[2m]) 지표에서 etcd가 멤버 간 클라이언트 요청을 복제하기 위한 왕복 시간을 보고합니다. 50ms보다 작은지 확인하십시오.
2.3.2. etcd를 다른 디스크로 이동 링크 복사링크가 클립보드에 복사되었습니다!
공유 디스크에서 etcd를 별도의 디스크로 이동하여 성능 문제를 방지하거나 해결할 수 있습니다.
MCO(Machine Config Operator)는 OpenShift Container Platform 4.12 컨테이너 스토리지를 위한 보조 디스크를 마운트합니다.
이 인코딩된 스크립트는 다음 장치 유형에 대한 장치 이름만 지원합니다.
- SCSI 또는 SATA
-
/dev/sd* - 가상 장치
-
/dev/vd* - NVMe
-
/dev/nvme*[0-9]*n*
제한
-
새 디스크가 클러스터에 연결되면 etcd 데이터베이스가 root 마운트의 일부입니다. 기본 노드가 다시 생성되는 경우 보조 디스크 또는 의도한 디스크의 일부가 아닙니다. 결과적으로 기본 노드는 별도의
/var/lib/etcd마운트를 생성하지 않습니다.
사전 요구 사항
- 클러스터의 etcd 데이터 백업이 있습니다.
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - 머신 구성을 업로드하기 전에 디스크를 추가합니다.
-
MachineConfigPool은metadata.labels[machineconfiguration.openshift.io/role]과 일치해야 합니다. 컨트롤러, 작업자 또는 사용자 지정 풀에 적용됩니다.
이 절차에서는 루트 파일 시스템의 일부(예: /var/ )를 설치된 노드의 다른 디스크 또는 파티션으로 이동하지 않습니다.
컨트롤 플레인 머신 세트를 사용할 때 이 절차는 지원되지 않습니다.
절차
새 디스크를 클러스터에 연결하고 디버그 쉘에서
lsblk명령을 실행하여 노드에서 디스크가 감지되었는지 확인합니다.oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow lsblk
# lsblkCopy to Clipboard Copied! Toggle word wrap Toggle overflow lsblk명령에서 보고한 새 디스크의 장치 이름을 확인합니다.다음 스크립트를 생성하고 이름을
etcd-find-secondary-device.sh로 지정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;device_type_glob>를 블록 장치 유형의 쉘 글로 바꿉니다. SCSI 또는 SATA 드라이브의 경우/dev/sd*를 사용합니다. 가상 드라이브의 경우/dev/vd*를 사용합니다. NVMe 드라이브의 경우/dev/nvme*[0-9]*를 사용합니다.
etcd-find-secondary-device.sh스크립트에서 base64로 인코딩된 문자열을 생성하고 해당 내용을 확인합니다.base64 -w0 etcd-find-secondary-device.sh
$ base64 -w0 etcd-find-secondary-device.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같은 콘텐츠를 사용하여
etcd-mc.yml이라는MachineConfigYAML 파일을 만듭니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- &
lt;encoded_etcd_find_secondary_device_script>를 사용자가 언급한 인코딩된 스크립트 콘텐츠로 바꿉니다.
검증 단계
노드의 디버그 쉘에서
grep /var/lib/etcd /proc/mounts명령을 실행하여 디스크가 마운트되었는지 확인합니다.oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow grep -w "/var/lib/etcd" /proc/mounts
# grep -w "/var/lib/etcd" /proc/mountsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
/dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0
/dev/sdb /var/lib/etcd xfs rw,seclabel,relatime,attr2,inode64,logbufs=8,logbsize=32k,noquota 0 0Copy to Clipboard Copied! Toggle word wrap Toggle overflow
2.3.3. etcd 데이터 조각 모음 링크 복사링크가 클립보드에 복사되었습니다!
대규모 및 밀도가 높은 클러스터의 경우 키 공간이 너무 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. 주기적으로 etcd를 유지 관리하고 조각 모음하여 데이터 저장소에서 공간을 확보합니다. etcd 지표에 대한 Prometheus를 모니터링하고 필요한 경우 조각 모음을 모니터링합니다. 그러지 않으면 etcd에서 키 읽기 및 삭제만 수락하는 유지 관리 모드로 클러스터를 배치하는 클러스터 전체 알람을 생성할 수 있습니다.
다음 주요 메트릭을 모니터링합니다.
-
etcd_server_quota_backend_bytes, 현재 할당량 제한 -
etcd_mvcc_db_total_size_in_use_in_bytes. 이는 기록 압축 후 실제 데이터베이스 사용량을 나타냅니다. -
etcd_mvcc_db_total_size_in_bytes.gb는 조각 모음 대기 중인 여유 공간을 포함하여 데이터베이스 크기를 표시합니다.
etcd 기록 압축과 같은 디스크 조각화를 초래하는 이벤트 후 디스크 공간을 회수하기 위해 etcd 데이터를 조각 모음합니다.
기록 압축은 5분마다 자동으로 수행되며 백엔드 데이터베이스에서 공백이 남습니다. 이 분할된 공간은 etcd에서 사용할 수 있지만 호스트 파일 시스템에서 사용할 수 없습니다. 호스트 파일 시스템에서 이 공간을 사용할 수 있도록 etcd 조각을 정리해야 합니다.
조각 모음이 자동으로 수행되지만 수동으로 트리거할 수도 있습니다.
etcd Operator는 클러스터 정보를 사용하여 사용자에게 가장 효율적인 작업을 결정하기 때문에 자동 조각 모음은 대부분의 경우에 적합합니다.
2.3.3.1. 자동 조각 모음 링크 복사링크가 클립보드에 복사되었습니다!
etcd Operator는 디스크 조각 모음을 자동으로 수행합니다. 수동 조작이 필요하지 않습니다.
다음 로그 중 하나를 확인하여 조각 모음 프로세스가 성공했는지 확인합니다.
- etcd 로그
- cluster-etcd-operator Pod
- Operator 상태 오류 로그
자동 조각 모음을 사용하면 Kubernetes 컨트롤러 관리자와 같은 다양한 OpenShift 핵심 구성 요소에서 리더 선택을 실패하여 실패한 구성 요소를 다시 시작할 수 있습니다. 재시작은 무해하며 실행 중인 다음 인스턴스로 장애 조치를 트리거하거나 다시 시작한 후 구성 요소가 다시 시작됩니다.
조각 모음에 대한 로그 출력 예
etcd member has been defragmented: <member_name>, memberID: <member_id>
etcd member has been defragmented: <member_name>, memberID: <member_id>
조각 모음 실패에 대한 로그 출력 예
failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
failed defrag on member: <member_name>, memberID: <member_id>: <error_message>
2.3.3.2. 수동 조각 모음 링크 복사링크가 클립보드에 복사되었습니다!
Prometheus 경고는 수동 조각 모음을 사용해야 하는 경우를 나타냅니다. 경고는 다음 두 가지 경우에 표시됩니다.
- etcd에서 사용 가능한 공간 50% 이상을 10분 이상 사용하는 경우
- etcd가 10분 이상 총 데이터베이스 크기의 50% 미만을 사용 중인 경우
PromQL 표현식을 사용하여 조각 모음을 사용하여 해제할 etcd 데이터베이스 크기를 MB 단위로 확인하여 조각 모음이 필요한지 여부를 확인할 수도 있습니다. (etcd_mvcc_db_total_size_in_in_bytes - etcd_mvcc_in_in_use_in_bytes)/1024/1024
etcd를 분리하는 것은 차단 작업입니다. 조각 모음이 완료될 때까지 etcd 멤버는 응답하지 않습니다. 따라서 각 pod의 조각 모음 작업 간에 클러스터가 정상 작동을 재개할 수 있도록 1분 이상 대기해야 합니다.
각 etcd 멤버의 etcd 데이터 조각 모음을 수행하려면 다음 절차를 따릅니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
절차
리더가 최종 조각화 처리를 수행하므로 어떤 etcd 멤버가 리더인지 확인합니다.
etcd pod 목록을 가져옵니다.
oc -n openshift-etcd get pods -l k8s-app=etcd -o wide
$ oc -n openshift-etcd get pods -l k8s-app=etcd -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
etcd-ip-10-0-159-225.example.redhat.com 3/3 Running 0 175m 10.0.159.225 ip-10-0-159-225.example.redhat.com <none> <none> etcd-ip-10-0-191-37.example.redhat.com 3/3 Running 0 173m 10.0.191.37 ip-10-0-191-37.example.redhat.com <none> <none> etcd-ip-10-0-199-170.example.redhat.com 3/3 Running 0 176m 10.0.199.170 ip-10-0-199-170.example.redhat.com <none> <none>
etcd-ip-10-0-159-225.example.redhat.com 3/3 Running 0 175m 10.0.159.225 ip-10-0-159-225.example.redhat.com <none> <none> etcd-ip-10-0-191-37.example.redhat.com 3/3 Running 0 173m 10.0.191.37 ip-10-0-191-37.example.redhat.com <none> <none> etcd-ip-10-0-199-170.example.redhat.com 3/3 Running 0 176m 10.0.199.170 ip-10-0-199-170.example.redhat.com <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow Pod를 선택하고 다음 명령을 실행하여 어떤 etcd 멤버가 리더인지 확인합니다.
oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w table
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com etcdctl endpoint status --cluster -w tableCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 출력의
ISLEADER 열에 따르면https://10.0.199.170:2379엔드 포인트가 리더입니다. 이전 단계의 출력과 이 앤드 포인트가 일치하면 리더의 Pod 이름은etcd-ip-10-0199-170.example.redhat.com입니다.
etcd 멤버를 분리합니다.
실행중인 etcd 컨테이너에 연결하고 리더가 아닌 pod 이름을 전달합니다.
oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.com
$ oc rsh -n openshift-etcd etcd-ip-10-0-159-225.example.redhat.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow ETCDCTL_ENDPOINTS환경 변수를 설정 해제합니다.unset ETCDCTL_ENDPOINTS
sh-4.4# unset ETCDCTL_ENDPOINTSCopy to Clipboard Copied! Toggle word wrap Toggle overflow etcd 멤버를 분리합니다.
etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defrag
sh-4.4# etcdctl --command-timeout=30s --endpoints=https://localhost:2379 defragCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Finished defragmenting etcd member[https://localhost:2379]
Finished defragmenting etcd member[https://localhost:2379]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 시간 초과 오류가 발생하면 명령이 성공할 때까지
--command-timeout의 값을 늘립니다.데이터베이스 크기가 감소되었는지 확인합니다.
etcdctl endpoint status -w table --cluster
sh-4.4# etcdctl endpoint status -w table --clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서는 etcd 멤버의 데이터베이스 크기가 시작 크기인 104MB와 달리 현재 41MB임을 보여줍니다.
다음 단계를 반복하여 다른 etcd 멤버에 연결하고 조각 모음을 수행합니다. 항상 리더의 조각 모음을 마지막으로 수행합니다.
etcd pod가 복구될 수 있도록 조각 모음 작업에서 1분 이상 기다립니다. etcd pod가 복구될 때까지 etcd 멤버는 응답하지 않습니다.
공간 할당량을 초과하여
NOSPACE경고가 발생하는 경우 이를 지우십시오.NOSPACE경고가 있는지 확인합니다.etcdctl alarm list
sh-4.4# etcdctl alarm listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
memberID:12345678912345678912 alarm:NOSPACE
memberID:12345678912345678912 alarm:NOSPACECopy to Clipboard Copied! Toggle word wrap Toggle overflow 경고를 지웁니다.
etcdctl alarm disarm
sh-4.4# etcdctl alarm disarmCopy to Clipboard Copied! Toggle word wrap Toggle overflow
3장. 오브젝트 최대값에 따른 환경 계획 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터를 계획하는 경우 다음과 같은 테스트된 오브젝트 최대값을 고려하십시오.
이러한 지침은 가능한 가장 큰 클러스터를 기반으로 합니다. 크기가 작은 클러스터의 경우 최대값이 더 낮습니다. etcd 버전 또는 스토리지 데이터 형식을 비롯하여 명시된 임계값에 영향을 주는 요인은 여러 가지가 있습니다.
대부분의 경우 이러한 수치를 초과하면 전체 성능이 저하됩니다. 반드시 클러스터가 실패하는 것은 아닙니다.
Pod 시작 및 중지 Pod와 같이 빠른 변경이 발생하는 클러스터는 문서화된 것보다 실제 가능한 최대 크기를 줄일 수 있습니다.
3.1. OpenShift Container Platform에 대해 테스트된 클러스터 최대값(주요 릴리스) 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat은 OpenShift Container Platform 클러스터 크기 조정에 대한 직접적인 지침을 제공하지 않습니다. 이는 클러스터가 지원되는 OpenShift Container Platform 범위 내에 있는지 여부를 확인하기 때문에 클러스터 스케일링을 제한하는 모든 다차원 요소를 신중하게 고려해야 하기 때문입니다.
OpenShift Container Platform은 절대 클러스터 최대값이 아닌 테스트된 클러스터 최대값을 지원합니다. OpenShift Container Platform 버전, 컨트롤 플레인 워크로드 및 네트워크 플러그인의 모든 조합이 테스트된 것은 아니므로 다음 표가 모든 배포에 대한 스케일링을 절대 예상하지는 않습니다. 모든 측면이 동시에 최대로 확장되지 않을 수 있습니다. 이 표에는 특정 워크로드 및 배포 구성에 대해 테스트된 최대값이 포함되어 있으며 유사한 배포에서 예상되는 항목에 대한 스케일링 가이드 역할을 합니다.
| 최대값 유형 | 4.x 테스트된 최대값 |
|---|---|
| 노드 수 | 2,000 [1] |
| Pod 수 [2] | 150,000 |
| 노드당 Pod 수 | 500 [3] |
| 코어당 Pod 수 | 기본값 없음 |
| 네임스페이스 수 [4] | 10,000 |
| 빌드 수 | 10,000(기본 Pod RAM 512Mi) - S2I(Source-to-Image) 빌드 전략 |
| 네임스페이스당 Pod 수 [5] | 25,000 |
| Ingress 컨트롤러당 경로 및 백엔드 수 | 라우터당 2,000개 |
| 보안 수 | 80,000 |
| 구성 맵 수 | 90,000 |
| 서비스 수 [6] | 10,000 |
| 네임스페이스당 서비스 수 | 5,000 |
| 서비스당 백엔드 수 | 5,000 |
| 네임스페이스당 배포 수 [5] | 2,000 |
| 빌드 구성 수 | 12,000 |
| CRD(사용자 정의 리소스 정의) 수 | 512 [7] |
- 2000 노드 규모에서 OpenShift Container Platform의 컨트롤 플레인 구성 요소를 완화하기 위해 Pod 일시 중지가 배포되었습니다. 유사한 숫자로 확장하는 기능은 특정 배포 및 워크로드 매개변수에 따라 달라집니다.
- 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
-
이 테스트는 작업자 노드가 100개이며 작업자 노드당 Pod가 500개인 클러스터에서 수행되었습니다. 기본
maxPods는 계속 250입니다.maxPods가 500이 되도록 하려면 사용자 정의 kubelet 구성을 사용하여500으로 설정된maxPods가 포함된 클러스터를 생성해야 합니다. 500개의 사용자 Pod가 필요한 경우 노드에서 이미 실행되고 있는 시스템 Pod가 10~15개가 있으므로hostPrefix22가 필요합니다. 연결된 PVC(영구 볼륨 클레임)가 있는 Pod의 최대 수는 PVC가 할당된 스토리지 백엔드에 따라 달라집니다. 이 테스트에서는 OCS v4(OpenShift Data Foundation v4)만 이 문서에서 설명하는 노드당 Pod 수를 충족할 수 있었습니다. - 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하기 위해 조각 모음을 포함한 etcd에 대한 유지보수를 정기적으로 수행하는 것이 좋습니다.
- 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트에서 반복해야 하는 컨트롤 루프가 많습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
- 각 서비스 포트와 각 서비스 백엔드는 iptables에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
-
OpenShift Container Platform에는 OpenShift Container Platform에서 설치한 제품, OpenShift Container Platform 및 사용자가 생성한 CRD를 포함하여 512개의 CRD(사용자 정의 리소스 정의)가 제한됩니다. 512개 이상의 CRD가 생성된 경우
oc명령 요청이 제한될 수 있습니다.
3.1.1. 시나리오 예 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어 500개의 작업자 노드(m5.2xl)를 테스트하고 OpenShift Container Platform 4.12, OVN-Kubernetes 네트워크 플러그인 및 다음 워크로드 오브젝트를 사용하여 지원됩니다.
- 기본값 외에도 200 네임스페이스
- 노드당 Pod 60개, 서버 30개 및 클라이언트 Pod 30개(전체 30개)
- 57 이미지 스트림/ns (전체 11.4k)
- 서버 Pod에서 지원하는 서비스/시간 15개 (3k 합계)
- 이전 서비스에서 지원하는 15개의 경로/시간 (3k 합계)
- 20개의 보안/ns (4k 합계)
- 10개의 구성 맵/ns (2k 합계)
- 6개의 네트워크 정책/ns, 거부를 포함한 allow-from 수신 및 네임스페이스 내 규칙
- 57개의 빌드/시간
다음 요인은 클러스터 워크로드 스케일링에 영향을 미치는 것으로 알려져 있으며 배포를 계획할 때 스케일링 수에 반영되어야 합니다. 자세한 정보 및 지침은 영업 담당자 또는 Red Hat 지원에 문의하십시오.
- 노드당 Pod 수
- Pod당 컨테이너 수
- 사용된 프로브 유형(예: liveness/readiness, exec/http)
- 네트워크 정책 수
- 프로젝트 수 또는 네임스페이스 수
- 프로젝트당 이미지 스트림 수
- 프로젝트당 빌드 수
- 서비스/엔드포인트 및 유형
- 경로 수
- shard 수
- 보안 수
- 구성 맵 수
API 호출 속도 또는 클러스터 구성이 얼마나 빠르게 변경되는지 추정하는 클러스터 "churn"입니다.
-
5분 창에 Pod 생성 요청에 대한 Prometheus 쿼리:
sum(irate(apiserver_request_count{resources",verb="POST"}[5m]) -
5분 창을 통해 초당 모든 API 요청에 대한 Prometheus 쿼리:
sum(irate(apiserver_request_count{}[5m]))
-
5분 창에 Pod 생성 요청에 대한 Prometheus 쿼리:
- CPU의 클러스터 노드 리소스 소비
- 메모리의 클러스터 노드 리소스 사용
3.2. 클러스터 최대값 테스트를 위한 OpenShift Container Platform 환경 및 구성 링크 복사링크가 클립보드에 복사되었습니다!
3.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 |
- etcd는 대기 시간에 민감하기 때문에 3000 IOPS 및 125MiB의 성능이 있는 gp3 디스크는 컨트롤 플레인/etcd 노드에 사용됩니다. gp3 볼륨은 버스트 성능을 사용하지 않습니다.
- 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
- 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
- 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
- 클러스터는 반복적으로 확장되며 성능 및 확장성 테스트는 지정된 노드 수에 따라 실행됩니다.
3.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 |
| 워크로드 [3] | 16 | 256 | gp2 | 120 [4] | 1 |
| Compute | 16 | 64 | gp2 | 120 | 2개에서 100 [5] |
- etcd는 I/O 집약적이고 대기 시간에 민감하므로 GiB당 120/10 IOPS가 있는 io1 디스크가 컨트롤 플레인/etcd 노드에 사용됩니다.
- 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
- 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
- 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
- 클러스터는 반복적으로 확장됩니다.
3.2.3. IBM Z 플랫폼 링크 복사링크가 클립보드에 복사되었습니다!
| 노드 | vCPU [4] | RAM(GiB)[5] | 디스크 유형 | 디스크 크기(GiB)/IOS | 수량 |
|---|---|---|---|---|---|
| 컨트롤 플레인/etcd [1,2] | 8 | 32 | ds8k | 300 / LCU 1 | 3 |
| Compute [1,3] | 8 | 32 | ds8k | 150 / LCU 2 | 4개의 노드(노드당 100/250/500개의 Pod로 확장) |
- 노드는 두 개의 LUN(Logical Control Unit) 간에 분산되어 etcd가 I/O 집약적이고 지연 시간에 민감하므로 컨트롤 플레인/etcd 노드의 디스크 I/O 부하를 최적화합니다. etcd I/O 수요가 다른 워크로드를 방해하지 않아야 합니다.
- 4개의 컴퓨팅 노드는 동시에 100/250/500개의 Pod를 사용하여 여러 번 반복하는 테스트에 사용됩니다. 먼저 Pod를 인스턴스에 사용할 수 있는지 평가하는 데 Pod를 유휴 상태로 설정합니다. 다음으로 네트워크 및 CPU 까다로운 클라이언트/서버 워크로드가 스트레스를 받고 시스템의 안정성을 평가하는 데 사용되었습니다. 클라이언트 및 서버 포드는 쌍으로 배포되었으며 각 쌍은 두 개의 계산 노드에 분산되었습니다.
- 별도의 워크로드 노드를 사용하지 않았습니다. 워크로드는 두 개의 컴퓨팅 노드 간에 마이크로 서비스 워크로드를 시뮬레이션합니다.
- 사용되는 물리적 프로세서 수는 Linux (IFL)에 대한 6 개의 통합 기능입니다.
- 사용된 총 실제 메모리는 512GiB입니다.
3.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에는 SDN, DNS, Operator 등과 같은 여러 시스템 Pod가 제공되며 기본적으로 모든 작업자 노드에서 실행됩니다. 따라서 위 공식의 결과는 다를 수 있습니다.
3.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바이트(2MiB)로 설정됩니다. 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를 실행할 수 있습니다.
4장. 링크 복사링크가 클립보드에 복사되었습니다!
4.1. 링크 복사링크가 클립보드에 복사되었습니다!
| 리소스 이름 | 설명 |
|---|---|
|
|
터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. |
|
|
터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. |
|
|
터미널이 아닌 상태에서 모든 Pod의 로컬 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
|
|
터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. |
|
|
터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. |
|
|
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
|
| 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다. |
|
| 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다. |
|
| 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다. 이 기능은 기본적으로 비활성화되어 있습니다. |
| 리소스 이름 | 설명 |
|---|---|
|
| 상태와 관계없이 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
|
| 프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다. |
|
| 상태와 관계없이 일치하는 스토리지 클래스가 있는 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다. |
|
| 프로젝트에 존재할 수 있는, 일치하는 스토리지 클래스가 있는 총 영구 볼륨 클레임 수입니다. |
| 리소스 이름 | 설명 |
|---|---|
|
| 프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다. |
|
| 프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다. |
|
| 프로젝트에 존재할 수 있는 총 리소스 할당량 수입니다. |
|
| 프로젝트에 존재할 수 있는 총 서비스 수입니다. |
|
| 프로젝트에 존재할 수 있는 총 시크릿 수입니다. |
|
|
프로젝트에 존재할 수 있는 총 |
|
| 프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다. |
|
| 프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다. |
oc create quota <name> --hard=count/<resource>.<group>=<quota>
$ oc create quota <name> --hard=count/<resource>.<group>=<quota>
4.1.1. 확장 리소스에 대한 리소스 할당량 설정 링크 복사링크가 클립보드에 복사되었습니다!
확장 리소스에는 리소스 과다 할당이 허용되지 않으므로 할당량의 해당 확장 리소스에 requests 및 limits를 지정해야 합니다. 다음은 GPU 리소스 nvidia.com/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개를 사용할 수 있습니다.
이 예에서 할당량은
1입니다.cat gpu-quota.yaml
$ cat gpu-quota.yamlCopy 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
resourcequota/gpu-quota created
resourcequota/gpu-quota createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe quota gpu-quota -n nvidia
$ oc describe quota gpu-quota -n nvidiaCopy 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 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc create pod gpu-pod.yaml
$ oc create pod gpu-pod.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get pods
$ oc get podsCopy 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 1mCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc describe quota gpu-quota -n nvidia
$ oc describe quota gpu-quota -n nvidiaCopy 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 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드에 GPU가 2개 있으므로 기술적으로 가능합니다.
oc create -f gpu-pod.yaml
$ oc create -f gpu-pod.yamlCopy 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=1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.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
이 기능은 기본적으로 비활성화되어 있습니다.
추가 리소스
4.2. 링크 복사링크가 클립보드에 복사되었습니다!
4.2.1. 할당량 적용 링크 복사링크가 클립보드에 복사되었습니다!
할당량이 생성되고 사용량 통계가 업데이트되면 프로젝트에서 새 콘텐츠 생성을 허용합니다. 리소스를 생성하거나 수정할 때는 리소스 생성 또는 수정 요청에 따라 할당량 사용이 즉시 증가합니다.
리소스를 삭제할 때는 프로젝트에 대한 다음 할당량 통계 전체 재계산 중 할당량 사용이 감소합니다.
구성 가능한 시간에 따라 현재 관찰되는 시스템 값으로 할당량 사용을 줄이는 데 걸리는 시간이 결정됩니다.
4.2.2. 링크 복사링크가 클립보드에 복사되었습니다!
할당량은 이러한 값 중을 제한할 수 있습니다.
할당량에 requests.cpu 또는 requests.memory에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스를 명시적으로 요청해야 합니다. 할당량에 limits.cpu 또는 limits.memory에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스에 대한 제한을 명시적으로 지정해야 합니다.
4.2.3. 리소스 할당량 정의의 예 링크 복사링크가 클립보드에 복사되었습니다!
- 1
- 프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.
- 1
- 프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.
- 2
- 터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 코어 1개를 초과할 수 없습니다.
- 3
- 터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 1Gi를 초과할 수 없습니다.
- 4
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 2Gi를 초과할 수 없습니다.
- 5
- 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 코어 2개를 초과할 수 없습니다.
- 6
- 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 2Gi를 초과할 수 없습니다.
- 7
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 4Gi를 초과할 수 없습니다.
- 1
- 터미널이 아닌 상태의 총 Pod 수입니다.
- 2
- 터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
- 3
- 터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
- 4
- 터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다.
- 5
- 할당량을
spec.activeDeadlineSeconds가nil로 설정된 일치하는 Pod로만 제한합니다. 빌드 Pod는RestartNever정책을 적용하지 않는 한NotTerminating에 해당합니다.
- 1
- 프로젝트의 총 영구 볼륨 클레임 수
- 2
- 프로젝트의 모든 영구 볼륨 클레임에서 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
- 3
- 프로젝트의 모든 영구 볼륨 클레임에서 골드 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
- 4
- 프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
- 5
- 프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스의 총 클레임 수는 이 값을 초과할 수 없습니다.
- 6
- 프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을
0으로 설정하면 브론즈 스토리지 클래스에서 스토리지를 요청할 수 없습니다. - 7
- 프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을
0으로 설정하면 브론즈 스토리지 클래스에서 클레임을 생성할 수 없습니다.
4.2.4. 할당량 생성 링크 복사링크가 클립보드에 복사되었습니다!
oc create -f <resource_quota_definition> [-n <project_name>]
$ oc create -f <resource_quota_definition> [-n <project_name>]
oc create -f core-object-counts.yaml -n demoproject
$ oc create -f core-object-counts.yaml -n demoproject
4.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>
이 예제에서는 나열된 리소스가 클러스터에 있는 각 프로젝트의 하드 제한으로 제한됩니다.
4.2.6. 할당량 보기 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어
demoproject라는 프로젝트의 경우 다음과 같습니다.oc get quota -n demoproject
$ oc get quota -n demoproject NAME AGE besteffort 11m compute-resources 2m core-object-counts 29mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 관심 있는 할당량을 입력합니다. 예를 들어
core-object-counts할당량은 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.2.7. 링크 복사링크가 클립보드에 복사되었습니다!
master-restart api master-restart controllers
$ master-restart api
$ master-restart controllers
4.2.8. 링크 복사링크가 클립보드에 복사되었습니다!
추가 리소스
4.3. 링크 복사링크가 클립보드에 복사되었습니다!
리소스 생성 및 수정을 위한 모든 요청은 프로젝트의 각 LimitRange 오브젝트에 대해 평가됩니다. 리소스가 열거된 제약 조건을 위반하는 경우 해당 리소스는 거부됩니다.
코어 및 OpenShift Container Platform 리소스를 모두 하나의 제한 범위 오브젝트로 지정할 수 있습니다.
4.3.1. 컨테이너 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- CPU
- 메모리
지원되는 제한
지정된 경우 컨테이너별로 다음이 true여야 합니다.
컨테이너
| 제약 조건 | 동작 |
|---|---|
|
|
구성에서 |
|
|
구성에서 |
|
|
max
제한 범위가
예를 들어 컨테이너의 |
지원되는 기본값:
default[<resource>]-
기본값은
container.resources.limit[<resource>]to specified value if none입니다. 기본 요청[<resource>]-
기본값은
container.resources.requests[<resource>]to specified value if none입니다.
4.3.2. Pod 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- CPU
- 메모리
지원되는 제한 사항:
Pod의 모든 컨테이너에서 다음 사항이 충족되어야 합니다.
| 제약 조건 | 강제 동작 |
|---|---|
|
|
|
|
|
|
|
|
max |
4.3.3. 이미지 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- 스토리지
리소스 유형 이름:
-
openshift.io/Image
지정된 경우 이미지당 다음 사항이 충족되어야 합니다.
| 제약 조건 | 동작 |
|---|---|
|
|
|
제한을 초과하는 Blob이 레지스트리에 업로드되지 않도록 하려면 할당량을 적용하도록 레지스트리를 구성해야 합니다. REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 환경 변수를 true 로 설정해야 합니다. 새 배포에 대해 기본적으로 환경 변수는 true 로 설정됩니다.
4.3.4. 이미지 스트림 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
-
openshift.io/image-tags -
openshift.io/images
리소스 유형 이름:
-
openshift.io/ImageStream
지정된 경우 이미지 스트림별로 다음 사항이 충족되어야 합니다.
| 제약 조건 | 동작 |
|---|---|
|
|
|
|
|
|
4.3.5. 이미지 참조 수 링크 복사링크가 클립보드에 복사되었습니다!
openshift.io/image-tags 리소스는 고유한 스트림 제한을 나타냅니다. 가능한 참조는 ImageStreamTag, ImageStreamImage 또는 DockerImage 입니다. 태그는 oc tag 및 oc import-image 명령을 사용하거나 이미지 스트림을 사용하여 생성할 수 있습니다. 내부 참조와 외부 참조는 구분되지 않습니다. 그러나 이미지 스트림 사양에 태그된 각 고유 참조는 한 번만 계산됩니다. 내부 컨테이너 이미지 레지스트리에 대한 내보내기는 어떤 방식으로든 제한하지 않지만 태그 제한에 유용합니다.
openshift.io/images 리소스는 이미지 스트림 상태에 기록된 고유한 이미지 이름을 나타냅니다. 내부 레지스트리로 내보낼 수 있는 여러 이미지를 제한하는 데 도움이 됩니다. 내부 및 외부 참조는 구분되지 않습니다.
4.3.6. PersistentVolumeClaim 제한 링크 복사링크가 클립보드에 복사되었습니다!
지원되는 리소스:
- 스토리지
지원되는 제한 사항:
프로젝트의 모든 영구 볼륨 클레임에서 다음 사항이 충족되어야 합니다.
| 제약 조건 | 강제 동작 |
|---|---|
|
| min[<resource>] <= claim.spec.resources.requests[<resource>] (필수) |
|
| claim.spec.resources.requests[<resource>] (필수) <= Max[<resource>] |
제한 범위 오브젝트 정의
추가 리소스
스트림 제한에 대한 자세한 내용은 이미지 스트림 관리를 참조하십시오.
컴퓨팅 리소스 제약 조건에 대한 자세한 내용은 다음을 수행합니다.
CPU 및 메모리 측정 방법에 대한 자세한 내용은 권장 컨트롤 플레인 관행을 참조하십시오.
임시 스토리지에 대한 제한 및 요청을 지정할 수 있습니다. 이 기능에 대한 자세한 내용은 임시 스토리지 이해 를 참조하십시오.
4.4. 제한 범위 작업 링크 복사링크가 클립보드에 복사되었습니다!
4.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
4.4.2. 제한 보기 링크 복사링크가 클립보드에 복사되었습니다!
웹 콘솔에서 프로젝트의 할당량 페이지로 이동하여 프로젝트에 정의된 제한 범위를 볼 수 있습니다. CLI를 사용하여 다음 단계를 수행하여 제한 범위 세부 정보를 볼 수도 있습니다.
프로세스
프로젝트에 정의된 제한 범위 오브젝트 목록을 가져옵니다. 예를 들어
demoproject라는 프로젝트는 다음과 같습니다.oc get limits -n demoproject
$ oc get limits -n demoprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE resource-limits 6d
NAME AGE resource-limits 6dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 제한 범위를 설명합니다. 예를 들어
resource-limits라는 제한 범위의 경우 다음을 수행합니다.oc describe limits resource-limits -n demoproject
$ oc describe limits resource-limits -n demoprojectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.4.3. 제한 범위 삭제 링크 복사링크가 클립보드에 복사되었습니다!
제한 범위를 제거하려면 다음 명령을 실행합니다.
+
oc delete limits <limit_name>
$ oc delete limits <limit_name>
S
추가 리소스
사용자가 프로젝트 리소스에 대해 생성, 제한 및 할당량을 관리할 수 있는 프로젝트 수에 대한 다양한 제한을 적용하는 방법에 대한 자세한 내용은 프로젝트당 리소스 할당량을 참조하십시오.
5장. IBM Z & IBM (R) LinuxONE 환경에 대한 호스트 관련 권장 사례 링크 복사링크가 클립보드에 복사되었습니다!
이 주제에서는 IBM Z 및 IBM® LinuxONE의 OpenShift Container Platform에 대한 권장 호스트 사례를 설명합니다.
s390x 아키텍처는 여러 측면에서 고유합니다. 따라서 여기에 제공된 일부 권장 사항은 다른 플랫폼에 적용되지 않을 수 있습니다.
달리 명시되지 않는 한, 이러한 사례는 IBM Z 및 IBM® LinuxONE의 z/VM 및 RHEL(Red Hat Enterprise Linux) KVM 설치에 모두 적용됩니다.
5.1. CPU 과다 할당 관리 링크 복사링크가 클립보드에 복사되었습니다!
고도로 가상화된 IBM Z 환경에서는 인프라 설정 및 크기를 신중하게 계획해야 합니다. 가상화의 가장 중요한 기능 중 하나는 리소스 과다 할당을 수행하여 하이퍼바이저 수준에서 실제로 사용 가능한 것보다 더 많은 리소스를 가상 머신에 할당하는 기능입니다. 이는 워크로드에 따라 달라지며 모든 설정에 적용할 수 있는 금고 규칙이 없습니다.
설정에 따라 CPU 과다 할당과 관련된 모범 사례를 고려하십시오.
- LPAR 레벨(PR/SM 하이퍼바이저)에서는 사용 가능한 모든 물리적 코어(IFL)를 각 LPAR에 할당하지 마십시오. 예를 들어 4개의 물리적 IFL을 사용할 수 있으면 각각 4개의 논리 IFL을 사용하여 세 개의 LPAR을 정의할 수 없습니다.
- LPAR 공유 및 가중치를 확인하고 이해하십시오.
- 과도한 수의 가상 CPU가 성능에 부정적인 영향을 미칠 수 있습니다. 논리 프로세서가 LPAR에 정의되어 있는 것보다 더 많은 가상 프로세서를 게스트에 정의하지 마십시오.
- 더 이상 사용하지 않는 최대 워크로드에 대해 게스트당 가상 프로세서 수를 구성합니다.
- 작게 시작하고 워크로드를 모니터링합니다. 필요한 경우 vCPU 수를 증분적으로 늘립니다.
- 모든 워크로드가 높은 과다 할당 비율에 적합한 것은 아닙니다. 워크로드가 CPU 집약적인 경우 성능 문제 없이 높은 비율을 달성할 수 없습니다. I/O 집약적인 워크로드는 초과 커밋이 높은 경우에도 일관된 성능을 유지할 수 있습니다.
5.2. Transparent Huge Pages 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
THP(Transparent Huge Pages)는 대규모 페이지를 생성, 관리 및 사용하는 대부분의 측면을 자동화합니다. THP는 대규모 페이지를 자동으로 관리하므로 모든 유형의 워크로드에 대해 항상 최적으로 처리되는 것은 아닙니다. THP는 많은 애플리케이션이 자체적으로 대규모 페이지를 처리하기 때문에 성능 회귀 문제가 발생할 수 있습니다. 따라서 THP를 비활성화하는 것이 좋습니다.
5.3. Receive Flow stering으로 네트워킹 성능 향상 링크 복사링크가 클립보드에 복사되었습니다!
수신 흐름 스테이저링(RFS)은 네트워크 대기 시간을 추가로 줄임으로써 Receive Packet stering(RPS)을 확장합니다. RFS는 기술적으로 RPS를 기반으로 하며, CPU 캐시 적중률을 증가시켜 패킷 처리의 효율성을 향상시킵니다. RFS는 이를 달성하며, 또한 CPU 내에서 캐시 적중이 발생할 가능성이 높아지도록 계산에 가장 편리한 CPU를 결정함으로써 큐 길이를 고려합니다. 따라서 CPU 캐시가 덜 무효화되어 캐시를 다시 빌드하려면 주기가 감소합니다. 이렇게 하면 패킷 처리 시간을 줄일 수 있습니다.
5.3.1. MCO(Machine Config Operator)를 사용하여 RFS를 활성화합니다. 링크 복사링크가 클립보드에 복사되었습니다!
절차
다음 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 50-enable-rfs라는 항목이 나열되었는지 확인합니다.oc get mc
$ oc get mcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 비활성화하려면 다음을 입력합니다.
oc delete mc 50-enable-rfs
$ oc delete mc 50-enable-rfsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.4. 네트워킹 설정 선택 링크 복사링크가 클립보드에 복사되었습니다!
네트워킹 스택은 OpenShift Container Platform과 같은 Kubernetes 기반 제품의 가장 중요한 구성 요소 중 하나입니다. IBM Z 설정의 경우 네트워킹 설정은 선택한 하이퍼바이저에 따라 다릅니다. 워크로드 및 애플리케이션에 따라 가장 적합한 것이 일반적으로 사용 사례 및 트래픽 패턴에 따라 변경됩니다.
설정에 따라 다음 모범 사례를 고려하십시오.
- 트래픽 패턴을 최적화하기 위해 네트워킹 장치와 관련된 모든 옵션을 고려하십시오. OSA-Express, RoCE Express, HiperSockets, z/VM VSwitch, Linux Bridge(KVM)의 장점을 살펴보고, 다른 옵션으로 인해 설정에 가장 큰 이점을 얻을 수 있습니다.
- 항상 사용 가능한 최신 NIC 버전을 사용하십시오. 예를 들어 OSA Express 7S 10GbE는 10GbE 어댑터인 OSA Express 6S 10GbE와 트랜잭션 워크로드 유형의 GbE와 비교하여 큰 개선을 나타냈습니다.
- 각 가상 스위치는 대기 시간의 추가 계층을 추가합니다.
- 로드 밸런서는 클러스터 외부의 네트워크 통신에 중요한 역할을 합니다. 애플리케이션에 중요한 경우 프로덕션 수준의 하드웨어 로드 밸런서를 사용하는 것이 좋습니다.
- OpenShift Container Platform SDN에는 네트워킹 성능에 영향을 주는 흐름과 규칙이 도입되었습니다. 통신이 중요한 서비스의 현지성을 활용하기 위해 포드의 영향 및 배치를 고려해야 합니다.
- 성능과 기능 간의 균형을 조정합니다.
5.5. z/VM의 HyperPAV로 높은 디스크 성능 보장 링크 복사링크가 클립보드에 복사되었습니다!
DASD 및 ECKD 장치는 IBM Z 환경에서 일반적으로 사용되는 디스크 유형입니다. z/VM 환경의 일반적인 OpenShift Container Platform 설정에서 DASD 디스크는 일반적으로 노드의 로컬 스토리지를 지원하는 데 사용됩니다. HyperPAV 별칭 장치를 설정하여 z/VM 게스트를 지원하는 DASD 디스크에 대해 처리량과 전반적으로 향상된 I/O 성능을 제공할 수 있습니다.
로컬 스토리지 장치에 HyperPAV를 사용하면 성능에 큰 이점이 있습니다. 그러나 처리량과 CPU 비용 사이에 장단점이 있다는 점에 유의해야 합니다.
풀팩 미니disk를 사용하는 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc create -f 05-worker-kernelarg-hpav.yaml
$ oc create -f 05-worker-kernelarg-hpav.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 비활성화하려면 다음을 입력합니다.
oc delete -f 05-master-kernelarg-hpav.yaml
$ oc delete -f 05-master-kernelarg-hpav.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete -f 05-worker-kernelarg-hpav.yaml
$ oc delete -f 05-worker-kernelarg-hpav.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6. IBM Z 호스트의 RHEL KVM 권장 사항 링크 복사링크가 클립보드에 복사되었습니다!
KVM 가상 서버 환경 최적화는 가상 서버 및 사용 가능한 리소스의 워크로드에 따라 크게 달라집니다. 한 환경에서 성능을 개선하는 것과 동일한 동작이 다른 환경에서 불리한 영향을 미칠 수 있습니다. 특정 설정에 가장 적합한 균형을 찾는 것은 문제가 될 수 있으며 종종 실험이 포함됩니다.
다음 섹션에서는 IBM Z 및 IBM® LinuxONE 환경에서 RHEL KVM과 함께 OpenShift Container Platform을 사용할 때 몇 가지 모범 사례를 소개합니다.
5.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 스레드를 실행 중인 가상 서버에 추가할 수 있습니다.
5.6.2. 가상 SCSI 장치 방지 링크 복사링크가 클립보드에 복사되었습니다!
SCSI별 인터페이스를 통해 장치를 해결해야 하는 경우에만 가상 SCSI 장치를 구성합니다. 호스트에서 백업에 관계없이 가상 SCSI 장치가 아닌 가상 블록 장치로 디스크 공간을 구성합니다.
그러나 다음을 위해 SCSI 특정 인터페이스가 필요할 수 있습니다.
- 호스트의 SCSI 연결 video drive용 LUN입니다.
- 가상 DVD 드라이브에 마운트된 호스트 파일 시스템의 DVD ISO 파일입니다.
5.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>
5.6.4. 메모리 balloon 장치 제외 링크 복사링크가 클립보드에 복사되었습니다!
동적 메모리 크기가 필요하지 않은 경우 메모리 balloon 장치를 정의하지 말고 libvirt가 사용자를 위해 생성되지 않도록 합니다. 도메인 구성 XML 파일에 devices 요소의 하위 항목으로 memballoon 매개 변수를 포함합니다.
활성 프로필 목록을 확인합니다.
<memballoon model="none"/>
<memballoon model="none"/>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
5.6.5. 호스트 스케줄러의 CPU 마이그레이션 알고리즘 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
영향을 이해하는 전문가가 아닌 경우 스케줄러 설정을 변경하지 마십시오. 테스트하지 않고 프로덕션 시스템에 변경 사항을 적용하지 말고 의도된 효과가 있는지 확인합니다.
kernel.sched_migration_cost_ns 매개변수는 나노초 단위를 지정합니다. 작업을 마지막으로 실행한 후 CPU 캐시는 이 간격이 만료될 때까지 유용한 콘텐츠를 갖는 것으로 간주됩니다. 이 간격을 늘리면 작업 마이그레이션 횟수가 줄어듭니다. 기본값은 500000 ns입니다.
실행 가능한 프로세스가 있을 때 CPU 유휴 시간이 예상보다 높은 경우 이 간격을 줄입니다. CPU 또는 노드 간에 작업이 너무 자주 부과되는 경우 해당 작업을 늘립니다.
간격을 60000 ns로 동적으로 설정하려면 다음 명령을 입력합니다.
sysctl kernel.sched_migration_cost_ns=60000
# sysctl kernel.sched_migration_cost_ns=60000
값을 60000 ns로 영구적으로 변경하려면 다음 항목을 /etc/sysctl.conf 에 추가합니다.
kernel.sched_migration_cost_ns=60000
kernel.sched_migration_cost_ns=60000
5.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 libvirtdCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 가상 머신을 재시작합니다.
이 설정은 호스트 재부팅 시 유지됩니다.
5.6.7. 유휴 가상 CPU의 폴링 기간 조정 링크 복사링크가 클립보드에 복사되었습니다!
가상 CPU가 유휴 상태가 되면 KVM은 호스트 리소스를 할당하기 전에 가상 CPU에 대한 정지 조건을 폴링합니다. /sys/module/kvm/parameters/halt_poll_ns 의 sysfs에서 폴링하는 시간 간격을 지정할 수 있습니다. 지정된 시간 동안 폴링을 사용하면 리소스 사용량을 소비하여 가상 CPU의 정지 대기 시간을 줄일 수 있습니다. 워크로드에 따라 폴링 시간이 길거나 짧아질 수 있습니다. 시간 간격은 나노초로 지정됩니다. 기본값은 50000 ns입니다.
낮은 CPU 사용을 최적화하려면 작은 값을 입력하거나 0을 작성하여 폴링을 비활성화합니다.
echo 0 > /sys/module/kvm/parameters/halt_poll_ns
# echo 0 > /sys/module/kvm/parameters/halt_poll_nsCopy 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_nsCopy to Clipboard Copied! Toggle word wrap Toggle overflow
6장. Node Tuning Operator 사용 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator에 대해 알아보고, Node Tuning Operator를 사용하여 Tuned 데몬을 오케스트레이션하고 노드 수준 튜닝을 관리하는 방법도 알아봅니다.
6.1. Node Tuning Operator 정보 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator는 TuneD 데몬을 오케스트레이션하여 노드 수준 튜닝을 관리하고 Performance Profile 컨트롤러를 사용하여 짧은 대기 시간 성능을 달성하는 데 도움이 됩니다. 대부분의 고성능 애플리케이션에는 일정 수준의 커널 튜닝이 필요합니다. Node Tuning Operator는 노드 수준 sysctls 사용자에게 통합 관리 인터페이스를 제공하며 사용자의 필요에 따라 지정되는 사용자 정의 튜닝을 추가할 수 있는 유연성을 제공합니다.
Operator는 OpenShift Container Platform의 컨테이너화된 TuneD 데몬을 Kubernetes 데몬 세트로 관리합니다. 클러스터에서 실행되는 모든 컨테이너화된 TuneD 데몬에 사용자 정의 튜닝 사양이 데몬이 이해할 수 있는 형식으로 전달되도록 합니다. 데몬은 클러스터의 모든 노드에서 노드당 하나씩 실행됩니다.
컨테이너화된 TuneD 데몬을 통해 적용되는 노드 수준 설정은 프로필 변경을 트리거하는 이벤트 시 또는 컨테이너화된 TuneD 데몬이 종료 신호를 수신하고 처리하여 정상적으로 종료될 때 롤백됩니다.
Node Tuning Operator는 Performance Profile 컨트롤러를 사용하여 자동 튜닝을 구현하여 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능을 실현합니다. 클러스터 관리자는 다음과 같은 노드 수준 설정을 정의하도록 성능 프로필을 구성합니다.
- 커널을 kernel-rt로 업데이트
- 하우스키핑을 위해 CPU를 선택합니다.
- 워크로드 실행을 위한 CPU 선택.
현재 cgroup v2에서는 CPU 부하 분산을 비활성화하지 않습니다. 따라서 cgroup v2가 활성화된 경우 성능 프로필에서 원하는 동작을 얻지 못할 수 있습니다. 성능 프로필을 사용하는 경우에는 cgroup v2를 활성화하는 것은 권장되지 않습니다.
버전 4.1 이상에서는 Node Tuning Operator가 표준 OpenShift Container Platform 설치에 포함되어 있습니다.
이전 버전의 OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다.
6.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-operatorCopy 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 라벨이 일치된 상태로 사용자 정의 프로필이 생성되면 해당 시점에 이 기능이 활성화됩니다. Pod 라벨 기능은 Node Tuning Operator의 향후 버전에서 더 이상 사용되지 않습니다.
6.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 ^ {} \;
6.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 개체 생성 이후 경과 시간입니다.
6.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 데몬의 디버깅을 켜거나 비활성화합니다. off의 경우 on 또는
false의 경우 옵션이true입니다. 기본값은false입니다. - 9
- TuneD 데몬에 대해
reapply_sysctl기능을 켜거나 off합니다. off의 경우 on 및false의 경우 옵션이true입니다.
<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 피연산자가 동일한 머신 구성 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.
예: 노드 또는 Pod 라벨 기반 일치
위의 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> 형식의 노드 오브젝트 값을 사용하고 NTO 피연산자 컨테이너에서 < spec.provider IDcloud-provider> 값으로 파일을 씁니다. 그런 다음 TuneD에서 해당 프로필이 있는 경우 provider-< /var/lib/tuned/provider cloud-provider > 프로필을 로드하는 데 이 파일의 콘텐츠를 사용합니다.
및 openshift -control-planeopenshift-node 프로필 모두의 설정을 상속하는 openshift 프로필은 조건부 프로필 로드를 사용하여 이 기능을 사용하도록 업데이트되었습니다. NTO와 TuneD는 현재 클라우드 공급자별 프로필을 제공하지 않습니다. 그러나 모든 클라우드 공급자별 클러스터 노드에 적용할 사용자 지정 프로필 provider-<cloud- provider>를 생성할 수 있습니다.
GCE 클라우드 공급자 프로필의 예
프로필 상속으로 인해 provider-< cloud-provider > 프로필에 지정된 모든 설정은 openshift 프로필 및 해당 하위 프로필에서 덮어씁니다.
6.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별 튜닝을 사용합니다.
6.7. 지원되는 TuneD 데몬 플러그인 링크 복사링크가 클립보드에 복사되었습니다!
Tuned CR의 profile: 섹션에 정의된 사용자 정의 프로필을 사용하는 경우 [main] 섹션을 제외한 다음 TuneD 플러그인이 지원됩니다.
- audio
- cpu
- disk
- eeepc_she
- modules
- mounts
- net
- scheduler
- scsi_host
- selinux
- sysctl
- sysfs
- usb
- video
- vm
- bootloader
일부 플러그인에서 제공하는 동적 튜닝 기능은 지원되지 않습니다. 다음 TuneD 플러그인은 현재 지원되지 않습니다.
- script
- systemd
TuneD 부트로더 플러그인은 RHCOS(Red Hat Enterprise Linux CoreOS) 작업자 노드만 지원합니다.
추가 리소스
6.8. 호스팅된 클러스터에서 노드 튜닝 구성 링크 복사링크가 클립보드에 복사되었습니다!
호스트 컨트롤 플레인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
호스팅된 클러스터의 노드에 노드 수준 튜닝을 설정하려면 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섹션에 있는 항목에 레이블을 추가하지 않으면 노드 풀 기반 일치로 가정하므로spec.recommend섹션의 우선 순위 프로필이 풀의 노드에 적용됩니다. Tuned.spec.recommend.match섹션에서 레이블 값을 설정하여 더 세분화된 node-label-based 일치를 수행할 수 있지만 노드 풀의.spec.management.upgradeType값을InPlace로 설정하지 않으면 업그레이드 중에 노드 라벨이 유지되지 않습니다.관리 클러스터에
ConfigMap오브젝트를 생성합니다.oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yamlCopy 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-operatorCopy 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 65sCopy 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-operatorCopy 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 7m14sCopy 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_ratioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
vm.dirty_ratio = 55
vm.dirty_ratio = 55Copy to Clipboard Copied! Toggle word wrap Toggle overflow
6.9. 커널 부팅 매개변수를 설정하여 호스팅 클러스터의 고급 노드 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
호스트 컨트롤 플레인은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
커널 부팅 매개변수를 설정해야 하는 호스팅 컨트롤 플레인의 고급 튜닝을 위해 Node Tuning Operator를 사용할 수도 있습니다. 다음 예제에서는 대규모 페이지가 예약된 노드 풀을 생성하는 방법을 보여줍니다.
프로세스
크기가 2MB인 10개의 대규모 페이지를 생성하기 위한
Tuned오브젝트 매니페스트가 포함된ConfigMap오브젝트를 생성합니다.tuned-hugepages.yaml이라는 파일에 이ConfigMap매니페스트를 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고.spec.recommend.match필드는 의도적으로 비어 있습니다. 이 경우 이Tuned오브젝트는 이ConfigMap오브젝트가 참조되는 노드 풀의 모든 노드에 적용됩니다. 동일한 하드웨어 구성을 가진 노드를 동일한 노드 풀로 그룹화합니다. 그렇지 않으면 TuneD 피연산자가 동일한 노드 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.관리 클러스터에
ConfigMap오브젝트를 생성합니다.oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-hugepages.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-hugepages.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow NodePool매니페스트 YAML 파일을 생성하고NodePool의 업그레이드 유형을 사용자 지정하고spec.tuningConfig섹션에서 생성한ConfigMap오브젝트를 참조합니다.NodePool매니페스트를 생성하고hypershiftCLI를 사용하여hugepages-nodepool.yaml이라는 파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow hugepages-nodepool.yaml파일에서.spec.management.upgradeType을InPlace.Place.spec.tuningConfig로 설정하고 생성한tuned-hugepagesConfigMap오브젝트를 참조하도록 .spec.tuningConfig를 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고새
MachineConfig개체를 적용할 때 노드의 불필요한 재생성을 방지하려면.spec.management.upgradeType을InPlace로 설정합니다.Replace업그레이드 유형을 사용하는 경우 TuneD 피연산자가 계산된 새 커널 부팅 매개변수를 적용하면 노드가 완전히 삭제되고 새 노드가 교체될 수 있습니다.관리 클러스터에
NodePool을 생성합니다.oc --kubeconfig="$MGMT_KUBECONFIG" create -f hugepages-nodepool.yaml
$ oc --kubeconfig="$MGMT_KUBECONFIG" create -f hugepages-nodepool.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
노드를 사용할 수 있게 되면 컨테이너화된 TuneD 데몬은 적용된 TuneD 프로필을 기반으로 필요한 커널 부팅 매개변수를 계산합니다. 노드가 준비되고 재부팅되면 생성된 MachineConfig 오브젝트를 적용한 후 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-operatorCopy 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 123mCopy 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-operatorCopy 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 3m57sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 새
NodePool의 두 작업자 노드에는openshift-node-hugepages프로필이 적용됩니다.튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고
/proc/cmdline을 확인합니다.oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
$ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdlineCopy 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=50Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7장. CPU 관리자 및 토폴로지 관리자 사용 링크 복사링크가 클립보드에 복사되었습니다!
CPU 관리자는 CPU 그룹을 관리하고 워크로드를 특정 CPU로 제한합니다.
CPU 관리자는 다음과 같은 속성 중 일부가 포함된 워크로드에 유용합니다.
- 가능한 한 많은 CPU 시간이 필요합니다.
- 프로세서 캐시 누락에 민감합니다.
- 대기 시간이 짧은 네트워크 애플리케이션입니다.
- 다른 프로세스와 조정하고 단일 프로세서 캐시 공유를 통해 얻는 이점이 있습니다.
토폴로지 관리자는 동일한 NUMA(Non-Uniform Memory Access) 노드의 모든 QoS(Quality of Service) 클래스에 대해 CPU 관리자, 장치 관리자, 기타 힌트 공급자로부터 힌트를 수집하여 CPU, SR-IOV VF, 기타 장치 리소스 등의 Pod 리소스를 정렬합니다.
토폴로지 관리자는 토폴로지 관리자 정책 및 요청된 Pod 리소스를 기반으로 수집된 팁의 토폴로지 정보를 사용하여 노드에서 Pod를 수락하거나 거부할 수 있는지 결정합니다.
토폴로지 관리자는 하드웨어 가속기를 사용하여 대기 시간이 중요한 실행과 처리량이 높은 병렬 계산을 지원하는 워크로드에 유용합니다.
토폴로지 관리자를 사용하려면 정적 정책을 사용하여 CPU 관리자를 구성해야 합니다.
7.1. CPU 관리자 설정 링크 복사링크가 클립보드에 복사되었습니다!
프로세스
선택사항: 노드에 레이블을 지정합니다.
oc label node perf-node.example.com cpumanager=true
# oc label node perf-node.example.com cpumanager=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow CPU 관리자를 활성화해야 하는 노드의
MachineConfigPool을 편집합니다. 이 예에서는 모든 작업자의 CPU 관리자가 활성화됩니다.oc edit machineconfigpool worker
# oc edit machineconfigpool workerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 작업자 머신 구성 풀에 레이블을 추가합니다.
metadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabledmetadata: creationTimestamp: 2020-xx-xxx generation: 3 labels: custom-kubelet: cpumanager-enabledCopy 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.yamlCopy 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 -A7Copy 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 cpuManagerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
cpuManagerPolicy: static cpuManagerReconcilePeriod: 5s
cpuManagerPolicy: static1 cpuManagerReconcilePeriod: 5s2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다.
cat cpumanager-pod.yaml
# cat cpumanager-pod.yamlCopy 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 레이블 지정한 노드에 Pod가 예약되어 있는지 검증합니다.
oc describe pod cpumanager
# oc describe pod cpumanagerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow cgroups가 올바르게 설정되었는지 검증합니다.pause프로세스의 PID(프로세스 ID)를 가져옵니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow QoS(Quality of Service) 계층
Guaranteed의 Pod는kubepods.slice에 있습니다. 다른 QoS 계층의 Pod는kubepods의 하위cgroups에 있습니다.cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done
# cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
cpuset.cpus 1 tasks 32706
cpuset.cpus 1 tasks 32706Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업에 허용되는 CPU 목록을 확인합니다.
grep ^Cpus_allowed_list /proc/32706/status
# grep ^Cpus_allowed_list /proc/32706/statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Cpus_allowed_list: 1
Cpus_allowed_list: 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow GuaranteedPod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우burstableQoS 계층의 Pod)를 실행할 수 없는지 검증합니다.cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus 0 oc describe node perf-node.example.com
# cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus 0 # oc describe node perf-node.example.comCopy 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 11sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
7.2. 토폴로지 관리자 정책 링크 복사링크가 클립보드에 복사되었습니다!
토폴로지 관리자는 CPU 관리자 및 장치 관리자와 같은 힌트 공급자로부터 토폴로지 힌트를 수집하고 수집된 힌트로 Pod 리소스를 정렬하는 방법으로 모든 QoS(Quality of Service) 클래스의 Pod 리소스를 정렬합니다.
토폴로지 관리자는 cpumanager-enabled 라는 KubeletConfig CR(사용자 정의 리소스)에서 할당하는 네 가지 할당 정책을 지원합니다.
none정책- 기본 정책으로, 토폴로지 정렬을 수행하지 않습니다.
best-effort정책-
best-effort토폴로지 관리 정책을 사용하는 Pod의 각 컨테이너에서는 kubelet이 각 힌트 공급자를 호출하여 해당 리소스 가용성을 검색합니다. 토폴로지 관리자는 이 정보를 사용하여 해당 컨테이너의 기본 NUMA 노드 선호도를 저장합니다. 선호도를 기본 설정하지 않으면 토폴로지 관리자가 해당 정보를 저장하고 노드에 대해 Pod를 허용합니다. restricted정책-
restricted토폴로지 관리 정책을 사용하는 Pod의 각 컨테이너에서는 kubelet이 각 힌트 공급자를 호출하여 해당 리소스 가용성을 검색합니다. 토폴로지 관리자는 이 정보를 사용하여 해당 컨테이너의 기본 NUMA 노드 선호도를 저장합니다. 선호도를 기본 설정하지 않으면 토폴로지 관리자가 노드에서 이 Pod를 거부합니다. 그러면 Pod는Terminated상태가 되고 Pod 허용 실패가 발생합니다. single-numa-node정책-
single-numa-node토폴로지 관리 정책을 사용하는 Pod의 각 컨테이너에서는 kubelet이 각 힌트 공급자를 호출하여 해당 리소스 가용성을 검색합니다. 토폴로지 관리자는 이 정보를 사용하여 단일 NUMA 노드 선호도가 가능한지 여부를 결정합니다. 가능한 경우 노드에 대해 Pod가 허용됩니다. 단일 NUMA 노드 선호도가 가능하지 않은 경우 토폴로지 관리자가 노드에서 Pod를 거부합니다. 그러면 Pod는 Terminated 상태가 되고 Pod 허용 실패가 발생합니다.
7.3. 토폴로지 관리자 설정 링크 복사링크가 클립보드에 복사되었습니다!
토폴로지 관리자를 사용하려면 cpumanager-enabled 라는 KubeletConfig CR(사용자 정의 리소스)에서 할당 정책을 구성해야 합니다. CPU 관리자를 설정한 경우 해당 파일이 존재할 수 있습니다. 파일이 없으면 파일을 생성할 수 있습니다.
사전 요구 사항
-
CPU 관리자 정책을
static으로 구성하십시오.
절차
토폴로지 관리자를 활성화하려면 다음을 수행합니다.
사용자 정의 리소스에서 토폴로지 관리자 할당 정책을 구성합니다.
oc edit KubeletConfig cpumanager-enabled
$ oc edit KubeletConfig cpumanager-enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow Copy to Clipboard Copied! Toggle word wrap Toggle overflow
7.4. Pod와 토폴로지 관리자 정책 간의 상호 작용 링크 복사링크가 클립보드에 복사되었습니다!
아래 Pod 사양의 예는 Pod와 토폴로지 관리자 간 상호 작용을 보여주는 데 도움이 됩니다.
다음 Pod는 리소스 요청 또는 제한이 지정되어 있지 않기 때문에 BestEffort QoS 클래스에서 실행됩니다.
spec:
containers:
- name: nginx
image: nginx
spec:
containers:
- name: nginx
image: nginx
다음 Pod는 요청이 제한보다 작기 때문에 Burstable QoS 클래스에서 실행됩니다.
선택한 정책이 none이 아니면 토폴로지 관리자는 이러한 Pod 사양 중 하나를 고려하지 않습니다.
아래 마지막 예의 Pod는 요청이 제한과 동일하기 때문에 Guaranteed QoS 클래스에서 실행됩니다.
토폴로지 관리자는 이러한 Pod를 고려합니다. 토폴로지 관리자는 포드에 대한 토폴로지 힌트 힌트를 얻으려면 CPU 관리자 및 장치 관리자인 힌트 공급자를 참조합니다.
토폴로지 관리자는 이 정보를 사용하여 이 컨테이너에 가장 적합한 토폴로지를 저장합니다. 이 Pod의 경우 CPU 관리자와 장치 관리자는 리소스 할당 단계에서 이러한 저장된 정보를 사용합니다.
8장. NUMA 인식 워크로드 예약 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 스케줄링과 이를 사용하여 OpenShift Container Platform 클러스터에서 고성능 워크로드를 배포하는 방법에 대해 알아보십시오.
NUMA 인식 스케줄링은 OpenShift Container Platform 버전 4.12.0에서 4.12.23까지의 기술 프리뷰 기능입니다. 일반적으로 OpenShift Container Platform 버전 4.12.24 이상에서 사용할 수 있습니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
NUMA 리소스 Operator를 사용하면 동일한 NUMA 영역에 고성능 워크로드를 예약할 수 있습니다. 사용 가능한 클러스터 노드 NUMA 리소스에 보고하는 노드 리소스 내보내기 에이전트와 워크로드를 관리하는 보조 스케줄러를 배포합니다.
8.1. NUMA 인식 스케줄링 정보 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 소개
NUMA(Non-Uniform Memory Access)는 다른 CPU가 다른 속도로 다양한 메모리에 액세스할 수 있도록 하는 컴퓨팅 플랫폼 아키텍처입니다. NUMA 리소스 토폴로지는 계산 노드에서 서로 상대적 CPU, 메모리 및 PCI 장치의 위치를 나타냅니다. 배치된 리소스는 동일한 NUMA 영역에 있다고 합니다. 고성능 애플리케이션의 경우 클러스터는 단일 NUMA 영역에서 Pod 워크로드를 처리해야 합니다.
성능 고려 사항
NUMA 아키텍처를 사용하면 여러 메모리 컨트롤러가 있는 CPU는 메모리가 있는 위치와 관계없이 CPU 복잡성에서 사용 가능한 메모리를 사용할 수 있습니다. 이렇게 하면 성능이 저하될 때 유연성이 향상됩니다. NUMA 영역 외부에 있는 메모리를 사용하여 워크로드를 처리하는 CPU는 단일 NUMA 영역에서 처리된 워크로드보다 속도가 느립니다. 또한 I/O-constrained 워크로드의 경우 멀리 있는 NUMA 영역의 네트워크 인터페이스가 애플리케이션에 도달하는 속도가 얼마나 빠르게 느려집니다. 통신 워크로드와 같은 고성능 워크로드는 이러한 조건에서 사양으로 작동할 수 없습니다.
NUMA 인식 스케줄링
NUMA 인식 스케줄링은 지연에 민감한 또는 고성능 워크로드를 효율적으로 처리하기 위해 동일한 NUMA 영역의 요청된 클러스터 컴퓨팅 리소스(CPU, 메모리, 장치)를 조정합니다. NUMA 인식 스케줄링은 리소스 효율성을 높이기 위해 컴퓨팅 노드당 Pod 밀도도 향상시킵니다.
Node Tuning Operator와의 통합
Node Tuning Operator의 성능 프로필을 NUMA 인식 스케줄링과 통합하면 대기 시간에 민감한 워크로드에 대한 성능을 최적화하도록 CPU 선호도를 추가로 구성할 수 있습니다.
기본 스케줄링 논리
기본 OpenShift Container Platform Pod 스케줄러 스케줄링 논리는 개별 NUMA 영역이 아닌 전체 컴퓨팅 노드의 사용 가능한 리소스를 고려합니다. kubelet 토폴로지 관리자에서 가장 제한적인 리소스 정렬을 요청하는 경우 노드에 Pod를 허용할 때 오류 조건이 발생할 수 있습니다. 반대로 가장 제한적인 리소스 정렬을 요청하지 않으면 Pod를 적절한 리소스 정렬 없이 노드에 허용하여 성능이 저하되거나 예측할 수 없는 성능이 저하될 수 있습니다. 예를 들어 Pod 스케줄러에서 Pod의 요청된 리소스를 사용할 수 있는지 확인하지 않고 보장된 Pod 워크로드에 대한 하위 스케줄링 결정을 내릴 때 Topology Affinity Error 를 사용한 runaway Pod 생성이 발생할 수 있습니다. 예약 불일치 결정으로 인해 Pod 시작 지연이 발생할 수 있습니다. 또한 클러스터 상태 및 리소스 할당에 따라 Pod 예약 결정이 실패한 시작 시도로 인해 클러스터에 추가 로드가 발생할 수 있습니다.
NUMA 인식 Pod 스케줄링 다이어그램
NUMA 리소스 Operator는 사용자 정의 NUMA 리소스 보조 스케줄러 및 기타 리소스를 배포하여 기본 OpenShift Container Platform Pod 스케줄러의 단점에 대해 완화합니다. 다음 다이어그램에서는 NUMA 인식 Pod 스케줄링에 대한 고급 개요를 제공합니다.
그림 8.1. NUMA 인식 스케줄링 개요
- NodeResourceTopology API
-
NodeResourceTopologyAPI는 각 컴퓨팅 노드에서 사용 가능한 NUMA 영역 리소스를 설명합니다. - NUMA 인식 스케줄러
-
NUMA 인식 보조 스케줄러는
NodeResourceTopologyAPI에서 사용 가능한 NUMA 영역에 대한 정보를 수신하고 최적으로 처리할 수 있는 노드에서 고성능 워크로드를 예약합니다. - 노드 토폴로지 내보내기
-
노드 토폴로지 내보내기자는 각 계산 노드에 대해 사용 가능한 NUMA 영역 리소스를
NodeResourceTopologyAPI에 노출합니다. 노드 토폴로지 내보내기 데몬은PodResourcesAPI를 사용하여 kubelet에서 리소스 할당을 추적합니다. - PodResources API
-
PodResourcesAPI는 각 노드의 로컬이며 리소스 토폴로지 및 사용 가능한 리소스를 kubelet에 노출합니다.
추가 리소스
- 클러스터에서 보조 Pod 스케줄러를 실행하는 방법 및 보조 Pod 스케줄러를 사용하여 Pod를 배포하는 방법에 대한 자세한 내용은 보조 스케줄러 를 사용하여 Pod 예약을 참조하십시오.
8.2. NUMA Resources Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 Operator는 NUMA 인식 워크로드 및 배포를 예약할 수 있는 리소스를 배포합니다. OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 NUMA 리소스 Operator를 설치할 수 있습니다.
8.2.1. CLI를 사용하여 NUMA 리소스 Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
NUMA Resources Operator의 네임스페이스를 생성합니다.
nro-namespace.yaml파일에 다음 YAML을 저장합니다.apiVersion: v1 kind: Namespace metadata: name: openshift-numaresources
apiVersion: v1 kind: Namespace metadata: name: openshift-numaresourcesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NamespaceCR을 생성합니다.oc create -f nro-namespace.yaml
$ oc create -f nro-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NUMA 리소스 Operator의 Operator 그룹을 생성합니다.
다음 YAML을
nro-operatorgroup.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
OperatorGroupCR을 생성합니다.oc create -f nro-operatorgroup.yaml
$ oc create -f nro-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NUMA 리소스 Operator에 대한 서브스크립션을 생성합니다.
다음 YAML을
nro-sub.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SubscriptionCR을 생성합니다.oc create -f nro-sub.yaml
$ oc create -f nro-sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
openshift-numaresources네임스페이스에서 CSV 리소스를 검사하여 설치에 성공했는지 확인합니다. 다음 명령을 실행합니다.oc get csv -n openshift-numaresources
$ oc get csv -n openshift-numaresourcesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME DISPLAY VERSION REPLACES PHASE numaresources-operator.v4.12.2 numaresources-operator 4.12.2 Succeeded
NAME DISPLAY VERSION REPLACES PHASE numaresources-operator.v4.12.2 numaresources-operator 4.12.2 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.2. 웹 콘솔을 사용하여 NUMA Resources Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 웹 콘솔을 사용하여 NUMA Resources Operator를 설치할 수 있습니다.
절차
NUMA Resources Operator의 네임스페이스를 생성합니다.
- OpenShift Container Platform 웹 콘솔에서 관리 → 네임스페이스를 클릭합니다.
-
네임스페이스 생성을 클릭하고 이름 필드에
openshift-numaresources를 입력한 다음 생성 을 클릭합니다.
NUMA Resources Operator를 설치합니다.
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 numaresources-operator 를 선택한 다음 설치를 클릭합니다.
-
설치된 네임스페이스 필드에서
openshift-numaresources네임스페이스를 선택한 다음 설치를 클릭합니다.
선택 사항: NUMA 리소스 Operator가 설치되었는지 확인합니다.
- Operator → 설치된 Operator 페이지로 전환합니다.
NUMA Resources Operator 가
openshift-numaresources네임스페이스에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.참고설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
-
워크로드 → Pod 페이지로 이동하여
기본프로젝트에서 Pod 로그를 확인합니다.
8.3. NUMA 인식 워크로드 예약 링크 복사링크가 클립보드에 복사되었습니다!
대기 시간에 민감한 워크로드를 실행하는 클러스터는 일반적으로 워크로드 대기 시간을 최소화하고 성능을 최적화하는 데 도움이 되는 성능 프로필을 제공합니다. NUMA 인식 스케줄러는 노드에 적용된 성능 프로필 설정과 관련하여 사용 가능한 노드 NUMA 리소스를 기반으로 워크로드를 배포합니다. NUMA 인식 배포와 워크로드의 성능 프로파일이 조합되면 성능을 극대화하는 방식으로 워크로드가 예약됩니다.
NUMA Resources Operator가 완전히 작동하려면 NUMAResourcesOperator 사용자 정의 리소스 및 NUMA 인식 보조 Pod 스케줄러를 배포해야 합니다.
8.3.1. NUMAResourcesOperator 사용자 정의 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 Operator를 설치한 경우 데몬 세트 및 API를 포함하여 NUMA 인식 스케줄러를 지원하는 데 필요한 모든 클러스터 인프라를 설치하도록 NUMA 리소스 Operator에 지시하는 NUMAResourcesOperator CR(사용자 정의 리소스)을 생성합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다. - NUMA 리소스 Operator를 설치합니다.
절차
작업자 노드에 대한 사용자 정의 kubelet 구성을 활성화하는
MachineConfigPool사용자 정의 리소스를 생성합니다.다음 YAML을
nro-machineconfig.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
MachineConfigPoolCR을 생성합니다.oc create -f nro-machineconfig.yaml
$ oc create -f nro-machineconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
NUMAResourcesOperator사용자 정의 리소스를 생성합니다.nrop.yaml로 다음과 같은 최소한의 필수 YAML 파일 예제를 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- NUMA Resources Operator를 구성하려는
MachineConfigPool과 일치해야 합니다. 예를 들어 통신 워크로드를 실행하는 데 예상되는 노드 집합을 지정하는worker-cnf라는MachineConfigPool을 생성할 수 있습니다.
다음 명령을 실행하여
NUMAResourcesOperatorCR을 생성합니다.oc create -f nrop.yaml
$ oc create -f nrop.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고NUMAResourcesOperator를 생성하면 해당 머신 구성 풀 및 영향을 받는 노드에서 재부팅이 트리거됩니다.
검증
다음 명령을 실행하여 NUMA Resources Operator가 성공적으로 배포되었는지 확인합니다.
oc get numaresourcesoperators.nodetopology.openshift.io
$ oc get numaresourcesoperators.nodetopology.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesoperator 27s
NAME AGE numaresourcesoperator 27sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 몇 분 후에 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인합니다.
oc get all -n openshift-numaresources
$ oc get all -n openshift-numaresourcesCopy 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 97sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.2. NUMA 인식 보조 Pod 스케줄러 배포 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 리소스 Operator를 설치한 후 다음을 수행하여 NUMA 인식 보조 Pod 스케줄러를 배포합니다.
절차
-
머신 프로필에 대한 Pod 허용 정책을 구성하는
KubeletConfig사용자 정의 리소스를 생성합니다. NUMA 인식 사용자 정의 Pod 스케줄러를 배포하는
NUMAResourcesScheduler사용자 정의 리소스를 생성합니다.nro-scheduler.yaml파일에 필요한 다음 최소 YAML을 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NUMAResourcesSchedulerCR을 생성합니다.oc create -f nro-scheduler.yaml
$ oc create -f nro-scheduler.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
몇 초 후에 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인합니다.
oc get all -n openshift-numaresources
$ oc get all -n openshift-numaresourcesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.3.3. 단일 NUMA 노드 정책 구성 링크 복사링크가 클립보드에 복사되었습니다!
NUMA Resources Operator는 클러스터에 단일 NUMA 노드 정책을 구성해야 합니다. 성능 프로필을 생성 및 적용하거나 KubeletConfig를 구성하면 두 가지 방법으로 이 작업을 수행할 수 있습니다.
단일 NUMA 노드 정책을 구성하는 기본 방법은 성능 프로필을 적용하는 것입니다. PPC(Performance Profile Creator) 툴을 사용하여 성능 프로필을 생성할 수 있습니다. 클러스터에서 성능 프로필이 생성되면 KubeletConfig 및 tuned 프로필과 같은 다른 튜닝 구성 요소가 자동으로 생성됩니다.
성능 프로필 생성에 대한 자세한 내용은 "추가 리소스" 섹션의 "성능 프로필 Creator 정보"를 참조하십시오.
추가 리소스
8.3.4. 성능 프로파일의 예 링크 복사링크가 클립보드에 복사되었습니다!
이 예제 YAML은 PPC(Performance profile creator) 툴을 사용하여 생성된 성능 프로필을 보여줍니다.
8.3.5. KubeletConfig CRD 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 NUMA 노드 정책을 구성하는 권장 방법은 성능 프로필을 적용하는 것입니다. 또 다른 방법은 다음 절차에 표시된 대로 KubeletConfig CR(사용자 정의 리소스)을 생성하고 적용하는 것입니다.
절차
머신 프로필에 대한 Pod 승인 정책을 구성하는
KubeletConfigCR(사용자 정의 리소스)을 생성합니다.다음 YAML을
nro-kubeletconfig.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
KubeletConfigCR을 생성합니다.oc create -f nro-kubeletconfig.yaml
$ oc create -f nro-kubeletconfig.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고성능 프로필 또는
KubeletConfig를 적용하면 노드 재부팅이 자동으로 트리거됩니다. 재부팅이 트리거되지 않은 경우 노드 그룹을 처리하는KubeletConfig의 레이블을 확인하여 문제를 해결할 수 있습니다.
8.3.6. 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라는 스케줄러를 사용하는DeploymentCR을 생성합니다. 예를 들면 다음과 같습니다.다음 YAML을
nro-deployment.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
schedulerName은 클러스터에 배포된 NUMA 인식 스케줄러의 이름과 일치해야 합니다(예:topo-aware-scheduler).
다음 명령을 실행하여
DeploymentCR을 생성합니다.oc create -f nro-deployment.yaml
$ oc create -f nro-deployment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
배포에 성공했는지 확인합니다.
oc get pods -n openshift-numaresources
$ oc get pods -n openshift-numaresourcesCopy 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-numaresourcesCopy 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-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약할 수 있는 것보다 더 많은 리소스를 요청하는 배포는
MinimumReplicasUnavailable오류로 실패합니다. 필요한 리소스를 사용할 수 있게 되면 배포가 성공합니다. 필요한 리소스를 사용할 수 있을 때까지 Pod는Pending상태로 유지됩니다.예상 할당된 리소스가 노드에 나열되어 있는지 확인합니다.
다음 명령을 실행하여 배포 Pod를 실행 중인 노드를 식별합니다.
oc get pods -n openshift-numaresources -o wide
$ oc get pods -n openshift-numaresources -o wideCopy 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 배포 Pod를 실행 중인 해당 노드의 이름으로 다음 명령을 실행합니다.
oc describe noderesourcetopologies.topology.node.k8s.io worker-1
$ oc describe noderesourcetopologies.topology.node.k8s.io worker-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 보장된 Pod에 할당된 리소스로 인해
사용 가능한용량이 줄어듭니다.
보장된 Pod에서 사용하는 리소스는
noderesourcetopologies.topology.node.k8s.io아래에 나열된 사용 가능한 노드 리소스에서 제거됩니다.
Best-effort또는Burstable서비스 품질(qosClass)이 있는 Pod에 대한 리소스 할당은noderesourcetopologies.topology.node.k8s.io의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 소비 리소스가 노드 리소스 계산에 반영되지 않는 경우 다음 명령을 실행하여 Pod에GuaranteedqosClass가 있는지 확인합니다.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
GuaranteedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.4. 선택 사항: NUMA 리소스 업데이트를 위한 폴링 작업 구성 링크 복사링크가 클립보드에 복사되었습니다!
nodeGroup 의 NUMA Resources Operator에서 제어하는 데몬은 리소스를 폴링하여 사용 가능한 NUMA 리소스에 대한 업데이트를 검색합니다. NUMAResourcesOperator CR(사용자 정의 리소스)에서 spec.nodeGroups 사양을 구성하여 이러한 데몬에 대한 폴링 작업을 미세 조정할 수 있습니다. 이를 통해 폴링 작업에 대한 고급 제어가 제공됩니다. 스케줄링 동작을 개선하고 최적의 스케줄링 결정을 해결하기 위해 이러한 사양을 구성합니다.
구성 옵션은 다음과 같습니다.
-
infoRefreshMode: kubelet을 폴링하기 위한 트리거 조건을 결정합니다. NUMA Resources Operator는 결과 정보를 API 서버에 보고합니다. -
infoRefreshPeriod: 폴링 업데이트 사이의 기간을 결정합니다. podsFingerprinting: 노드에서 실행되는 현재 Pod 세트에 대한 지정 시간 정보가 폴링 업데이트에서 노출되는지 여부를 결정합니다.참고podsFingerprinting은 기본적으로 활성화되어 있습니다.podsFingerprinting은NUMAResourcesSchedulerCR의cacheResyncPeriod사양에 대한 요구 사항입니다.cacheResyncPeriod사양은 노드에서 보류 중인 리소스를 모니터링하여 보다 정확한 리소스 가용성을 보고하는 데 도움이 됩니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다. - NUMA 리소스 Operator를 설치합니다.
절차
NUMAResourcesOperatorCR에서spec.nodeGroups사양을 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 유효한 값은
Periodic,Events,periodicAndEvents입니다.Periodic을 사용하여infoRefreshPeriod에 정의된 간격으로 kubelet을 폴링합니다.이벤트를사용하여 모든 Pod 라이프사이클 이벤트에서 kubelet을 폴링합니다.PeriodicAndEvents를 사용하여 두 가지 방법을 모두 활성화합니다. - 2
Periodic또는PeriodicAndEvents새로 고침 모드의 폴링 간격을 정의합니다. 새로 고침 모드가Events인 경우 필드가 무시됩니다.- 3
- 유효한 값은
enabled,Disabled및EnabledExclusiveResources.NUMAResourcesScheduler의cacheResyncPeriod사양에 대한 요구 사항입니다.
검증
NUMA Resources Operator를 배포한 후 다음 명령을 실행하여 노드 그룹 구성이 적용되었는지 확인합니다.
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
8.5. NUMA 인식 스케줄링 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
NUMA 인식 Pod 예약과 관련된 일반적인 문제를 해결하려면 다음 단계를 수행합니다.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc)를 설치합니다. - cluster-admin 권한이 있는 사용자로 로그인합니다.
- NUMA 리소스 Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
절차
다음 명령을 실행하여
noderesourcetopologiesCRD가 클러스터에 배포되었는지 확인합니다.oc get crd | grep noderesourcetopologies
$ oc get crd | grep noderesourcetopologiesCopy 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:06ZCopy 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-schedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow NUMA 인식 가능 노드에
noderesourcetopologiesCR이 적용되는지 확인합니다. 다음 명령을 실행합니다.oc get noderesourcetopologies.topology.node.k8s.io
$ oc get noderesourcetopologies.topology.node.k8s.ioCopy 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 17hCopy 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 yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.1. 보다 정확한 리소스 가용성 보고 링크 복사링크가 클립보드에 복사되었습니다!
cacheResyncPeriod 사양을 활성화하여 노드에서 보류 중인 리소스를 모니터링하고 이 정보를 정의된 간격으로 스케줄러 캐시에서 동기화하여 NUMA 리소스 가용성을 보다 정확하게 보고할 수 있습니다. 또한 최적의 스케줄링 결정으로 인해 토폴로지 선호도 오류 오류를 최소화하는 데 도움이 됩니다. 간격이 낮으면 네트워크가 더 많이 로드됩니다. cacheResyncPeriod 사양은 기본적으로 비활성화되어 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
현재 실행 중인
NUMAResourcesScheduler리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler를 가져옵니다.oc get NUMAResourcesScheduler
$ oc get NUMAResourcesSchedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 92m
NAME AGE numaresourcesscheduler 92mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
oc delete NUMAResourcesScheduler numaresourcesscheduler
$ oc delete NUMAResourcesScheduler numaresourcesschedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
nro-scheduler-cacheresync.yaml파일에 다음 YAML을 저장합니다. 이 예제에서는 로그 수준을Debug로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 스케줄러 캐시의 동기화를 위해 간격 값을 초 단위로 입력합니다. 값
5s는 대부분의 구현에 일반적인 값입니다.
다음 명령을 실행하여 업데이트된
NUMAResourcesScheduler리소스를 만듭니다.oc create -f nro-scheduler-cacheresync.yaml
$ oc create -f nro-scheduler-cacheresync.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증 단계
NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.
oc get crd | grep numaresourcesschedulers
$ oc get crd | grep numaresourcesschedulersCopy 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:03ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
oc get numaresourcesschedulers.nodetopology.openshift.io
$ oc get numaresourcesschedulers.nodetopology.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 3h26m
NAME AGE numaresourcesscheduler 3h26mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.
다음 명령을 실행하여
openshift-numaresources네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.oc get pods -n openshift-numaresources
$ oc get pods -n openshift-numaresourcesCopy 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 21mCopy 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-numaresourcesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.2. NUMA 인식 스케줄러 로그 확인 링크 복사링크가 클립보드에 복사되었습니다!
로그를 검토하여 NUMA 인식 스케줄러에서 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler 리소스의 spec.logLevel 필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal,Debug 및 Trace 이며 Trace 는 가장 자세한 정보 옵션입니다.
보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 재배포합니다. 이 다운타임 동안 새 워크로드를 예약하는 데 스케줄러를 사용할 수 없습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
현재 실행 중인
NUMAResourcesScheduler리소스를 삭제합니다.다음 명령을 실행하여 활성
NUMAResourcesScheduler를 가져옵니다.oc get NUMAResourcesScheduler
$ oc get NUMAResourcesSchedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 90m
NAME AGE numaresourcesscheduler 90mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.
oc delete NUMAResourcesScheduler numaresourcesscheduler
$ oc delete NUMAResourcesScheduler numaresourcesschedulerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deletedCopy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 YAML을
nro-scheduler-debug.yaml파일에 저장합니다. 이 예제에서는 로그 수준을Debug로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 업데이트된
DebugloggingNUMAResourcesScheduler리소스를 생성합니다.oc create -f nro-scheduler-debug.yaml
$ oc create -f nro-scheduler-debug.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증 단계
NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.
다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.
oc get crd | grep numaresourcesschedulers
$ oc get crd | grep numaresourcesschedulersCopy 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:03ZCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.
oc get numaresourcesschedulers.nodetopology.openshift.io
$ oc get numaresourcesschedulers.nodetopology.openshift.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME AGE numaresourcesscheduler 3h26m
NAME AGE numaresourcesscheduler 3h26mCopy to Clipboard Copied! Toggle word wrap Toggle overflow
스케줄러의 로그에 로그 수준이 증가되었는지 확인합니다.
다음 명령을 실행하여
openshift-numaresources네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.oc get pods -n openshift-numaresources
$ oc get pods -n openshift-numaresourcesCopy 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 21mCopy 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-numaresourcesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.3. 리소스 토폴로지 내보내기 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
해당 resource-topology-exporter 로그를 검사하여 예기치 않은 결과가 발생하는 noderesourcetopologies 오브젝트의 문제를 해결합니다.
클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름을 참조하는 노드의 이름을 지정하는 것이 좋습니다. 예를 들어 이름이 worker인 작업자 노드에는 라는 해당 worker noderesourcetopologies 오브젝트가 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
NUMA 리소스 Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는
NUMAResourcesOperatorCR에 해당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 이전 단계의
이름값을 사용하여 관심 있는 daemonset의 레이블을 가져옵니다.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 wideCopy 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.comCopy 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-pb75cCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
8.5.4. 누락된 리소스 토폴로지 내보내기 구성 맵 수정 링크 복사링크가 클립보드에 복사되었습니다!
경우에 따라 클러스터 설정이 잘못 구성된 클러스터에 NUMA 리소스 Operator를 설치하는 경우 Operator가 활성으로 표시되지만 리소스 토폴로지 내보내기(RTE) 데몬 세트 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 구성 맵이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에는 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 리소스 Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.
절차
다음 명령을 사용하여
kubeletconfig의spec.machineConfigPoolSelector.matchLabels값과MachineConfigPool(mcp) worker CR의metadata.labels값을 비교합니다.다음 명령을 실행하여
kubeletconfig라벨을 확인합니다.oc get kubeletconfig -o yaml
$ oc get kubeletconfig -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
machineConfigPoolSelector: matchLabels: cnf-worker-tuning: enabledmachineConfigPoolSelector: matchLabels: cnf-worker-tuning: enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
mcp레이블을 확인합니다.oc get mcp worker -o yaml
$ oc get mcp worker -o yamlCopy 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오브젝트에 존재하지 않습니다.
누락된 레이블을 포함하도록
MachineConfigPoolCR을 편집합니다. 예를 들면 다음과 같습니다.oc edit mcp worker -o yaml
$ oc edit mcp worker -o yamlCopy 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: enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.
검증
누락된
numaresourcesoperator-workerconfigmapCR이 적용되었는지 확인합니다.oc get configmap
$ oc get configmapCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
9장. 확장성 및 성능 최적화 링크 복사링크가 클립보드에 복사되었습니다!
9.1. 스토리지 최적화 링크 복사링크가 클립보드에 복사되었습니다!
스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.
9.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 프로비저닝을 지원합니다.
9.1.2. 권장되는 구성 가능한 스토리지 기술 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에는 지정된 OpenShift Container Platform 클러스터 애플리케이션에 권장되는 구성 가능한 스토리지 기술이 요약되어 있습니다.
| 스토리지 유형 | 블록 | 파일 | 개체 |
|---|---|---|---|
|
1
2 3 Prometheus는 메트릭에 사용되는 기본 기술입니다. 4 물리적 디스크, VM 물리적 디스크, VMDK, NFS를 통한 루프백, AWS EBS 및 Azure Disk에는 적용되지 않습니다.
5 메트릭의 경우 RWX( 6 로깅은 로그 저장소의 영구 스토리지 구성 섹션에서 권장되는 스토리지 솔루션을 검토하십시오. NFS 스토리지를 영구 볼륨으로 사용하거나 Gluster와 같은 NAS를 통해 데이터가 손상될 수 있습니다. 따라서 OpenShift Container Platform Logging에서 Elasticsearch 스토리지 및 10.0.0.1Stack 로그 저장소에 NFS가 지원되지 않습니다. 로그 저장소당 하나의 영구 볼륨 유형을 사용해야 합니다. 7 OpenShift Container Platform의 PV 또는 PVC를 통해서는 오브젝트 스토리지가 사용되지 않습니다. 앱은 오브젝트 스토리지 REST API와 통합해야 합니다. | |||
| ROX1 | 제공됨4 | 제공됨4 | 예 |
| RWX2 | 없음 | 예 | 예 |
| Registry | 구성 가능 | 구성 가능 | 권장 |
| 확장 레지스트리 | 구성 불가능 | 구성 가능 | 권장 |
| Metrics3 | 권장 | 구성 가능5 | 구성 불가능 |
| Elasticsearch 로깅 | 권장 | 구성 가능6 | 지원되지 않음6 |
| CloudEvent Logging | 구성 불가능 | 구성 불가능 | 권장 |
| 앱 | 권장 | 권장 | 구성 불가능7 |
확장된 레지스트리는 두 개 이상의 포드 복제본이 실행되는 OpenShift 이미지 레지스트리입니다.
9.1.2.1. 특정 애플리케이션 스토리지 권장 사항 링크 복사링크가 클립보드에 복사되었습니다!
테스트 결과 RHEL(Red Hat Enterprise Linux)의 NFS 서버를 핵심 서비스의 스토리지 백엔드로 사용하는 데 문제가 있는 것으로 표시됩니다. 여기에는 OpenShift Container Registry and Quay, 스토리지 모니터링을 위한 Prometheus, 로깅 스토리지를 위한 Elasticsearch가 포함됩니다. 따라서 RHEL NFS를 사용하여 핵심 서비스에서 사용하는 PV를 백업하는 것은 권장되지 않습니다.
Marketplace의 다른 NFS 구현에는 이러한 문제가 없을 수 있습니다. 이러한 OpenShift Container Platform 핵심 구성 요소에 대해 완료된 테스트에 대한 자세한 내용은 개별 NFS 구현 공급업체에 문의하십시오.
9.1.2.1.1. 레지스트리 링크 복사링크가 클립보드에 복사되었습니다!
비 확장/HA(고가용성) OpenShift 이미지 레지스트리 클러스터 배포에서는 다음을 수행합니다.
- 스토리지 기술에서 RWX 액세스 모드를 지원할 필요가 없습니다.
- 스토리지 기술에서 쓰기 후 읽기 일관성을 보장해야 합니다.
- 기본 스토리지 기술은 오브젝트 스토리지, 블록 스토리지 순입니다.
- 프로덕션 워크로드가 있는 OpenShift 이미지 레지스트리 클러스터 배포에는 파일 스토리지를 사용하지 않는 것이 좋습니다.
9.1.2.1.2. 확장 레지스트리 링크 복사링크가 클립보드에 복사되었습니다!
확장/HA OpenShift 이미지 레지스트리 클러스터 배포에서는 다음을 수행합니다.
- 스토리지 기술은 RWX 액세스 모드를 지원해야 합니다.
- 스토리지 기술에서 쓰기 후 읽기 일관성을 보장해야 합니다.
- 기본 스토리지 기술은 오브젝트 스토리지입니다.
- Red Hat OpenShift Data Foundation(ODF), Amazon Simple Storage Service(Amazon S3), GCS(Google Cloud Storage), Microsoft Azure Blob Storage 및 OpenStack Swift가 지원됩니다.
- 오브젝트 스토리지는 S3 또는 Swift와 호환되어야 합니다.
- vSphere, 베어 메탈 설치 등 클라우드 이외의 플랫폼에서는 구성 가능한 유일한 기술이 파일 스토리지입니다.
- 블록 스토리지는 구성 불가능합니다.
- OpenShift Container Platform에서 NFS(Network File System) 스토리지 사용이 지원됩니다. 그러나 확장된 레지스트리와 함께 NFS 스토리지를 사용하면 알려진 문제가 발생할 수 있습니다. 자세한 내용은 프로덕션의 OpenShift 클러스터 내부 구성 요소에 대해 NFS가 지원되는 Red Hat 지식베이스 솔루션을 참조하십시오.
9.1.2.1.3. 지표 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 호스트 지표 클러스터 배포에서는 다음 사항에 유의합니다.
- 기본 스토리지 기술은 블록 스토리지입니다.
- 오브젝트 스토리지는 구성 불가능합니다.
프로덕션 워크로드가 있는 호스트 지표 클러스터 배포에는 파일 스토리지를 사용하지 않는 것이 좋습니다.
9.1.2.1.4. 로깅 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 호스트 로깅 클러스터 배포에서는 다음 사항에 유의합니다.
Loki Operator:
- 기본 스토리지 기술은 S3 호환 오브젝트 스토리지입니다.
- 블록 스토리지는 구성 불가능합니다.
OpenShift Elasticsearch Operator:
- 기본 스토리지 기술은 블록 스토리지입니다.
- 오브젝트 스토리지는 지원되지 않습니다.
로깅 버전 5.4.3부터 OpenShift Elasticsearch Operator는 더 이상 사용되지 않으며 향후 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 제거됩니다. OpenShift Elasticsearch Operator를 사용하여 기본 로그 스토리지를 관리하는 대신 Loki Operator를 사용할 수 있습니다.
9.1.2.1.5. 애플리케이션 링크 복사링크가 클립보드에 복사되었습니다!
애플리케이션 사용 사례는 다음 예에 설명된 대로 애플리케이션마다 다릅니다.
- 동적 PV 프로비저닝을 지원하는 스토리지 기술은 마운트 대기 시간이 짧고 정상 클러스터를 지원하는 노드와 관련이 없습니다.
- 애플리케이션 개발자는 애플리케이션의 스토리지 요구사항을 잘 알고 있으며 제공된 스토리지로 애플리케이션을 작동시켜 애플리케이션이 스토리지 계층을 스케일링하거나 스토리지 계층과 상호 작용할 때 문제가 발생하지 않도록 하는 방법을 이해하고 있어야 합니다.
9.1.2.2. 다른 특정 애플리케이션 스토리지 권장 사항 링크 복사링크가 클립보드에 복사되었습니다!
etcd 와 같은 집약적 워크로드에서는 RAID 구성을 사용하지 않는 것이 좋습니다. RAID 구성으로 etcd 를 실행하는 경우 워크로드에 성능 문제가 발생할 위험이 있을 수 있습니다.
- RHOSP(Red Hat OpenStack Platform) Cinder: RHOSP Cinder는 ROX 액세스 모드 사용 사례에 적합합니다.
- 데이터베이스: 데이터베이스(RDBMS, NoSQL DB 등)는 전용 블록 스토리지를 사용하는 경우 성능이 최대화되는 경향이 있습니다.
- etcd 데이터베이스에는 대규모 클러스터를 활성화하기 위해 충분한 스토리지와 적절한 성능 용량이 있어야 합니다. 충분한 스토리지 및 고성능 환경을 설정하는 모니터링 및 벤치마킹 툴에 대한 정보는 권장 etcd 관행에 설명되어 있습니다.
9.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가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다. |
9.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 스토리지에 있는 디스크에서 데이터를 읽는 것보다 훨씬 빠릅니다.
9.2. 라우팅 최적화 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform HAProxy 라우터는 성능을 최적화하도록 확장 또는 구성할 수 있습니다.
9.2.1. 기본 Ingress 컨트롤러(라우터) 성능 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform Ingress 컨트롤러 또는 라우터는 경로 및 인그레스를 사용하여 구성된 애플리케이션 및 서비스의 수신 트래픽의 수신 지점입니다.
초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.
- HTTP 연결 유지/닫기 모드
- 경로 유형
- TLS 세션 재개 클라이언트 지원
- 대상 경로당 동시 연결 수
- 대상 경로 수
- 백엔드 서버 페이지 크기
- 기본 인프라(네트워크/SDN 솔루션, 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 컨트롤러 구성은 spec.tuningOptions.threadCount 필드에서 4 로 설정된 상태에서 사용되었습니다. 두 가지 엔드 포인트 게시 전략이 테스트되었습니다: Load Balancer Service 및 Host Network. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP keep-alive를 사용하면 단일 HAProxy 라우터가 8kB의 작은 페이지 크기에서 1Gbit NIC를 포화시킬 수 있습니다.
최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.
| 애플리케이션 수 | 애플리케이션 유형 |
|---|---|
| 5-10 | 정적 파일/웹 서버 또는 캐싱 프록시 |
| 100-1000 | 동적 콘텐츠를 생성하는 애플리케이션 |
일반적으로 HAProxy는 사용 중인 기술에 따라 최대 1000개의 애플리케이션 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.
Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.
Ingress 샤딩에 대한 자세한 내용은 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성 및 네임스페이스 라벨 을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하십시오.
시간 초과에 대한 스레드 및 Ingress 컨트롤러 구성 매개변수 설정에 제공된 정보를 사용하여 Ingress 컨트롤러 배포 및 Ingress 컨트롤러 사양의 기타 튜닝 구성 을 사용하여 Ingress 컨트롤러 배포를 수정할 수 있습니다.
9.2.2. Ingress 컨트롤러 활동성, 준비 및 시작 프로브 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 OpenShift Container Platform Ingress 컨트롤러(라우터)에서 관리하는 라우터 배포에 대해 kubelet의 활성 상태, 준비 상태, 시작 프로브에 대한 시간 초과 값을 구성할 수 있습니다. 라우터의 활성 상태 및 준비 상태 프로브는 기본 시간 초과 값이 1초이며, 네트워킹 또는 런타임 성능이 크게 저하될 때 너무 짧습니다. 프로브 타임아웃으로 인해 애플리케이션 연결을 중단하는 원치 않는 라우터가 다시 시작될 수 있습니다. 더 큰 시간 초과 값을 설정하는 기능을 사용하면 불필요한 및 원치 않는 재시작 위험을 줄일 수 있습니다.
router 컨테이너의 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
9.2.3. HAProxy 재로드 간격 구성 링크 복사링크가 클립보드에 복사되었습니다!
경로와 연결된 경로 또는 끝점을 업데이트하면 OpenShift Container Platform 라우터에서 HAProxy 구성을 업데이트합니다. 그런 다음 HAProxy는 이러한 변경 사항을 적용하기 위해 업데이트된 구성을 다시 로드합니다. HAProxy가 다시 로드되면 업데이트된 구성을 사용하여 새 연결을 처리하는 새 프로세스가 생성됩니다.
HAProxy는 해당 연결이 모두 닫힐 때까지 기존 프로세스를 실행하여 기존 연결을 처리합니다. 이전 프로세스에 수명이 긴 연결이 있는 경우 이러한 프로세스에서 리소스를 누적하고 사용할 수 있습니다.
기본 최소 HAProxy 재로드 간격은 5초입니다. spec.tuningOptions.reloadInterval 필드를 사용하여 Ingress 컨트롤러를 구성하여 최소 다시 로드 간격을 더 길게 설정할 수 있습니다.
최소 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
9.3. 네트워킹 최적화 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift SDN 은 OpenvSwitch, VXLAN(Virtualxtensible LAN) 터널, OpenFlow 규칙 및 iptables를 사용합니다. 이 네트워크는 점보 프레임, 다중 큐 및 ethtool 설정을 사용하여 조정할 수 있습니다.
OVN-Kubernetes 는 VXLAN 대신 일반 네트워크 가상화 캡슐화(Geneve)를 터널 프로토콜로 사용합니다. 이 네트워크는 NIC(네트워크 인터페이스 컨트롤러) 오프로드를 사용하여 조정할 수 있습니다.
VXLAN은 VLAN에 비해 네트워크 수가 4096개에서 1600만 개 이상으로 증가하고 물리적 네트워크 전반에 걸쳐 계층 2 연결과 같은 이점을 제공합니다. 이를 통해 서비스 뒤에 있는 모든 Pod가 서로 다른 시스템에서 실행되는 경우에도 서로 통신할 수 있습니다.
VXLAN은 사용자 데이터그램 프로토콜(UDP) 패킷의 터널링된 모든 트래픽을 캡슐화합니다. 그러나 이로 인해 CPU 사용량이 증가합니다. 이러한 외부 및 내부 패킷은 전송 중에 데이터가 손상되지 않도록하기 위해 일반 체크섬 규칙을 따릅니다. CPU 성능에 따라 이러한 추가 처리 오버헤드는 처리량이 감소하고 기존 비 오버레이 네트워크에 비해 대기 시간이 증가할 수 있습니다.
클라우드, 가상 머신, 베어 메탈 CPU 성능은 많은 Gbps의 네트워크 처리량을 처리할 수 있습니다. 10 또는 40Gbps와 같은 높은 대역폭 링크를 사용하는 경우 성능이 저하될 수 있습니다. 이 문제는 VXLAN 기반 환경에서 알려진 문제이며 컨테이너 또는 OpenShift Container Platform에만 국한되지 않습니다. VXLAN 터널에 의존하는 네트워크는 VXLAN 구현으로 인해 비슷한 작업을 수행할 수 있습니다.
Gbps을 초과하여 푸시하려는 경우 다음을 수행할 수 있습니다.
- BGP(Border Gateway Protocol)와 같은 다른 라우팅 기술을 구현하는 네트워크 플러그인을 평가합니다.
- VXLAN 오프로드 가능 네트워크 어댑터를 사용합니다. VXLAN 오프로드는 패킷 체크섬 계산 및 관련 CPU 오버헤드를 시스템 CPU에서 네트워크 어댑터의 전용 하드웨어로 이동합니다. 이를 통해 Pod 및 애플리케이션에서 사용할 CPU 사이클을 확보하고 사용자는 네트워크 인프라의 전체 대역폭을 사용할 수 있습니다.
VXLAN 오프로드는 대기 시간을 단축시키지 않습니다. 그러나 대기 시간 테스트에서도 CPU 사용량이 감소합니다.
9.3.1. 네트워크에 대한 MTU 최적화 링크 복사링크가 클립보드에 복사되었습니다!
중요한 최대 전송 단위(MTU)는 NIC(네트워크 인터페이스 컨트롤러) MTU와 클러스터 네트워크 MTU입니다.
NIC MTU는 OpenShift Container Platform을 설치할 때만 구성됩니다. MTU는 네트워크 NIC에서 지원되는 최대 값과 작거나 같아야 합니다. 처리량을 최적화하려면 가능한 가장 큰 값을 선택합니다. 최소 지연을 최적화하려면 더 낮은 값을 선택합니다.
OpenShift SDN 네트워크 플러그인 오버레이 MTU는 NIC MTU보다 최소 50바이트 작아야 합니다. 이 계정은 SDN 오버레이 헤더에 대한 계정입니다. 따라서 일반적인 이더넷 네트워크에서는 이 값을 1450 으로 설정해야 합니다. 점보 프레임 이더넷 네트워크에서는 이 값을 8950 으로 설정해야 합니다. 이러한 값은 NIC의 구성된 MTU를 기반으로 Cluster Network Operator에서 자동으로 설정해야 합니다. 따라서 클러스터 관리자는 일반적으로 이러한 값을 업데이트하지 않습니다. AWS(Amazon Web Services) 및 베어 메탈 환경은 점보 프레임 이더넷 네트워크를 지원합니다. 이 설정은 특히 TCP(Transmission Control Protocol)에서 처리량에 도움이 됩니다.
OVN 및 Geneve의 경우 MTU는 NIC MTU보다 최소 100바이트 작아야 합니다.
50바이트 오버레이 헤더는 OpenShift SDN 네트워크 플러그인과 관련이 있습니다. 기타 SDN 솔루션에서는 이 값이 더 크거나 작아야 할 수 있습니다.
9.3.2. 대규모 클러스터 설치에 대한 권장 사례 링크 복사링크가 클립보드에 복사되었습니다!
대규모 클러스터를 설치하거나 클러스터 스케일링을 통해 노드 수를 늘리는 경우 install-config.yaml 파일에서 클러스터 네트워크 cidr을 적절하게 설정한 후 클러스터를 설치하십시오.
클러스터 크기가 500개 노드를 초과하는 경우 기본 클러스터 네트워크 cidr 10.128.0.0/14를 사용할 수 없습니다. 노드 수가 500개를 초과하게 되면 10.128.0.0/12 또는 10.128.0.0/10으로 설정해야 합니다.
9.3.3. IPsec 영향 링크 복사링크가 클립보드에 복사되었습니다!
노드 호스트의 암호화 및 암호 해독은 CPU를 사용하기 때문에 사용 중인 IP 보안 시스템에 관계없이 암호화를 사용할 때 노드의 처리량과 CPU 사용량 모두에서 성능에 영향을 미칩니다.
IPsec은 NIC에 도달하기 전에 IP 페이로드 수준에서 트래픽을 암호화하여 NIC 오프로드에 사용되는 필드를 보호합니다. 즉, IPSec가 활성화되면 일부 NIC 가속 기능을 사용할 수 없으며 처리량이 감소하고 CPU 사용량이 증가합니다.
9.4. 마운트 네임스페이스 캡슐화를 사용하여 CPU 사용량 최적화 링크 복사링크가 클립보드에 복사되었습니다!
마운트 네임스페이스 캡슐화를 사용하여 kubelet 및 CRI-O 프로세스에 개인 네임스페이스를 제공하는 방식으로 OpenShift Container Platform 클러스터에서 CPU 사용량을 최적화할 수 있습니다. 이렇게 하면 기능 차이 없이 systemd에서 사용하는 클러스터 CPU 리소스가 줄어듭니다.
마운트 네임스페이스 캡슐화는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
9.4.1. 마운트 네임스페이스 캡슐화 링크 복사링크가 클립보드에 복사되었습니다!
마운트 네임스페이스는 다른 네임스페이스의 프로세스가 서로의 파일을 볼 수 없도록 마운트 지점을 분리하는 데 사용됩니다. 캡슐화는 Kubernetes 마운트 네임스페이스를 호스트 운영 체제에서 지속적으로 스캔하지 않는 대체 위치로 이동하는 프로세스입니다.
호스트 운영 체제는 systemd를 사용하여 모든 마운트 네임스페이스를 지속적으로 검사합니다. 표준 Linux 마운트와 Kubernetes가 작동하는 데 사용하는 수많은 마운트입니다. kubelet 및 CRI-O의 현재 구현은 모든 컨테이너 런타임 및 kubelet 마운트 지점에 최상위 네임스페이스를 사용합니다. 그러나 프라이빗 네임스페이스에서 이러한 컨테이너별 마운트 지점을 캡슐화하면 기능의 차이 없이 systemd 오버헤드가 줄어듭니다. CRI-O 및 kubelet 모두에 별도의 마운트 네임스페이스를 사용하면 systemd 또는 기타 호스트 운영 체제 상호 작용에서 컨테이너별 마운트를 캡슐화할 수 있습니다.
이제 모든 OpenShift Container Platform 관리자가 주요 CPU 최적화를 수행할 수 있는 이러한 기능을 사용할 수 있습니다. 캡슐화는 권한이 없는 사용자가 검사에서 안전한 위치에 Kubernetes별 마운트 지점을 저장하여 보안을 개선할 수도 있습니다.
다음 다이어그램에서는 캡슐화 전과 후에 Kubernetes 설치를 보여줍니다. 두 시나리오 모두 양방향, 호스트 간 컨테이너, none의 마운트 전파 설정이 있는 예제 컨테이너를 보여줍니다.
여기에서는 단일 마운트 네임스페이스를 공유하는 systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임을 참조하십시오.
- systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임은 각각 모든 마운트 지점에 대한 액세스 및 가시성을 제공합니다.
-
컨테이너 1은 양방향 마운트 전파로 구성되며 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다.
/run/a와 같은 컨테이너 1에서 시작된 마운트는 systemd, 호스트 운영 체제 프로세스, kubelet, 컨테이너 런타임 및 host-to-container 또는 양방향 마운트 전파가 구성된 기타 컨테이너에 표시됩니다(컨테이너 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 또는 호스트 운영 체제 프로세스에 표시되지 않는 점을 제외하고 변경되지 않습니다. host-to-container 또는 양방향 마운트 전파가 구성된 컨테이너(컨테이너 2)와 같이 kubelet, CRI-O 및 기타 컨테이너에 계속 표시됩니다. - 컨테이너 2 및 컨테이너 3의 동작은 변경되지 않습니다.
9.4.2. 마운트 네임스페이스 캡슐화 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터가 리소스 오버헤드를 적게 실행하도록 마운트 네임스페이스 캡슐화를 구성할 수 있습니다.
마운트 네임스페이스 캡슐화는 기술 프리뷰 기능으로, 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 기능을 수동으로 활성화해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다.
절차
다음 YAML을 사용하여
mount_namespace_config.yaml이라는 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 마운트 네임스페이스
MachineConfigCR을 적용합니다.oc apply -f mount_namespace_config.yaml
$ oc apply -f mount_namespace_config.yamlCopy 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 createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfigCR을 클러스터에 적용하는 데 최대 30분이 걸릴 수 있습니다. 다음 명령을 실행하여MachineConfigCR의 상태를 확인할 수 있습니다.oc get mcp
$ oc get mcpCopy 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 1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행한 후 모든 컨트롤 플레인 및 작업자 노드에
MachineConfigCR이 성공적으로 적용될 때까지 기다립니다.oc wait --for=condition=Updated mcp --all --timeout=30m
$ oc wait --for=condition=Updated mcp --all --timeout=30mCopy 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 metCopy 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 /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemd 마운트 네임스페이스를 확인합니다.
readlink /proc/1/ns/mnt
sh-4.4# readlink /proc/1/ns/mntCopy 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/mntCopy 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/mntCopy 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에 다른 마운트 네임스페이스에 있는 경우 Encapsulation이 적용됩니다. 세 개의 프로세스가 모두 동일한 마운트 네임스페이스에 있는 경우 캡슐화가 적용되지 않습니다.
9.4.3. 캡슐화된 네임스페이스 검사 링크 복사링크가 클립보드에 복사되었습니다!
RHCOS(Red Hat Enterprise Linux CoreOS)에서 사용 가능한 kubensenter 스크립트를 사용하여 디버깅 또는 감사 목적으로 클러스터 호스트 운영 체제의 Kubernetes별 마운트 지점을 검사할 수 있습니다.
클러스터 호스트에 대한 SSH 쉘 세션은 default 네임스페이스에 있습니다. SSH 쉘 프롬프트에서 Kubernetes별 마운트 지점을 검사하려면 kubensenter 스크립트를 root로 실행해야 합니다. kubensenter 스크립트는 마운트 캡슐화의 상태를 알고 있으며 캡슐화가 활성화되지 않은 경우에도 실행할 수 있습니다.
oc debug 원격 쉘 세션은 기본적으로 Kubernetes 네임스페이스 내에서 시작됩니다. oc debug 를 사용할 때 kubensenter 를 실행하여 마운트 지점을 검사할 필요가 없습니다.
캡슐화 기능이 활성화되지 않은 경우 kubensenter findmnt 및 findmnt 명령은 oc debug 세션 또는 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 findmntCopy 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 kubensenterCopy 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/mntCopy to Clipboard Copied! Toggle word wrap Toggle overflow
9.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
10장. 베어 메탈 호스트 관리 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 클러스터에 OpenShift Container Platform을 설치할 때 클러스터에 있는 베어 메탈 호스트에 대한 machine 및 machineset CR(사용자 정의 리소스)을 사용하여 베어 메탈 노드를 프로비저닝하고 관리할 수 있습니다.
10.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에 지정된 대로 호스트에 해당하는 베어 메탈 노드를 프로비저닝합니다.
10.2. 베어 메탈 호스트 유지관리 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔에서 클러스터의 베어 메탈 호스트의 세부 정보를 유지 관리할 수 있습니다. 컴퓨팅 → 베어 메탈 호스트로 이동하여 작업 드롭다운 메뉴에서 작업을 선택합니다. 여기에서 BMC 세부 정보, 호스트의 MAC 주소 부팅, 전원 관리 활성화 등의 항목을 관리할 수 있습니다. 네트워크 인터페이스의 세부 정보와 호스트에 대한 드라이브도 검토할 수 있습니다.
베어 메탈 호스트를 유지 관리 모드로 이동할 수 있습니다. 호스트를 유지 관리 모드로 이동할 때 스케줄러는 모든 관리 워크로드를 해당 베어 메탈 노드에서 이동합니다. 유지 관리 모드에서는 새 워크로드가 예약되지 않습니다.
웹 콘솔에서 베어 메탈 호스트를 프로비저닝 해제할 수 있습니다. 호스트 프로비저닝 해제는 다음 작업을 수행합니다.
-
cluster.k8s.io/delete-machine: true를 사용하여 베어 메탈 호스트 CR에 주석을 답니다. - 관련 컴퓨팅 머신 세트를 축소합니다.
먼저 데몬 세트와 관리되지 않는 정적 Pod를 다른 노드로 이동하지 않고 호스트의 전원을 끄면 서비스가 중단되고 데이터가 손실될 수 있습니다.
10.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 명령 및 적절한 베어 메탈 컴퓨팅 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.
10.2.2. 웹 콘솔에서 YAML을 사용하여 클러스터에 베어 메탈 호스트 추가 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 호스트를 설명하는 YAML 파일을 사용하여 웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.
사전 요구 사항
- 클러스터에 사용할 RHCOS 컴퓨팅 머신을 베어메탈 인프라에 설치합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. -
베어 메탈 호스트의
SecretCR을 생성합니다.
절차
- 웹 콘솔에서 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명령 및 적절한 베어 메탈 컴퓨팅 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.
10.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 오브젝트가 계속 계산됩니다.
10.2.4. provisioner 노드에서 베어 메탈 호스트 제거 링크 복사링크가 클립보드에 복사되었습니다!
특정 상황에서는 프로비저너 노드에서 베어 메탈 호스트를 일시적으로 삭제할 수 있습니다. 예를 들어 OpenShift Container Platform 관리 콘솔을 사용하거나 Machine Config Pool 업데이트로 인해 베어 메탈 호스트 재부팅이 트리거되는 경우 OpenShift Container Platform은 통합된 Dell Remote Access Controller(iDrac)에 로그인하여 작업 대기열 삭제를 발행합니다.
사용 가능한 BareMetalHost 오브젝트 수와 일치하는 Machine 오브젝트 수를 관리하지 않으려면 baremetalhost.metal3.io/detached 주석을 MachineSet 오브젝트에 추가합니다.
이 주석은 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
11장. 베어 메탈 이벤트 릴레이를 사용하여 베어 메탈 이벤트 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
Bare Metal Event Relay는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
11.1. 베어 메탈 이벤트 정보 링크 복사링크가 클립보드에 복사되었습니다!
Bare Metal Event Relay를 사용하여 OpenShift Container Platform 클러스터에서 실행되는 애플리케이션을 기본 베어 메탈 호스트에서 생성된 이벤트에 서브스크립션합니다. Redfish 서비스는 노드에 이벤트를 게시하고 고급 메시지 큐에 서브스크립션된 애플리케이션으로 전송합니다.
베어 메탈 이벤트는 DCTF(Distributed Management Task Force)의 지침에 따라 개발된 오픈 Redfish 표준을 기반으로 합니다. Redfish는 REST API를 사용하여 보안 업계 표준 프로토콜을 제공합니다. 이 프로토콜은 분산, 컨버지드 또는 소프트웨어 정의 리소스 및 인프라를 관리하는 데 사용됩니다.
Redfish를 통해 게시된 하드웨어 관련 이벤트는 다음과 같습니다.
- 온도 제한 위반
- 서버 상태
- 팬 상태
Bare Metal Event Relay Operator를 배포하여 베어 메탈 이벤트 사용을 시작하고 애플리케이션에 서비스에 가입하십시오. Bare Metal Event Relay Operator는 Redfish 베어 메탈 이벤트 서비스의 라이프사이클을 설치하고 관리합니다.
베어 메탈 이벤트 릴레이는 베어 메탈 인프라에서 프로비저닝된 단일 노드 클러스터에서 Redfish 가능 장치에서만 작동합니다.
11.2. 베어 메탈 이벤트 작동 방식 링크 복사링크가 클립보드에 복사되었습니다!
Bare Metal Event Relay를 사용하면 베어 메탈 클러스터에서 실행되는 애플리케이션이 Redfish 하드웨어 변경 및 온도 임계값 위반, 디스크 손실, 정전 및 메모리 실패와 같은 Redfish 하드웨어 변경 및 장애에 빠르게 대응할 수 있습니다. 이러한 하드웨어 이벤트는 HTTP 전송 또는 AMQP 메커니즘을 사용하여 전달됩니다. 메시징 서비스의 대기 시간은 10~20밀리초입니다.
베어 메탈 이벤트 릴레이는 하드웨어 이벤트에 대한 게시-서브스크립션 서비스를 제공합니다. 애플리케이션은 REST API를 사용하여 이벤트를 구독할 수 있습니다. 베어 메탈 이벤트 릴레이는 Redfish OpenAPI v1.8 이상을 준수하는 하드웨어를 지원합니다.
11.2.1. 베어 메탈 이벤트 릴레이 데이터 흐름 링크 복사링크가 클립보드에 복사되었습니다!
다음 그림은 베어 메탈 이벤트 데이터 흐름의 예를 보여줍니다.
그림 11.1. 베어 메탈 이벤트 릴레이 데이터 흐름
11.2.1.1. Operator에서 관리하는 Pod 링크 복사링크가 클립보드에 복사되었습니다!
Operator는 사용자 정의 리소스를 사용하여 HardwareEvent CR을 사용하여 Bare Metal Event Relay 및 해당 구성 요소가 포함된 Pod를 관리합니다.
11.2.1.2. Bare Metal Event Relay 링크 복사링크가 클립보드에 복사되었습니다!
시작 시 베어 메탈 이벤트 릴레이는 Redfish API를 쿼리하고 사용자 지정 레지스트리를 포함한 모든 메시지 레지스트리를 다운로드합니다. 그런 다음 Bare Metal Event Relay가 Redfish 하드웨어에서 서브스크립션 이벤트를 수신하기 시작합니다.
Bare Metal Event Relay를 사용하면 베어 메탈 클러스터에서 실행되는 애플리케이션이 Redfish 하드웨어 변경 및 온도 임계값 위반, 디스크 손실, 정전 및 메모리 실패와 같은 Redfish 하드웨어 변경 및 장애에 빠르게 대응할 수 있습니다. 이벤트는 HardwareEvent CR을 사용하여 보고합니다.
11.2.1.3. 클라우드 네이티브 이벤트 링크 복사링크가 클립보드에 복사되었습니다!
CCNE(클라우드 네이티브 이벤트)는 이벤트 데이터 형식을 정의하기 위한 REST API 사양입니다.
11.2.1.4. CNCF CloudEvents 링크 복사링크가 클립보드에 복사되었습니다!
CloudEvents 는 이벤트 데이터 형식을 정의하기 위해 CCNCF(Cloud Native Computing Foundation)에서 개발한 벤더 중립 사양입니다.
11.2.1.5. HTTP 전송 또는 AMQP 디스패치 라우터 링크 복사링크가 클립보드에 복사되었습니다!
HTTP 전송 또는 AMQP 디스패치 라우터는 게시자와 구독자 간의 메시지 전달 서비스를 담당합니다.
HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS(Extended Life Cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.
11.2.1.6. 클라우드 이벤트 프록시 사이드카 링크 복사링크가 클립보드에 복사되었습니다!
클라우드 이벤트 프록시 사이드카 컨테이너 이미지는 O-RAN API 사양을 기반으로 하며 하드웨어 이벤트에 대한 게시-구독 이벤트 프레임워크를 제공합니다.
11.2.2. Redfish 메시지 구문 분석 서비스 링크 복사링크가 클립보드에 복사되었습니다!
Redfish 이벤트를 처리하는 것 외에도 Bare Metal Event Relay는 Message 속성 없이 이벤트에 대한 메시지 구문 분석 기능을 제공합니다. 프록시는 시작될 때 하드웨어에서 벤더별 레지스트리를 포함하여 모든 Redfish 메시지 레지스트리를 다운로드합니다. 이벤트에 Message 속성이 포함되어 있지 않은 경우 프록시는 Redfish 메시지 레지스트리를 사용하여 Message 및 Resolution 속성을 구성하고 이벤트를 클라우드 이벤트 프레임워크에 전달하기 전에 이벤트에 추가합니다. 이 서비스를 사용하면 Redfish 이벤트의 메시지 크기와 전송 대기 시간이 단축될 수 있습니다.
11.2.3. CLI를 사용하여 베어 메탈 이벤트 릴레이 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 CLI를 사용하여 Bare Metal Event Relay Operator를 설치할 수 있습니다.
사전 요구 사항
- BMC(RedFish-enabled Baseboard Management Controller)가 있는 노드를 사용하여 베어 메탈 하드웨어에 설치된 클러스터입니다.
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
베어 메탈 이벤트 릴레이의 네임스페이스를 생성합니다.
다음 YAML을
베어 메탈-events-namespace.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NamespaceCR을 생성합니다.oc create -f bare-metal-events-namespace.yaml
$ oc create -f bare-metal-events-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
Bare Metal Event Relay Operator에 대한 Operator 그룹을 생성합니다.
다음 YAML을
bare-metal-events-operatorgroup.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroupCR을 생성합니다.oc create -f bare-metal-events-operatorgroup.yaml
$ oc create -f bare-metal-events-operatorgroup.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
베어 메탈 이벤트 릴레이를 구독합니다.
다음 YAML을
bare-metal-events-sub.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow SubscriptionCR을 생성합니다.oc create -f bare-metal-events-sub.yaml
$ oc create -f bare-metal-events-sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
Bare Metal Event Relay Operator가 설치되었는지 확인하려면 다음 명령을 실행합니다.
oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.name,Phase:.status.phase
$ oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.name,Phase:.status.phase
11.2.4. 웹 콘솔을 사용하여 베어 메탈 이벤트 릴레이 설치 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 웹 콘솔을 사용하여 Bare Metal Event Relay Operator를 설치할 수 있습니다.
사전 요구 사항
- BMC(RedFish-enabled Baseboard Management Controller)가 있는 노드를 사용하여 베어 메탈 하드웨어에 설치된 클러스터입니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
OpenShift Container Platform 웹 콘솔을 사용하여 Bare Metal Event Relay를 설치합니다.
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
- 사용 가능한 Operator 목록에서 Bare Metal Event Relay 를 선택한 다음 설치를 클릭합니다.
- Operator 설치 페이지에서 네임스페이스 를 선택하거나 생성한 후 openshift-bare-metal-events 를 선택한 다음 설치를 클릭합니다.
검증
선택 사항: 다음 검사를 수행하여 Operator가 성공적으로 설치되었는지 확인할 수 있습니다.
- Operator → 설치된 Operator 페이지로 전환합니다.
InstallSucceeded 상태로 프로젝트에 Bare Metal Event Relay 가 나열되어 있는지 확인합니다.
참고설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.
Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.
- Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
- 워크로드 → Pod 페이지로 이동하여 프로젝트 네임스페이스에서 Pod 로그를 확인합니다.
11.3. AMQ 메시징 버스 설치 링크 복사링크가 클립보드에 복사되었습니다!
노드에서 게시자와 구독자 간에 Redfish 베어 메탈 이벤트 알림을 전달하려면 노드에서 로컬로 실행되도록 AMQ 메시징 버스를 설치하고 구성할 수 있습니다. 클러스터에서 사용할 AMQ Interconnect Operator를 설치하여 이 작업을 수행합니다.
HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS(Extended Life Cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.
사전 요구 사항
-
OpenShift Container Platform CLI (
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다.
프로세스
-
AMQ Interconnect Operator를 자체
amq-interconnect네임스페이스에 설치합니다. AMQ Interconnect Operator 설치를 참조하십시오.
검증
AMQ Interconnect Operator를 사용할 수 있고 필요한 Pod가 실행 중인지 확인합니다.
oc get pods -n amq-interconnect
$ oc get pods -n amq-interconnectCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23h
NAME READY STATUS RESTARTS AGE amq-interconnect-645db76c76-k8ghs 1/1 Running 0 23h interconnect-operator-5cb5fc7cc-4v7qm 1/1 Running 0 23hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 필요한
bare-metal-event-relay베어 메탈 이벤트 생산자 Pod가openshift-bare-metal-events네임스페이스에서 실행 중인지 확인합니다.oc get pods -n openshift-bare-metal-events
$ oc get pods -n openshift-bare-metal-eventsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl 2/2 Running 0 25s
NAME READY STATUS RESTARTS AGE hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl 2/2 Running 0 25sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4. 클러스터 노드의 Redfish BMC 베어 메탈 이벤트 구독 링크 복사링크가 클립보드에 복사되었습니다!
노드의 BMCEventSubscription CR(사용자 정의 리소스)을 생성하고 이벤트에 대한 HardwareEvent CR을 생성하고 BMC에 대한 Secret CR을 생성하여 클러스터의 노드에서 생성된 Redfish BMC 이벤트를 구독할 수 있습니다.
11.4.1. 베어 메탈 이벤트 구독 링크 복사링크가 클립보드에 복사되었습니다!
BMC(Baseboard Management Controller)를 구성하여 OpenShift Container Platform 클러스터에서 실행되는 서브스크립션 애플리케이션에 베어 메탈 이벤트를 보낼 수 있습니다. Redfish 베어 메탈 이벤트의 예로는 장치 온도 증가 또는 장치 제거가 포함됩니다. REST API를 사용하여 애플리케이션을 베어 메탈 이벤트에 서브스크립션합니다.
Redfish를 지원하고 벤더 인터페이스가 redfish 또는 idrac-redfish 로 설정된 물리적 하드웨어에 대한 BMCEventSubscription CR(사용자 정의 리소스)만 생성할 수 있습니다.
BMCEventSubscription CR을 사용하여 사전 정의된 Redfish 이벤트를 구독합니다. Redfish 표준에서는 특정 경고 및 임계값을 생성할 수 있는 옵션을 제공하지 않습니다. 예를 들어 인클로저의 온도가 40>-< Celsius를 초과하는 경우 경고 이벤트를 수신하려면 공급 업체의 권장 사항에 따라 이벤트를 수동으로 구성해야 합니다.
BMCEventSubscription CR을 사용하여 노드의 베어 메탈 이벤트를 구독하려면 다음 절차를 수행합니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. -
cluster-admin권한이 있는 사용자로 로그인합니다. - BMC의 사용자 이름과 암호를 가져옵니다.
클러스터에 Redfish 지원 BMC(Baseboard Management Controller)를 사용하여 베어 메탈 노드를 배포하고 BMC에서 Redfish 이벤트를 활성화합니다.
참고특정 하드웨어에서 Redfish 이벤트를 활성화하는 것은 이 정보의 범위를 벗어납니다. 특정 하드웨어에 대한 Redfish 이벤트 활성화에 대한 자세한 내용은 BMC 제조업체 설명서를 참조하십시오.
프로세스
다음
curl명령을 실행하여 노드 하드웨어에 RedfishEventService가 활성화되어 있는지 확인합니다.curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"
$ curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- bmc_ip_address
- Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터의 Bare Metal Event Relay 서비스 경로를 가져옵니다.
oc get route -n openshift-bare-metal-events
$ oc get route -n openshift-bare-metal-eventsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hw-event-proxy hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com hw-event-proxy-service 9087 edge None
NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD hw-event-proxy hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com hw-event-proxy-service 9087 edge NoneCopy to Clipboard Copied! Toggle word wrap Toggle overflow BMCEventSubscription리소스를 생성하여 Redfish 이벤트를 구독합니다.다음 YAML을
bmc_sub.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- Redfish 이벤트가 생성되는 작업자 노드의 이름 또는 UUID를 지정합니다.
- 2
- 베어 메탈 이벤트 프록시 서비스를 지정합니다(예:
https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook).
BMCEventSubscriptionCR을 생성합니다.oc create -f bmc_sub.yaml
$ oc create -f bmc_sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
선택 사항: BMC 이벤트 서브스크립션을 삭제하려면 다음 명령을 실행합니다.
oc delete -f bmc_sub.yaml
$ oc delete -f bmc_sub.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항:
BMCEventSubscriptionCR을 생성하지 않고 Redfish 이벤트 서브스크립션을 수동으로 생성하려면 BMC 사용자 이름과 암호를 지정하여 다음curl명령을 실행합니다.curl -i -k -X POST -H "Content-Type: application/json" -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –v$ curl -i -k -X POST -H "Content-Type: application/json" -d '{"Destination": "https://<proxy_service_url>", "Protocol" : "Redfish", "EventTypes": ["Alert"], "Context": "root"}' -u <bmc_username>:<password> 'https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions' –vCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- proxy_service_url
-
베어 메탈 이벤트 프록시 서비스(예:
https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook)입니다.
- bmc_ip_address
- Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
11.4.2. curl을 사용하여 Redfish 베어 메탈 이벤트 서브스크립션 쿼리 링크 복사링크가 클립보드에 복사되었습니다!
일부 하드웨어 벤더는 Redfish 하드웨어 이벤트 서브스크립션의 양을 제한합니다. curl 을 사용하여 Redfish 이벤트 서브스크립션 수를 쿼리할 수 있습니다.
사전 요구 사항
- BMC의 사용자 이름과 암호를 가져옵니다.
- 클러스터에 Redfish 사용 BMC(Baseboard Management Controller)를 사용하여 베어 메탈 노드를 배포하고 BMC에서 Redfish 하드웨어 이벤트를 활성화합니다.
프로세스
다음
curl명령을 실행하여 BMC의 현재 서브스크립션을 확인합니다.curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions
$ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/SubscriptionsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- bmc_ip_address
- Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 예에서 단일 서브스크립션이
/redfish/v1/EventService/Subscriptions/1로 구성되어 있습니다.선택 사항:
curl을 사용하여/redfish/v1/EventService/Subscriptions/1서브스크립션을 제거하려면 BMC 사용자 이름과 암호를 지정하여 다음 명령을 실행합니다.curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1$ curl --globoff -L -w "%{http_code} %{url_effective}\n" -k -u <bmc_username>:<password >-H "Content-Type: application/json" -d '{}' -X DELETE https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions/1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- bmc_ip_address
- Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.
11.4.3. 베어 메탈 이벤트 및 Secret CR 생성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 이벤트 사용을 시작하려면 Redfish 하드웨어가 있는 호스트에 대한 HardwareEvent CR(사용자 정의 리소스)을 생성합니다. 하드웨어 이벤트 및 오류는 hw-event-proxy 로그에 보고됩니다.
사전 요구 사항
-
OpenShift Container Platform CLI(
oc)를 설치했습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. - 베어 메탈 이벤트 릴레이를 설치했습니다.
-
BMC Redfish 하드웨어에 대한
BMCEventSubscriptionCR을 생성했습니다.
프로세스
HardwareEventCR(사용자 정의 리소스)을 생성합니다.참고여러
HardwareEvent리소스가 허용되지 않습니다.다음 YAML을
hw-event.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 필수 항목입니다.
nodeSelector필드를 사용하여 지정된 레이블이 있는 노드를 대상으로 지정합니다(예:node-role.kubernetes.io/hw-event: "").참고OpenShift Container Platform 4.12 이상에서는 베어 메탈 이벤트에 HTTP 전송을 사용할 때
HardwareEvent리소스에서spec.transportHost필드를 설정할 필요가 없습니다. 베어 메탈 이벤트에 AMQP 전송을 사용하는 경우에만transportHost를 설정합니다. - 2
- 선택 사항: 기본값은
debug입니다.hw-event-proxy로그에서 로그 수준을 설정합니다. 다음과 같은 로그 수준을 사용할 수 있습니다.fatal,error,warning,info,debug,trace. - 3
- 선택 사항: Message Parser의 시간 초과 값을 밀리초로 설정합니다. 메시지 구문 분석 요청이 시간 초과 내에 응답하지 않으면 원래 하드웨어 이벤트 메시지가 클라우드 네이티브 이벤트 프레임워크에 전달됩니다. 기본값은 10입니다.
클러스터에
HardwareEventCR을 적용합니다.oc create -f hardware-event.yaml
$ oc create -f hardware-event.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
하드웨어 이벤트 프록시가 베어 메탈 호스트의 Redfish 메시지 레지스트리에 액세스할 수 있는 BMC 사용자 이름 및 암호
SecretCR을 생성합니다.hw-event-bmc-secret.yaml파일에 다음 YAML을 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
stringData아래에 다양한 항목의 일반 텍스트 값을 입력합니다.
SecretCR을 생성합니다.oc create -f hw-event-bmc-secret.yaml
$ oc create -f hw-event-bmc-secret.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
11.5. 베어 메탈 이벤트 REST API 참조에 애플리케이션 구독 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 이벤트 REST API를 사용하여 애플리케이션을 상위 노드에서 생성된 베어 메탈 이벤트에 등록합니다.
리소스 주소 /cluster/node/<node_name>/redfish/event 를 사용하여 애플리케이션을 Redfish 이벤트에 구독합니다. 여기서 < node_name >은 애플리케이션을 실행하는 클러스터 노드입니다.
별도의 애플리케이션 Pod에 cloud-event-consumer 애플리케이션 컨테이너 및 cloud-event-proxy 사이드카 컨테이너를 배포합니다. cloud-event-consumer 애플리케이션은 애플리케이션 Pod의 cloud-event-proxy 컨테이너를 서브스크립션합니다.
다음 API 끝점을 사용하여 애플리케이션 Pod의 http://localhost:8089/api/ocloudNotifications/v1/ 에서 cloud-event-consumer 컨테이너에서 게시한 Redfish 이벤트에 cloud-event- consumer 애플리케이션을 서브스크립션합니다.
/api/ocloudNotifications/v1/subscriptions-
POST: 새 서브스크립션을 생성합니다. -
GET: 서브스크립션 목록 검색합니다.
-
/api/ocloudNotifications/v1/subscriptions/<subscription_id>-
PUT: 지정된 서브스크립션 ID에 대한 새 상태 ping 요청을 생성합니다.
-
/api/ocloudNotifications/v1/health-
GET:ocloudNotificationsAPI의 상태를 반환합니다.
-
9089 는 애플리케이션 Pod에 배포된 cloud-event-consumer 컨테이너의 기본 포트입니다. 필요에 따라 애플리케이션에 대해 다른 포트를 구성할 수 있습니다.
api/ocloudNotifications/v1/subscriptions
HTTP 방법
GET api/ocloudNotifications/v1/subscriptions
설명
서브스크립션 목록을 반환합니다. 서브스크립션이 존재하는 경우 200 OK 상태 코드가 서브스크립션 목록과 함께 반환됩니다.
API 응답 예
HTTP 방법
POST api/ocloudNotifications/v1/subscriptions
설명
새 서브스크립션을 생성합니다. 서브스크립션이 성공적으로 생성되었거나 이미 존재하는 경우 201 Created 상태 코드가 반환됩니다.
| 매개변수 | 유형 |
|---|---|
| subscription | data |
페이로드 예
{
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
"resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}
{
"uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions",
"resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}
api/ocloudNotifications/v1/subscriptions/<subscription_id>
HTTP 방법
GET api/ocloudNotifications/v1/subscriptions/<subscription_id>
설명
ID <subscription _id>가 있는 서브스크립션 세부 정보를 반환합니다.
| 매개변수 | 유형 |
|---|---|
|
| string |
API 응답 예
api/ocloudNotifications/v1/health/
HTTP 방법
GET api/ocloudNotifications/v1/health/
설명
ocloudNotifications REST API의 상태를 반환합니다.
API 응답 예
OK
OK
11.6. PTP 또는 베어 메탈 이벤트에 HTTP 전송을 사용하도록 소비자 애플리케이션 마이그레이션 링크 복사링크가 클립보드에 복사되었습니다!
이전에 PTP 또는 베어 메탈 이벤트 소비자 애플리케이션을 배포한 경우 HTTP 메시지 전송을 사용하도록 애플리케이션을 업데이트해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. - 기본적으로 HTTP 전송을 사용하는 PTP Operator 또는 Bare Metal Event Relay를 버전 4.12 이상으로 업데이트했습니다.
절차
HTTP 전송을 사용하도록 이벤트 소비자 애플리케이션을 업데이트합니다. 클라우드 이벤트 사이드카 배포에 대한
http-event-publishers변수를 설정합니다.예를 들어 PTP 이벤트가 구성된 클러스터에서 다음 YAML 스니펫에서는 클라우드 이벤트 사이드카 배포를 보여줍니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- PTP Operator는
NODE_NAME을 PTP 이벤트를 생성하는 호스트로 자동으로 해결합니다. 예를 들면compute-1.example.com입니다.
베어 메탈 이벤트가 구성된 클러스터에서 클라우드 이벤트 사이드카 배포 CR에서
http-event-publishers필드를hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043으로 설정합니다.이벤트 소비자 애플리케이션과 함께
consumer-events-subscription-service서비스를 배포합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12장. 대규모 페이지의 기능과 애플리케이션에서 대규모 페이지를 사용하는 방법 링크 복사링크가 클립보드에 복사되었습니다!
12.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의 애플리케이션이 사전 할당된 대규모 페이지를 할당하고 사용할 수 있습니다.
12.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과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.
12.3. Downward API를 사용하여 Huge Page 리소스 사용 링크 복사링크가 클립보드에 복사되었습니다!
Downward API를 사용하여 컨테이너에서 사용하는 Huge Page 리소스에 대한 정보를 삽입할 수 있습니다.
리소스 할당을 환경 변수, 볼륨 플러그인 또는 둘 다로 삽입할 수 있습니다. 컨테이너에서 개발하고 실행하는 애플리케이션은 지정된 볼륨에서의 환경 변수 또는 파일을 읽고 사용할 수 있는 리소스를 확인할 수 있습니다.
절차
다음 예와 유사한
hugepages-volume-pod.yaml파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow <.>
requests.hugepages-1Gi에서 리소스 사용을 읽고 값을REQUESTS_HUGEPAGES_1GI환경 변수로 표시하도록 지정합니다. <.>는requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 파일/etc/podinfo/hugepages_1G_request로 표시하도록 지정합니다.volume-pod.yaml파일에서 Pod를 생성합니다.oc create -f hugepages-volume-pod.yaml
$ oc create -f hugepages-volume-pod.yamlCopy 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_1GICopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
REQUESTS_HUGEPAGES_1GI=2147483648
REQUESTS_HUGEPAGES_1GI=2147483648Copy 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_requestCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
2
2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
12.4. 부팅 시 Huge Page 구성 링크 복사링크가 클립보드에 복사되었습니다!
노드는 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.yamlCopy 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.yamlCopy 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) 작업자 노드만 지원합니다.
12.5. Transparent Huge Pages 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
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.yamlCopy 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-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
노드 중 하나에 로그인하고 일반 THP 검사를 수행하여 프로필이 성공적으로 적용되었는지 확인합니다.
cat /sys/kernel/mm/transparent_hugepage/enabled
$ cat /sys/kernel/mm/transparent_hugepage/enabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
always madvise [never]
always madvise [never]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13장. 짧은 대기 시간 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
13.1. 짧은 대기 시간 이해 링크 복사링크가 클립보드에 복사되었습니다!
Telco/5G 영역에서 Edge 컴퓨팅이 등장하여 대기 시간 및 정체 문제를 줄이고 애플리케이션 성능을 개선하는 데 핵심적인 역할을 하고 있습니다.
간단히 말해, 대기 시간이 데이터(패킷)가 발신자에서 수신자로 이동하고 수신자의 처리 후 발신자로 반환되는 속도를 결정합니다. 5G의 네트워크 성능 요구 사항을 충족하기 위해 대기 시간이 가장 짧은 지연으로 네트워크 아키텍처를 유지보수하는 것이 핵심입니다. 평균 대기 시간이 50ms인 4G 기술과 비교하여 5G는 1ms 이하의 대기 시간 번호에 도달하는 것을 목표로 합니다. 이렇게 대기 시간이 감소하면 무선 처리량이 10배 증가합니다.
Telco 공간에 배포된 많은 애플리케이션에서는 제로 패킷 손실이 가능한 짧은 대기 시간을 요구하고 있습니다. 제로 패킷 손실 튜닝은 네트워크 성능을 저하시키는 고유한 문제를 완화하는 데 도움이 됩니다. 자세한 내용은 RHOSP(Red Hat OpenStack Platform)에서 제로 패킷 손실 튜닝을 참조하십시오.
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를 분리하여 워크로드를 실행할 수 있습니다.
현재 cgroup v2에서는 CPU 부하 분산을 비활성화하지 않습니다. 따라서 cgroup v2가 활성화된 경우 성능 프로필에서 원하는 동작을 얻지 못할 수 있습니다. 성능 프로필을 사용하는 경우에는 cgroup v2를 활성화하는 것은 권장되지 않습니다.
OpenShift Container Platform에서는 다양한 산업 환경의 요구를 충족하기 위해 PerformanceProfile 을 조정할 수 있는 Node Tuning Operator의 워크로드 팁도 지원합니다. 워크로드 힌트는 높은 PowerConsumption (전원 소비 증가 시 낮은 대기 시간) 및 realTime (최적 최적의 대기 시간으로 지정된 우선 순위)에 사용할 수 있습니다. 이러한 힌트에 대한 true/false 설정의 조합을 사용하여 애플리케이션별 워크로드 프로필 및 요구 사항을 처리할 수 있습니다.
워크로드 힌트는 업계 섹터 설정에 대한 성능 세부 조정 작업을 단순화합니다. "하나의 크기가 모든" 접근 방식에 적합한 대신 워크로드 힌트는 우선순위 배치와 같은 사용 패턴에 적합할 수 있습니다.
- 짧은 대기 시간
- 실시간 기능
- 효율적인 전력 사용
이상적인 세계에서 모든 것이 우선 순위가 될 것입니다 : 실제 삶에서, 일부는 다른 사람의 비용으로 발생합니다. Node Tuning Operator는 이제 워크로드의 기대치를 인식하고 워크로드의 요구를 더 잘 충족할 수 있게 되었습니다. 이제 클러스터 관리자가 워크로드가 속하는 사용 사례를 지정할 수 있습니다. Node Tuning Operator는 PerformanceProfile 을 사용하여 워크로드의 성능 설정을 미세 조정합니다.
애플리케이션이 작동하는 환경은 해당 동작에 영향을 미칩니다. 대기 시간 요구 사항이 없는 일반적인 데이터 센터의 경우 일부 고성능 워크로드 Pod에 대한 CPU 파티셔닝을 활성화하려면 최소한의 기본 튜닝만 필요합니다. 대기 시간이 더 높은 데이터 센터 및 워크로드의 경우 전력 소비를 최적화하기 위해 계속 조치를 취해야 합니다. 가장 복잡한 경우는 제조기 및 소프트웨어 정의 무선과 같은 대기 시간에 민감한 장치에 가까운 클러스터입니다. 이 마지막 배포 클래스는 Far edge라고 합니다. Far edge 배포의 경우 대기 시간이 가장 낮은 것이 궁극적인 우선 순위이며 전원 관리 비용으로 달성됩니다.
OpenShift Container Platform 버전 4.10 및 이전 버전에서 Performance Addon Operator는 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 사용되었습니다. 이제 이 기능이 Node Tuning Operator의 일부입니다.
13.1.1. 짧은 대기 시간과 실시간 애플리케이션의 하이퍼 스레딩 정보 링크 복사링크가 클립보드에 복사되었습니다!
하이퍼 스레딩은 물리 CPU 프로세서 코어가 두 개의 논리 코어로 작동하여 두 개의 독립 스레드를 동시에 실행할 수 있는 Intel 프로세서 기술입니다. 하이퍼 스레딩을 사용하면 병렬 처리가 효과적인 특정 워크로드 유형에 대한 시스템 처리량이 향상시킬 수 있습니다. 기본 OpenShift Container Platform 설정에서는 기본적으로 하이퍼 스레딩을 활성화하도록 설정해야합니다.
통신 애플리케이션의 경우 가능한 한 대기 시간을 최소화하도록 애플리케이션 인프라를 설계하는 것이 중요합니다. 하이퍼 스레딩은 성능을 저하시킬 수 있으며 대기 시간이 짧은 컴퓨팅 집약적 워크로드의 처리량에 부정적인 영향을 미칠 수 있습니다. 하이퍼 스레딩을 비활성화하면 예측 가능한 성능이 보장되고 이러한 워크로드의 처리 시간을 줄일 수 있습니다.
OpenShift Container Platform을 실행하는 하드웨어에 따라 하이퍼 스레딩 구현 및 구성이 다릅니다. 해당 하드웨어와 관련된 하이퍼 스레딩 구현에 대한 자세한 내용은 관련 호스트 하드웨어 튜닝 정보를 참조하십시오. 하이퍼 스레딩을 비활성화하면 클러스터 코어당 비용이 증가할 수 있습니다.
13.2. 실시간 및 짧은 대기 시간 워크로드 프로비저닝 링크 복사링크가 클립보드에 복사되었습니다!
많은 업계와 조직에서 매우 높은 성능의 컴퓨팅을 필요로 하고 있으며 특히 금융 및 통신 업계에서는 짧고 예측 가능한 대기 시간이 요구될 수 있습니다. 고유한 요구 사항이 있는 이러한 업계의 경우 OpenShift Container Platform은 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능과 일관된 응답 시간을 실현할 수 있도록 자동 튜닝을 구현하는 Node Tuning Operator를 제공합니다.
클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 수행할 수 있습니다. 관리자는 커널을 kernel-rt(실시간)로 업데이트할지 여부를 지정하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하여 워크로드를 실행하고, 사용하지 않는 CPU를 비활성화하여 전력 소비를 줄일 수 있습니다.
보장된 CPU가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 대기 시간이 급증할 수 있습니다. 적절하게 구성된 네트워크 프로브 세트와 같은 다른 프로브를 대안으로 사용하는 것이 좋습니다.
이전 버전의 OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이러한 기능이 Node Tuning Operator의 일부입니다.
13.2.1. 실시간에 대한 알려진 제한 사항 링크 복사링크가 클립보드에 복사되었습니다!
대부분의 배포에서 kernel-rt는 세 개의 컨트롤 플레인 노드와 작업자 노드가 세 개 있는 표준 클러스터를 사용하는 경우 작업자 노드에서만 지원됩니다. OpenShift Container Platform 배포에는 컴팩트 및 단일 노드에 예외가 있습니다. 단일 노드에 설치하려면 kernel-rt가 단일 컨트롤 플레인 노드에서 지원됩니다.
실시간 모드를 완전히 활용하려면 상승된 권한으로 컨테이너를 실행해야 합니다. 권한 부여에 대한 자세한 내용은 컨테이너에 대한 기능 설정을 참조하십시오.
OpenShift Container Platform에서는 허용되는 기능을 제한하므로 SecurityContext를 생성해야 할 수도 있습니다.
RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 사용하는 베어 메탈 설치에서는 이러한 절차가 완전하게 지원됩니다.
적합한 성능 기대치를 설정한다는 것은 실시간 커널이 만능 해결책이 아니라는 것을 나타냅니다. 설정의 목표는 예측 가능한 응답 시간을 제공하는 일관되고 대기 시간이 짧은 결정성을 갖추는 것입니다. 실시간 커널에는 연관된 추가 커널 오버헤드가 있습니다. 이러한 오버헤드는 주로 별도로 예약된 스레드에서 하드웨어 중단을 처리하는 데서 발생합니다. 일부 워크로드에서 오버헤드가 증가하면 전반적으로 처리량 성능이 저하됩니다. 정확한 저하 수치는 워크로드에 따라 달라지며, 범위는 0%에서 30% 사이입니다. 하지만 이러한 저하는 결정성에 대한 대가입니다.
13.2.2. 실시간 기능이 있는 작업자 프로비저닝 링크 복사링크가 클립보드에 복사되었습니다!
- 선택사항: OpenShift Container Platform 클러스터에 노드를 추가합니다. 시스템 튜닝을 위한 BIOS 매개변수 설정을 참조하십시오.
-
oc명령을 사용하여 실시간 기능이 필요한 작업자 노드에worker-rt레이블을 추가합니다. 실시간 노드에 사용할 새 머신 구성 풀을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow worker-rt 레이블이 있는 노드 그룹에 대해 머신 구성 풀
worker-rt가 생성됩니다.노드 역할 레이블을 사용하여 적절한 머신 구성 풀에 노드를 추가합니다.
참고실시간 워크로드로 구성된 노드를 결정해야 합니다. 클러스터의 모든 노드 또는 노드의 하위 집합을 구성할 수 있습니다. 모든 노드를 예상하는 Node Tuning Operator는 전용 머신 구성 풀의 일부입니다. 모든 노드를 사용하는 경우 Node Tuning Operator에서 작업자 노드 역할 레이블을 가리켜야 합니다. 서브 세트를 사용하는 경우 해당 노드를 새 머신 구성 풀로 그룹화해야 합니다.
-
적절한 하우스키핑 코어 세트와
realTimeKernel: enabled: true를 사용하여PerformanceProfile을 생성합니다. PerformanceProfile에서machineConfigPoolSelector를 설정해야 합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 레이블과 일치하는 머신 구성 풀이 있는지 검증합니다.
oc describe mcp/worker-rt
$ oc describe mcp/worker-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rt
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow - OpenShift Container Platform에서 노드 구성을 시작합니다. 이 작업에서는 여러 번 재부팅이 수행될 수 있습니다. 노드가 설정될 때까지 기다리십시오. 사용하는 하드웨어에 따라 시간이 오래 걸릴 수 있으며 노드당 20분으로 예상됩니다.
- 모든 요소가 예상대로 작동하는지 검증하십시오.
13.2.3. 실시간 커널 설치 검증 링크 복사링크가 클립보드에 복사되었습니다!
다음 명령을 사용하여 실시간 커널이 설치되었는지 검증합니다.
oc get node -o wide
$ oc get node -o wide
4.18.0-305.30.1.rt7.102.el8_4.x86_64 cri-o://1.25.0-99.rhaos4.10.gitc3131de.el8 문자열이 포함된 worker-rt 역할의 작업자를 기록해 둡니다.
13.2.4. 실시간으로 작동하는 워크로드 생성 링크 복사링크가 클립보드에 복사되었습니다!
실시간 기능을 사용할 워크로드를 준비하려면 다음 절차를 사용하십시오.
프로세스
-
QoS 클래스가
Guaranteed인 Pod를 생성합니다. - 선택사항: DPDK에 대해 CPU 부하 분산을 비활성화합니다.
- 적절한 노드 선택기를 할당합니다.
애플리케이션을 작성하는 경우 애플리케이션 튜닝 및 배포에 설명된 일반 권장 사항을 따르십시오.
13.2.5. QoS 클래스가 Guaranteed인 Pod 생성 링크 복사링크가 클립보드에 복사되었습니다!
QoS 클래스가 Guaranteed로 지정된 Pod를 생성하는 경우 다음 사항에 유의하십시오.
- Pod의 모든 컨테이너에는 메모리 제한과 메모리 요청이 있어야 하며 동일해야 합니다.
- Pod의 모든 컨테이너에는 CPU 제한과 CPU 요청이 있어야 하며 동일해야 합니다.
다음 예에서는 컨테이너가 하나인 Pod의 구성 파일을 보여줍니다. 이 컨테이너에는 메모리 제한과 메모리 요청이 있으며 둘 다 200MiB입니다. 이 컨테이너에는 CPU 제한과 CPU 요청이 있으며 둘 다 CPU 1개입니다.
Pod를 생성합니다.
oc apply -f qos-pod.yaml --namespace=qos-example
$ oc apply -f qos-pod.yaml --namespace=qos-exampleCopy to Clipboard Copied! Toggle word wrap Toggle overflow Pod에 대한 자세한 정보를 봅니다.
oc get pod qos-demo --namespace=qos-example --output=yaml
$ oc get pod qos-demo --namespace=qos-example --output=yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
spec: containers: ... status: qosClass: Guaranteedspec: containers: ... status: qosClass: GuaranteedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고컨테이너가 자체 메모리 제한은 지정하지만 메모리 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로, 컨테이너가 자체 CPU 제한은 지정하지만 CPU 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.
13.2.6. 선택사항: DPDK에 대해 CPU 부하 분산 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
CPU 부하 분산을 비활성화하거나 활성화하는 기능은 CRI-O 수준에서 구현됩니다. CRI-O 아래의 코드는 다음 요구사항이 충족되는 경우에만 CPU 부하 분산을 비활성화하거나 활성화합니다.
Pod는
performance-<profile-name>런타임 클래스를 사용해야 합니다. 다음과 같이 성능 프로필의 상태를 보고 적절한 이름을 가져올 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
현재 cgroup v2에서는 CPU 부하 분산을 비활성화하는 것은 지원되지 않습니다.
Node Tuning Operator는 관련 노드 아래에 고성능 런타임 처리기 구성 스니펫을 생성하고 클러스터에 고성능 런타임 클래스를 생성해야 합니다. CPU 부하 분산 구성 기능을 활성화하는 것을 제외하고는 기본 런타임 처리기와 콘텐츠가 동일합니다.
Pod에 대해 CPU 부하 분산을 비활성화하려면 Pod 사양에 다음 필드가 포함되어야 합니다.
CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 그렇지 않은 경우 CPU 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.
13.2.7. 적절한 노드 선택기 할당 링크 복사링크가 클립보드에 복사되었습니다!
노드에 Pod를 할당하는 기본 방법은 다음과 같이 성능 프로필에서 사용한 것과 동일한 노드 선택기를 사용하는 것입니다.
자세한 내용은 노드 선택기를 사용하여 특정 노드에 Pod 배치를 참조하십시오.
13.2.8. 실시간 기능이 있는 작업자에 대해 워크로드 예약 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator에서 짧은 대기 시간을 위해 구성된 머신 구성 풀에 연결된 노드와 일치하는 라벨 선택기를 사용합니다. 자세한 내용은 노드에 Pod 할당을 참조하십시오.
13.2.9. CPU를 오프라인 상태에서 사용하여 전력 소비 감소 링크 복사링크가 클립보드에 복사되었습니다!
일반적으로 Telemunication 워크로드를 예상할 수 있습니다. 모든 CPU 리소스가 필요하지 않은 경우 Node Tuning Operator를 사용하면 성능 프로필을 수동으로 업데이트하여 전력 소비를 줄일 수 있도록 Node Tuning Operator를 오프라인에서 사용할 수 있습니다.
사용되지 않는 CPU를 오프라인으로 전환하려면 다음 작업을 수행해야 합니다.
성능 프로필에 오프라인 CPU를 설정하고 YAML 파일의 내용을 저장합니다.
오프라인 CPU가 있는 성능 프로파일의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 선택 사항:
오프라인필드에서 CPU를 나열하여 지정된 CPU를 오프라인으로 가져올 수 있습니다.
다음 명령을 실행하여 업데이트된 프로필을 적용합니다.
oc apply -f my-performance-profile.yaml
$ oc apply -f my-performance-profile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.2.10. 선택 사항: 절전 구성 링크 복사링크가 클립보드에 복사되었습니다!
높은 우선 순위 워크로드의 대기 시간 또는 처리량에 영향을 주지 않고 우선 순위가 높은 워크로드와 함께 배치되는 우선 순위가 낮은 노드에 대해 전력 절감을 활성화할 수 있습니다. 워크로드 자체를 수정하지 않고 절전을 수행할 수 있습니다.
이 기능은 Intel Ice Lake 및 이후 세대의 Intel CPU에서 지원됩니다. 프로세서의 기능은 높은 우선 순위 워크로드의 대기 시간 및 처리량에 영향을 미칠 수 있습니다.
절전 구성을 사용하여 노드를 구성하는 경우 Pod 수준에서 성능 구성으로 높은 우선 순위의 워크로드를 구성해야 합니다. 즉, 구성이 Pod에서 사용하는 모든 코어에 적용됩니다.
Pod 수준에서 P-states 및 C-states를 비활성화하면 높은 우선 순위의 워크로드를 구성하여 최상의 성능과 대기 시간을 단축할 수 있습니다.
| 주석 | 설명 |
|---|---|
annotations: cpu-c-states.crio.io: "disable" cpu-freq-governor.crio.io: "<governor>"
|
C-states를 비활성화하고 CPU 스케일링에 대한 governor 유형을 지정하여 Pod에 가장 적합한 성능을 제공합니다. 높은 우선 순위 워크로드에 |
사전 요구 사항
- BIOS에서 C-states 및 OS 제어 P-states 활성화
절차
per-pod-power-management를true로 설정하여PerformanceProfile을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
power-consumption-mode는per-pod-power-management가true로 설정된 경우default또는low-latency여야 합니다.
perPodPowerManagement가 있는PerformanceProfile의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본
cpufreqgovernor를PerformanceProfileCR(사용자 정의 리소스)에서 추가 커널 인수로 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 그러나
schedutilgovernor를 사용하는 것이 좋습니다. 그러나ondemand또는powersavegovernors와 같은 다른 governors를 사용할 수 있습니다.
TunedPerformancePatchCR에서 최대 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/cpu0/cpufreq/cpuinfo_max_freq에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든코어s의 frequency에서 모든 CPU를 제한하는 백분율을 사용할 수 있습니다.모든 코어sECDHE빈도는 코어가 모두 완전히 사용 중인 경우 모든 코어가 실행되는 빈도입니다.
높은 우선 순위 워크로드 Pod에 원하는 주석을 추가합니다. 주석은
기본설정을 재정의합니다.우선 순위가 높은 워크로드 주석 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Pod를 다시 시작합니다.
13.2.11. 보장된 pod 분리 CPU의 장치 중단 처리 관리 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator는 Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 예약된 CPU와 워크로드를 실행하는 애플리케이션 컨테이너의 분리된 CPU로 호스트 CPU를 관리할 수 있습니다. 이를 통해 대기 시간이 짧은 워크로드의 CPU를 분리된 상태로 설정할 수 있습니다.
장치 중단은 보장된 pod가 실행 중인 CPU를 제외하고 CPU의 과부하를 방지하기 위해 모든 분리된 CPU와 예약된 CPU 간에 균형을 유지합니다. pod에 관련 주석이 설정되어 있으면 보장된 Pod CPU가 장치 인터럽트를 처리하지 못합니다.
새로운 성능 프로파일 필드 globallyDisableIrqLoadBalancing은 장치 중단을 처리할지 여부를 관리하는 데 사용할 수 있습니다. 특정 워크로드의 경우 예약된 CPU가 장치 인터럽트를 처리하기에 충분하지 않으며 이러한 이유로 장치 중단은 분리된 CPU에서 전역적으로 비활성화되지 않습니다. 기본적으로 Node Tuning Operator는 분리된 CPU에서 장치 인터럽트를 비활성화하지 않습니다.
워크로드에 대한 대기 시간을 단축하기 위해 일부(전체) pod에는 장치 인터럽트를 처리하지 않기 위한 실행 중인 CPU가 필요합니다. pod 주석 irq-load-balancing.crio.io는 장치 인터럽트의 처리 여부를 정의하는 데 사용됩니다. 설정되어 있는 경우 CRI-O는 pod가 실행되는 경우에만 장치 인터럽트를 비활성화합니다.
13.2.11.1. CPU CFS 할당량 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
보장된 개별 Pod의 CPU 제한을 줄이려면 cpu-quota.crio.io: "disable" 주석이 있는 Pod 사양을 생성합니다. 이 주석은 Pod 런타임에 CPU 완전 공정 스케줄러(CFS) 할당량을 비활성화합니다. 다음 Pod 사양에는 이 주석이 포함되어 있습니다.
CPU 관리자 정적 정책이 활성화되어 있고 전체 CPU를 사용하는 보장된 QoS가 있는 Pod의 경우 CPU CFS 할당량만 비활성화합니다. 그렇지 않으면 CPU CFS 할당량을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.
13.2.11.2. Node Tuning Operator에서 글로벌 장치 인터럽트 처리 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
분리된 CPU 세트에 대한 글로벌 장치 인터럽트를 비활성화하도록 Node Tuning Operator를 구성하려면 성능 프로필의 globallyDisableIrqLoadBalancing 필드를 true 로 설정합니다. true인 경우 충돌하는 Pod 주석이 무시됩니다. false인 경우 IRQ 로드는 모든 CPU에서 균형을 유지합니다.
성능 프로파일 스니펫에서는 이 설정을 보여줍니다.
13.2.11.3. 개별 pod에 대한 인터럽트 처리 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
개별 pod의 인터럽트 처리를 비활성화하려면 성능 프로필에서 globallyDisableIrqLoadBalancing이 false 로 설정되어 있는지 확인합니다. 그런 다음 Pod 사양에서 irq-load-balancing.crio.io Pod 주석을 설정하여 를 비활성화합니다. 다음 Pod 사양에는 이 주석이 포함되어 있습니다.
13.2.12. 장치 인터럽트 처리를 사용하기 위해 성능 프로파일을 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
기존 프로필에서 Node Tuning Operator 성능 프로필 CRD(사용자 정의 리소스 정의)를 v1 또는 v1alpha1에서 v2로 업그레이드하는 경우 기존 프로필에서 globallyDisableIrqLoadBalancing 이 true 로 설정됩니다.
globallyDisableIrqLoadBalancing toggles whether IRQ 로드 밸런싱이 Isolated CPU 세트에 대해 비활성화됩니다. 옵션을 true 로 설정하면 Isolated CPU 세트에 대한 IRQ 부하 분산을 비활성화합니다. 옵션을 false 로 설정하면 IRQ가 모든 CPU에서 균형을 유지할 수 있습니다.
13.2.12.1. 지원되는 API 버전 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator는 성능 프로파일 apiVersion 필드에 v2,v1 및 v1alpha1 을 지원합니다. v1 및 v1alpha1 API는 동일합니다. v2 API에는 기본값인 false 값을 사용하여 선택적 부울 필드 loballyDisableIrqLoadBalancing이 포함됩니다.
13.2.12.1.1. Node Tuning Operator API를 v1alpha1에서 v1로 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator API 버전을 v1alpha1에서 v1로 업그레이드하는 경우 "None" 변환 전략을 사용하여 v1alpha1 성능 프로파일이 즉시 변환되고 API 버전 v1과 Node Tuning Operator에 제공됩니다.
13.2.12.1.2. Node Tuning Operator API를 v1alpha1 또는 v1에서 v2로 업그레이드 링크 복사링크가 클립보드에 복사되었습니다!
이전 Node Tuning Operator API 버전에서 업그레이드할 때 기존 v1 및 v1alpha1 성능 프로파일은 true 값이 있는 globallyDisableIrqLoadBalancing 필드를 삽입하는 변환 Webhook를 사용하여 변환됩니다.
13.3. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필을 사용하면 특정 머신 구성 풀에 속한 노드의 대기 시간 튜닝 측면을 제어할 수 있습니다. 설정을 지정하면 PerformanceProfile 오브젝트가 실제 노드 수준 튜닝을 수행하는 여러 오브젝트로 컴파일됩니다.
-
MachineConfig파일은 노드를 조작합니다. -
KubeletConfig파일은 토폴로지 관리자, CPU 관리자 및 OpenShift Container Platform 노드를 구성합니다. - Tuned 프로필은 Node Tuning Operator를 구성합니다.
성능 프로필을 사용하여 커널을 kernel-rt로 업데이트할지 여부를 지정하고, 대규모 페이지를 할당하고, CPU를 분할하여 하우스키핑 작업 수행 또는 워크로드 실행에 사용할 CPU를 분할할 수 있습니다.
PerformanceProfile 오브젝트를 수동으로 생성하거나 PPC(Performance Profile Creator)를 사용하여 성능 프로필을 생성할 수 있습니다. PPC에 대한 자세한 내용은 아래 추가 리소스를 참조하십시오.
성능 프로파일의 예
- 1
- 이 필드를 사용하여 워크로드의 애플리케이션 컨테이너와 함께 사용할 특정 CPU를 분리합니다. 하이퍼 스레딩이 활성화된 경우 오류 없이 Pod를 실행할 수 있도록 분리된 CPU 수를 설정합니다.
- 2
- 이 필드를 사용하여 하우스키핑을 위해 인프라 컨테이너와 함께 사용할 특정 CPU를 예약합니다.
- 3
- 이 필드를 사용하여 노드에 실시간 커널을 설치합니다. 유효한 값은
true또는false입니다.true값을 설정하면 실시간 커널이 설치됩니다. - 4
- 이 필드를 사용하여 토폴로지 관리자 정책을 구성합니다. 유효한 값은
none(기본값),best-effort,restricted및single-numa-node입니다. 자세한 내용은 토폴로지 관리자 정책을 참조하십시오. - 5
- 이 필드를 사용하여 특정 노드에 성능 프로파일을 적용할 노드 선택기를 지정합니다.
13.3.1. 대규모 페이지 구성 링크 복사링크가 클립보드에 복사되었습니다!
노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Node Tuning Operator를 사용하여 특정 노드에 대규모 페이지를 할당합니다.
OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Node Tuning Operator는 성능 프로필을 사용하여 이 작업을 더 쉽게 수행할 수 있는 방법을 제공합니다.
예를 들어 성능 프로필의 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.internalCopy to Clipboard Copied! Toggle word wrap Toggle overflow grep -i huge /proc/meminfo
# grep -i huge /proc/meminfoCopy 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 hugeCopy 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
13.3.2. 여러 대규모 페이지 크기 할당 링크 복사링크가 클립보드에 복사되었습니다!
동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.
예를 들어 1G 및 2M 크기를 정의할 수 있으며 Node Tuning Operator는 다음과 같이 노드에서 두 크기를 모두 구성합니다.
13.3.3. IRQ 동적 로드 밸런싱을 위한 노드 구성 링크 복사링크가 클립보드에 복사되었습니다!
IRQ 동적 로드 밸런싱의 클러스터 노드를 구성하여 어떤 코어가 장치 인터럽트 요청(IRQ)을 수신할 수 있는지 제어합니다.
사전 요구 사항
- 핵심 격리를 위해 모든 서버 하드웨어 구성 요소는 IRQ 선호도를 지원해야 합니다. 서버의 하드웨어 구성 요소가 IRQ 선호도를 지원하는지 확인하려면 서버의 하드웨어 사양을 확인하거나 하드웨어 제공 업체에 문의하십시오.
절차
- cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
-
performance.openshift.io/v2를 사용하도록 성능 프로파일의apiVersion을 설정합니다. -
globallyDisableIrqLoadBalancing필드를 삭제제거하거나false로 설정합니다. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 CPU를 예약하는 프로파일을 보여줍니다.
isolatedCPU 세트에서 실행되는 Pod에 대해 IRQ 로드 밸런싱이 활성화됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.
전용 CPU를 사용하는 pod를 생성하고
irq-load-balancing.crio.io및cpu-quota.crio.io주석을disable로 설정합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
performance-<profile_name> 형식으로 pod
runtimeClassName을 입력합니다. 여기서<profile_name>은PerformanceProfileYAML의name입니다 (예:performance- dynamic-irq-profile). - 노드 선택기를 cnf-worker 을 대상으로 설정합니다.
Pod가 올바르게 실행되고 있는지 확인합니다. 상태가
running이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.oc get pod -o wide
$ oc get pod -o wideCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dynamic-irq-pod 1/1 Running 0 5h33m <ip-address> <node-name> <none> <none>
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES dynamic-irq-pod 1/1 Running 0 5h33m <ip-address> <node-name> <none> <none>Copy to Clipboard Copied! Toggle word wrap Toggle overflow IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.
oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"$ oc exec -it dynamic-irq-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-3Copy 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 예상 출력
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드 파일 시스템을 사용할 수 있는지 확인합니다.
chroot /host
sh-4.4# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
sh-4.4#
sh-4.4#Copy to Clipboard Copied! Toggle word wrap Toggle overflow 기본 시스템 CPU 선호도 마스크에
dynamic-irq-podCPU (예: CPU 2 및 3)가 포함되지 않도록 합니다.cat /proc/irq/default_smp_affinity
$ cat /proc/irq/default_smp_affinityCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
33
33Copy to Clipboard Copied! Toggle word wrap Toggle overflow IRQ가
dynamic-irq-podCPU에서 실행되도록 구성되어 있지 않은지 확인합니다.find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;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
13.3.4. IRQ 선호도 설정 지원 정보 링크 복사링크가 클립보드에 복사되었습니다!
일부 IRQ 컨트롤러는 IRQ 선호도 설정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 노출합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다.
다음은 Red Hat이 IRQ 선호도 설정을 지원하지 않는 드라이버 및 하드웨어의 예입니다. 목록은 절대적인 것이 아닙니다:
-
megaraid_sas와 같은 일부 RAID 컨트롤러 드라이버 - 많은 NVMe(Non-volatile memory express) 드라이버
- LOM(Migain on 마더보드) 네트워크 컨트롤러의 일부 LAN
-
드라이버는
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 {} \;
출력 예
일부 드라이버는 Managed_irqs 를 사용합니다. 여기서 선호도는 커널에서 내부적으로 관리되고 사용자 공간은 선호도를 변경할 수 없습니다. 경우에 따라 이러한 IRQ가 분리된 CPU에 할당될 수 있습니다. managed_irqs 에 대한 자세한 내용은 분리된 CPU를 대상으로하더라도 관리되는 인터럽트의 유사성 을 참조하십시오.
13.3.5. 클러스터의 하이퍼 스레딩 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터의 하이퍼 스레딩을 구성하려면 성능 프로파일의 CPU 스레드를 예약 또는 분리된 CPU 풀에 구성된 동일한 코어로 설정합니다.
성능 프로파일을 구성하고 호스트의 하이퍼 스레딩 구성을 변경하는 경우 PerformanceProfile YAML의 CPU isolated 및 reserved 필드를 새 구성과 일치하도록 업데이트해야 합니다.
이전에 활성화된 호스트 하이퍼 스레딩 구성을 비활성화하면 PerformanceProfile YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - OpenShift CLI(oc)를 설치합니다.
절차
구성할 호스트의 모든 CPU에서 실행중인 스레드를 확인합니다.
클러스터에 로그인하고 다음 명령을 실행하여 호스트 CPU에서 실행중인 스레드를 볼 수 있습니다.
lscpu --all --extended
$ lscpu --all --extendedCopy 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_listCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
0-4
0-4Copy to Clipboard Copied! Toggle word wrap Toggle overflow PerformanceProfileYAML에서 분리 및 예약된 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 풀은 중복되지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
하이퍼 스레딩은 대부분의 Intel 프로세서에서 기본적으로 활성화되어 있습니다. 하이퍼 스레딩을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.
13.3.5.1. 지연 시간이 짧은 애플리케이션의 하이퍼 스레딩 비활성화 링크 복사링크가 클립보드에 복사되었습니다!
지연 시간이 짧은 프로세스를 위해 클러스터를 구성할 때 클러스터를 배포하기 전에 하이퍼 스레딩을 비활성화할지 여부를 고려하십시오. 하이퍼 스레딩을 비활성화하려면 다음을 수행합니다.
- 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
nosmt를 추가 커널 인수로 설정합니다. 다음 성능 프로파일 예에서는 이 설정에 대해 설명합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.
13.3.6. 워크로드 팁 이해 링크 복사링크가 클립보드에 복사되었습니다!
다음 표에서는 전력 소비와 실시간 설정이 대기 시간에 미치는 영향에 대해 설명합니다.
다음 워크로드 힌트를 수동으로 구성할 수 있습니다. Performance Profile Creator를 사용하여 워크로드 힌트를 사용할 수도 있습니다. 성능 프로필에 대한 자세한 내용은 "성능 프로필 생성" 섹션을 참조하십시오. 워크로드 힌트가 수동으로 구성되고 realTime 워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true 입니다.
| Performance Profile Creator 설정 | 힌트 | 환경 | 설명 |
|---|---|---|---|
| 기본값 |
workloadHints: highPowerConsumption: false realTime: false
| 대기 시간 요구 사항이 없는 높은 처리량 클러스터 | CPU 파티셔닝을 통해서만 달성된 성능. |
| low-latency |
workloadHints: highPowerConsumption: false realTime: true
| 지역 데이터센터 | 전력 절감과 대기 시간이 짧은 경우 모두, 전원 관리, 대기 시간 및 처리량이 저하됩니다. |
| Ultra-low-latency |
workloadHints: highPowerConsumption: true realTime: true
| 긴 엣지 클러스터, 대기 시간 중요한 워크로드 | 전력 소비 증가의 비용으로 절대 최소 대기 시간과 최대 결정성에 최적화되어 있습니다. |
| 포드별 전원 관리 |
workloadHints: realTime: true highPowerConsumption: false perPodPowerManagement: true
| 심각하거나 중요하지 않은 워크로드 | Pod당 전원 관리를 허용합니다. |
13.3.7. 워크로드 힌트 수동 구성 링크 복사링크가 클립보드에 복사되었습니다!
절차
-
"Works workload hints"의 표에 설명된 대로 환경의 하드웨어 및 토폴로지에 적합한
PerformanceProfile을 생성합니다. 예상 워크로드와 일치하도록 프로필을 조정합니다. 이 예에서는 가능한 가장 짧은 대기 시간을 튜닝합니다. highPowerConsumption및realTime워크로드 힌트를 추가합니다. 둘 다true로 설정되어 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
성능 프로파일에서 realTime 워크로드 힌트 플래그가 true 로 설정된 경우 고정 CPU가 있는 보장된 모든 Pod에 cpu-quota.crio.io: disable 주석을 추가합니다. 이 주석은 Pod 내에서 프로세스 성능이 저하되지 않도록 하는 데 필요합니다. realTime 워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true 입니다.
13.3.8. 인프라 및 애플리케이션 컨테이너의 CPU 제한 링크 복사링크가 클립보드에 복사되었습니다!
일반 하우스키핑 및 워크로드 작업에서는 대기 시간에 민감한 프로세스에 영향을 줄 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하므로 컨텍스트 스위치와 대기 시간이 급증할 수 있습니다. CPU를 분할하면 대기 시간에 민감한 프로세스를 분리하여 프로세스에서 서로 분리할 수 없습니다. 다음 표에서는 Node Tuning Operator를 사용하여 노드를 조정한 후 CPU에서 프로세스를 실행하는 방법을 설명합니다.
| 프로세스 유형 | 세부 정보 |
|---|---|
|
| 대기 시간이 짧은 워크로드가 실행되는 경우를 제외하고 모든 CPU에서 실행 |
| 인프라 Pod | 대기 시간이 짧은 워크로드가 실행되는 경우를 제외하고 모든 CPU에서 실행 |
| 인터럽트 | 예약된 CPU로 리디렉션(OpenShift Container Platform 4.7 이상에서 선택 사항) |
| 커널 프로세스 | 예약된 CPU에 고정 |
| 대기 시간에 민감한 워크로드 Pod | 분리된 풀에서 특정 전용 CPU 세트에 고정 |
| OS 프로세스/systemd 서비스 | 예약된 CPU에 고정 |
모든 QoS 프로세스 유형, Burstable,BestEffort 또는 Guaranteed 의 Pod에 대한 노드에 있는 코어의 할당 용량은 분리된 풀의 용량과 동일합니다. 예약된 풀의 용량은 클러스터 및 운영 체제 하우스키핑 작업에서 사용하기 위해 노드의 총 코어 용량에서 제거됩니다.
예시 1
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 격리된 풀에 50개의 코어를 할당하고 예약된 풀에 코어 50개를 할당합니다. 클러스터 관리자는 BestEffort 또는 Burstable Pod에 대해 QoS Guaranteed Pod 및 25 코어를 할당합니다. 이는 격리된 풀의 용량과 일치합니다.
예시 2
노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 격리된 풀에 50개의 코어를 할당하고 예약된 풀에 코어 50개를 할당합니다. 클러스터 관리자는 QoS Guaranteed Pod에 50개의 코어와 BestEffort 또는 Burstable Pod에 하나의 코어를 할당합니다. 이는 하나의 코어로 격리된 풀의 용량을 초과합니다. CPU 용량이 부족하여 Pod 예약이 실패합니다.
사용할 정확한 파티션 패턴은 하드웨어, 워크로드 특성 및 예상 시스템 로드와 같은 여러 요인에 따라 다릅니다. 일부 샘플 사용 사례는 다음과 같습니다.
- 대기 시간에 민감한 워크로드가 NIC(네트워크 인터페이스 컨트롤러)와 같은 특정 하드웨어를 사용하는 경우 분리된 풀의 CPU가 이 하드웨어에 최대한 가깝게 있는지 확인합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
- 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따라 들어오는 모든 패킷 인터럽트를 처리할 수 있도록 충분히 크기 조정된 예약 풀을 할당합니다. 4.12 이상 버전에서는 워크로드에 선택적으로 민감한 것으로 라벨이 지정될 수 있습니다.
예약 및 분리된 파티션에 특정 CPU를 사용해야 하는 결정에는 자세한 분석 및 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요소가 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 달라집니다.
예약되고 분리된 CPU 풀은 중복되지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.
하우스키핑 작업 및 워크로드가 서로 간섭하지 않도록 성능 프로필의 spec 섹션에 두 개의 CPU 그룹을 지정합니다.
-
isolated- 애플리케이션 컨테이너 워크로드에 대한 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다. -
reserved- 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다.예약된그룹의 스레드는 종종 바쁘다.예약된그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은격리된그룹에서 실행됩니다.
절차
- 환경의 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
인프라 및 애플리케이션 컨테이너에 대해
reserved및isolated하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.4. Node Tuning Operator를 사용하여 NIC 큐 감소 링크 복사링크가 클립보드에 복사되었습니다!
Node Tuning Operator를 사용하면 각 네트워크 장치에 대한 NIC(네트워크 인터페이스 컨트롤러) 대기열 수를 조정할 수 있습니다. PerformanceProfile을 사용하면 대기열의 양을 예약된 CPU 수로 줄일 수 있습니다.
13.4.1. 성능 프로파일을 사용하여 NIC 큐 조정 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로파일을 사용하면 각 네트워크 장치의 대기열 수를 조정할 수 있습니다.
지원되는 네트워크 장치는 다음과 같습니다.
- 비가상 네트워크 장치
- 멀티 큐(채널)를 지원하는 네트워크 장치
지원되지 않는 네트워크 장치는 다음과 같습니다.
- Pure Software 네트워크 인터페이스
- 블록 장치
- Intel DPDK 가상 기능
사전 요구 사항
-
cluster-admin역할을 가진 사용자로 클러스터에 액세스합니다. -
OpenShift CLI(
oc)를 설치합니다.
절차
-
cluster-admin권한이 있는 사용자로 Node Tuning Operator를 실행하는 OpenShift Container Platform 클러스터에 로그인합니다. - 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.
생성된 성능 프로파일을 편집합니다.
oc edit -f <your_profile_name>.yaml
$ oc edit -f <your_profile_name>.yamlCopy 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>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.4.2. 대기열 상태 확인 링크 복사링크가 클립보드에 복사되었습니다!
이 섹션에서는 다양한 성능 프로필과 변경 사항이 적용되었는지 확인하는 방법에 대한 여러 예시가 있습니다.
예시 1
이 예에서 네트워크 대기열 수는 지원되는 모든 장치에 대해 예약된 CPU 수(2)로 설정됩니다.
성능 프로필의 관련 섹션은 다음과 같습니다.
다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.
참고성능 프로필이 적용된 노드에서 이 명령을 실행합니다.
ethtool -l <device>
$ ethtool -l <device>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로필을 적용하기 전에 대기열 상태를 확인합니다.
ethtool -l ens4
$ ethtool -l ens4Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 프로필이 적용된 후 대기열 상태를 확인합니다.
ethtool -l ens4
$ ethtool -l ens4Copy 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 ens4Copy 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 ens4Copy 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로 설정됩니다.
13.4.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, ens3Copy 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 availableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
13.5. 짧은 대기 시간 CNF 튜닝 상태 디버깅 링크 복사링크가 클립보드에 복사되었습니다!
PerformanceProfile CR(사용자 정의 리소스)에는 튜닝 상태를 보고하고 대기 시간 성능 저하 문제를 디버깅하기 위한 상태 필드가 있습니다. 이러한 필드는 상태를 보고하여 Operator 조정 기능의 상태에 대해 설명합니다.
일반적으로 성능 프로필에 연결된 머신 구성 풀의 상태가 성능 저하 상태이면 PerformanceProfile이 성능 저하 상태가 되는 문제가 발생할 수 있습니다. 이 경우 머신 구성 풀에서 실패 메시지를 발행합니다.
Node Tuning Operator에는 performanceProfile.spec.status.Conditions 상태 필드가 있습니다.
Status 필드에는 성능 프로필의 상태를 나타내는 Type 값을 지정하는 Conditions가 포함되어 있습니다.
Available- 모든 머신 구성 및 Tuned 프로필이 성공적으로 생성되었으며 구성 요소에서 처리해야 하는 클러스터에 사용할 수 있습니다(NTO, MCO, Kubelet).
Upgradeable- Operator에서 유지보수하는 리소스가 업그레이드하기에 안전한 상태인지를 나타냅니다.
Progressing- 성능 프로필의 배포 프로세스가 시작되었음을 나타냅니다.
Degraded다음과 같은 경우 오류를 표시합니다.
- 성능 프로필 검증에 실패했습니다.
- 모든 관련 구성 요소 생성이 성공적으로 완료되지 않았습니다.
이러한 각 유형에는 다음 필드가 포함되어 있습니다.
상태-
특정 유형의 상태(
true또는false)입니다. Timestamp- 트랜잭션 타임스탬프입니다.
Reason string- 머신에서 읽을 수 있는 이유입니다.
Message string- 상태 및 오류 세부 정보(있는 경우)를 설명하는 사람이 읽을 수 있는 이유입니다.
13.5.1. 머신 구성 풀 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필 및 생성된 제품은 연관 MCP(머신 구성 풀)에 따라 노드에 적용됩니다. MCP에는 커널 인수, kube 구성, 대규모 페이지 할당, rt-kernel 배포를 포괄하는 성능 프로필로 생성된 머신 구성의 적용 진행 상황에 대한 중요한 정보가 들어 있습니다. Performance Profile 컨트롤러는 MCP의 변경 사항을 모니터링하고 성능 프로필 상태를 적절하게 업데이트합니다.
MCP가 성능 프로필 상태로 반환하는 유일한 조건은 MCP가 Degraded 인 경우이며, 이로 인해 performanceProfile.status.condition.Degraded = true 입니다.
예
다음은 생성된 연관 머신 구성 풀(worker-cnf)이 있는 성능 프로필의 예입니다.
연관 머신 구성 풀이 성능 저하 상태입니다.
oc get mcp
# oc get mcpCopy 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 2d20hCopy to Clipboard Copied! Toggle word wrap Toggle overflow MCP의
describe섹션은 이유를 보여줍니다.oc describe mcp worker-cnf
# oc describe mcp worker-cnfCopy 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 syncMessage: 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 syncCopy to Clipboard Copied! Toggle word wrap Toggle overflow degraded = true로 표시된 성능 프로필status필드 아래에도 성능 저하 상태가 표시되어야 합니다.oc describe performanceprofiles performance
# oc describe performanceprofiles performanceCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
13.6. Red Hat 지원을 받기 위한 짧은 대기 시간 튜닝 디버깅 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.
must-gather 툴을 사용하면 노드 튜닝과 NUMA 토폴로지, 짧은 대기 시간 설정으로 인한 문제를 디버깅하는 데 필요한 다른 정보를 비롯하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.
즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 짧은 대기 시간 튜닝 둘 다에 대한 진단 정보를 제공하십시오.
13.6.1. must-gather 툴 정보 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather CLI 명령은 다음과 같이 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터 정보를 수집합니다.
- 리소스 정의
- 감사 로그
- 서비스 로그
--image 인수를 포함하여 명령을 실행하는 경우 이미지를 하나 이상 지정할 수 있습니다. 이미지를 지정하면 툴에서 해당 기능 또는 제품과 관련된 데이터를 수집합니다. oc adm must-gather를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 디렉터리에 생성됩니다.
13.6.2. 짧은 대기 시간 튜닝 데이터 수집 정보 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather CLI 명령을 사용하여 다음과 같은 짧은 대기 시간 튜닝과 연관된 기능 및 오브젝트를 포함한 클러스터 정보를 수집합니다.
- Node Tuning Operator 네임스페이스 및 하위 오브젝트.
-
MachineConfigPool및 연관MachineConfig오브젝트. - Node Tuning Operator 및 연관 Tuned 오브젝트.
- Linux Kernel 명령줄 옵션.
- CPU 및 NUMA 토폴로지.
- 기본 PCI 장치 정보 및 NUMA 위치.
must-gather 로 디버깅 정보를 수집하려면 Performance Addon Operator must-gather 이미지를 지정해야 합니다.
--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12.
--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12.
이전 버전의 OpenShift Container Platform에서 Performance Addon Operator는 애플리케이션에 대한 짧은 대기 시간 성능 튜닝을 제공합니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다. 그러나 must-gather 명령을 실행할 때 performance-addon-operator-must-gather 이미지를 계속 사용해야 합니다.
13.6.3. 특정 기능에 대한 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
oc adm must-gather CLI 명령을 --image 또는 --image-stream 인수와 함께 사용하여 특정 기능에 대한 디버깅 정보를 수집할 수 있습니다. must-gather 툴은 여러 이미지를 지원하므로 단일 명령을 실행하여 둘 이상의 기능에 대한 데이터를 수집할 수 있습니다.
특정 기능 데이터 외에도 기본 must-gather 데이터를 수집하려면 --image-stream=openshift/must-gather 인수를 추가하십시오.
이전 버전의 OpenShift Container Platform에서 Performance Addon Operator는 애플리케이션에 대한 짧은 대기 시간 성능 튜닝을 제공합니다. OpenShift Container Platform 4.11에서 이러한 함수는 Node Tuning Operator의 일부입니다. 그러나 must-gather 명령을 실행할 때 performance-addon-operator-must-gather 이미지를 계속 사용해야 합니다.
사전 요구 사항
-
cluster-admin역할을 가진 사용자로 클러스터에 액세스합니다. - OpenShift Container Platform CLI(oc)가 설치되어 있어야 합니다.
프로세스
-
must-gather데이터를 저장하려는 디렉터리로 이동합니다. --image또는--image-stream인수를 하나 이상 사용하여oc adm must-gather명령을 실행합니다. 예를 들어 다음 명령은 기본 클러스터 데이터와 Node Tuning Operator 관련 정보를 모두 수집합니다.oc adm must-gather \ --image-stream=openshift/must-gather \
$ oc adm must-gather \ --image-stream=openshift/must-gather \1 --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.122 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/를 실제 디렉터리 이름으로 바꿉니다.
- Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.
14장. 플랫폼 검증을 위해 대기 시간 테스트 수행 링크 복사링크가 클립보드에 복사되었습니다!
CNF(클라우드 네이티브 네트워크 기능) 테스트 이미지를 사용하여 CNF 워크로드 실행에 필요한 모든 구성 요소가 설치된 CNF 지원 OpenShift Container Platform 클러스터에서 대기 시간 테스트를 실행할 수 있습니다. 대기 시간 테스트를 실행하여 워크로드에 대한 노드 튜닝을 검증합니다.
cnf-tests 컨테이너 이미지는 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 에서 사용할 수 있습니다.
cnf-tests 이미지에는 현재 Red Hat에서 지원하지 않는 여러 테스트도 포함되어 있습니다. Red Hat에서 대기 시간 테스트만 지원합니다.
14.1. 대기 시간 테스트 실행을 위한 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
대기 시간 테스트를 실행하려면 클러스터가 다음 요구 사항을 충족해야 합니다.
- Node Tuning Operator를 사용하여 성능 프로필을 구성했습니다.
- 클러스터에 필요한 모든 CNF 구성을 적용했습니다.
-
클러스터에 기존
MachineConfigPoolCR이 적용되어 있습니다. 기본 작업자 풀은worker-cnf입니다.
14.2. 대기 시간 테스트의 검색 모드 정보 링크 복사링크가 클립보드에 복사되었습니다!
검색 모드를 사용하여 구성을 변경하지 않고 클러스터의 기능을 검증합니다. 기존 환경 구성이 테스트에 사용됩니다. 테스트에서는 필요한 구성 항목을 찾고 해당 항목을 사용하여 테스트를 실행할 수 있습니다. 특정 테스트를 실행하는 데 필요한 리소스를 찾을 수 없는 경우에는 테스트를 건너뛰고 사용자에게 적절한 메시지를 제공합니다. 테스트가 완료되면 사전 구성된 구성 항목을 정리하지 않으며 테스트 환경을 다른 테스트 실행에 즉시 사용할 수 있습니다.
대기 시간 테스트를 실행하는 경우 항상 -e DISCOVERY_MODE=true 로 테스트를 실행하고 -ginkgo.focus 를 적절한 대기 시간 테스트로 설정합니다. 검색 모드에서 대기 시간 테스트를 실행하지 않으면 테스트 실행에 의해 기존 라이브 클러스터 성능 프로필 구성이 수정됩니다.
테스트 중 사용되는 노드 제한
NODES_SELECTOR 환경 변수(예: -e NODES_SELECTOR=node-role.kubernetes.io/worker-cnf )를 지정하여 테스트가 실행되는 노드를 제한할 수 있습니다. 테스트에서 생성된 리소스는 라벨이 일치하는 노드로 제한됩니다.
기본 작업자 풀을 재정의하려면 -e ROLE_WORKER_CNF=<custom_worker_pool > 변수를 적절한 레이블을 지정하는 명령에 전달합니다.
14.3. 대기 시간 측정 링크 복사링크가 클립보드에 복사되었습니다!
cnf-tests 이미지는 세 가지 툴을 사용하여 시스템의 대기 시간을 측정합니다.
-
hwlatdetect -
cyclictest -
oslat
각 도구에는 특정 용도가 있습니다. 안정적인 테스트 결과 달성을 위해 순서대로 툴을 사용합니다.
- hwlatdetect
-
베어 메탈 하드웨어에서 수행할 수 있는 기준을 측정합니다. 다음 대기 시간 테스트를 진행하기 전에
hwlatdetect에서 보고한 대기 시간이 운영 체제 튜닝을 통해 하드웨어 대기 시간 급증을 수정할 수 없기 때문에 필요한 임계값을 충족하는지 확인합니다. - cyclictest
-
hwlatdetect가 검증을 통과한 후 실시간 커널 스케줄러 대기 시간을 확인합니다.cyclictest툴은 반복된 타이머를 예약하고 원하는 트리거 시간과 실제 트리거 시간 간의 차이를 측정합니다. 차이점은 인터럽트 또는 프로세스 우선순위로 인한 튜닝과 관련된 기본 문제를 발견할 수 있습니다. 툴은 실시간 커널에서 실행해야 합니다. - oslat
- CPU 집약적 DPDK 애플리케이션과 유사하게 작동하며 CPU 사용량이 많은 데이터 처리를 시뮬레이션하는 사용 중인 루프에 대한 모든 중단 및 중단을 측정합니다.
테스트에서는 다음과 같은 환경 변수를 도입합니다.
| 환경 변수 | 설명 |
|---|---|
|
| 테스트 실행을 시작한 후 시간(초)을 지정합니다. 변수를 사용하여 CPU 관리자 조정 루프를 허용하여 기본 CPU 풀을 업데이트할 수 있습니다. 기본값은 0입니다. |
|
| 대기 시간 테스트를 실행하는 Pod에서 사용하는 CPU 수를 지정합니다. 변수를 설정하지 않으면 기본 구성에 모든 분리된 CPU가 포함됩니다. |
|
| 대기 시간 테스트를 실행해야 하는 시간(초)을 지정합니다. 기본값은 300초입니다. |
|
|
워크로드 및 운영 체제에 대해 허용되는 최대 하드웨어 대기 시간(마이크로초)을 지정합니다. |
|
|
|
|
|
|
|
| microseconds에서 허용되는 최대 대기 시간을 지정하는 통합 변수입니다. 사용 가능한 모든 대기 시간 툴에 적용됩니다. |
|
|
테스트 실행 여부를 나타내는 부울 매개변수입니다. |
대기 시간 툴과 관련된 변수가 통합 변수보다 우선합니다. 예를 들어 OSLAT_MAXIMUM_LATENCY 가 30 마이크로초로 설정되고 MAXIMUM_LATENCY 가 10 마이크로초로 설정된 경우 oslat 테스트가 최대 허용 가능한 대기 시간 30마이크로 실행됩니다.
14.4. 대기 시간 테스트 실행 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 대기 시간 테스트를 실행하여 CNF(클라우드 네이티브 네트워크 기능) 워크로드에 대한 노드 튜닝을 검증합니다.
항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.
podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.
절차
kubeconfig파일이 포함된 디렉터리에서 쉘 프롬프트를 엽니다.테스트 이미지에 현재 디렉터리에
kubeconfig파일 및 볼륨을 통해 마운트된 관련$KUBECONFIG환경 변수를 제공합니다. 이를 통해 실행 중인 컨테이너에서 컨테이너 내부에서kubeconfig파일을 사용할 수 있습니다.다음 명령을 입력하여 대기 시간 테스트를 실행합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
선택 사항: Append
-ginkgo.dryRun을 사용하여 시험 실행 모드에서 대기 시간 테스트를 실행합니다. 이 명령은 테스트 실행을 확인하는 데 유용합니다. -
선택 사항: Append
-ginkgo.v를 사용하여 향상된 동사를 사용하여 테스트를 실행합니다. 선택 사항: 특정 성능 프로필에 대해 대기 시간 테스트를 실행하려면 다음 명령을 실행하여 적절한 값을 대체합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e FEATURES=performance -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ -e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e FEATURES=performance -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ -e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <performance_profile>
- 는 대기 시간 테스트를 실행할 성능 프로필의 이름입니다.
중요유효한 대기 시간 테스트 결과의 경우 최소 12 시간 동안 테스트를 실행합니다.
14.4.1. hwlatdetect 실행 링크 복사링크가 클립보드에 복사되었습니다!
hwlatdetect 툴은 RHEL(Red Hat Enterprise Linux) 8.x의 일반 서브스크립션과 함께 rt-kernel 패키지에서 사용할 수 있습니다.
항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.
podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.
사전 요구 사항
- 클러스터에 실시간 커널이 설치되어 있습니다.
-
고객 포털 인증 정보를 사용하여
registry.redhat.io에 로그인했습니다.
절차
hwlatdetect테스트를 실행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \ -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \ -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect"Copy to Clipboard Copied! Toggle word wrap Toggle overflow hwlatdetect테스트는 10분(600초) 동안 실행됩니다. 최대 관찰 대기 시간이MAXIMUM_LATENCY(20 ECDHEs)보다 작으면 테스트가 성공적으로 실행됩니다.결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.
중요유효한 결과를 얻으려면 테스트가 최소 12 시간 동안 실행되어야 합니다.
실패 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
hwlatdetect 테스트 결과의 예
다음 유형의 결과를 캡처할 수 있습니다.
- 테스트 전체에서 수행된 변경 사항에 대한 영향을 만들기 위해 각 실행 후 수집된 대략적인 결과.
- 최상의 결과 및 구성 설정을 사용하여 대략적인 테스트 집합을 결합합니다.
좋은 결과의 예
hwlatdetect 툴은 샘플이 지정된 임계값을 초과하는 경우에만 출력을 제공합니다.
잘못된 결과의 예
hwlatdetect 의 출력은 여러 샘플이 임계값을 초과함을 보여줍니다. 그러나 동일한 출력은 다음 요인에 따라 다른 결과를 나타낼 수 있습니다.
- 테스트 기간
- CPU 코어 수
- 호스트 펌웨어 설정
다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고하는 대기 시간이 필요한 임계값을 충족하는지 확인합니다. 하드웨어에서 도입된 대기 시간을 수정하려면 시스템 벤더 지원에 문의해야 할 수 있습니다.
모든 대기 시간 급증이 하드웨어와 관련이 있는 것은 아닙니다. 호스트 펌웨어를 튜닝하여 워크로드 요구 사항을 충족해야 합니다. 자세한 내용은 시스템 튜닝의 펌웨어 매개변수 설정을 참조하십시오.
14.4.2. cyclictest 실행 링크 복사링크가 클립보드에 복사되었습니다!
cyclictest 툴은 지정된 CPU에서 실시간 커널 스케줄러 대기 시간을 측정합니다.
항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.
podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.
사전 요구 사항
-
고객 포털 인증 정보를 사용하여
registry.redhat.io에 로그인했습니다. - 클러스터에 실시간 커널이 설치되어 있습니다.
- Node Tuning Operator를 사용하여 클러스터 성능 프로필을 적용했습니다.
절차
cyclictest를 수행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은
cyclictest툴을 10분(600초) 동안 실행합니다. 최대 관찰 대기 시간이MAXIMUM_LATENCY보다 작으면 테스트가 성공적으로 실행됩니다(이 예제에서는 20 ECDHE). 20 ECDHE 이상의 대기 시간 급증은 일반적으로 telco RAN 워크로드에는 허용되지 않습니다.결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.
중요유효한 결과를 얻으려면 테스트가 최소 12 시간 동안 실행되어야 합니다.
실패 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
cyclictest 결과 예
동일한 출력은 다른 워크로드에 대한 다른 결과를 나타낼 수 있습니다. 예를 들어 최대 18ECDHE의 급증은 4G DU 워크로드에는 허용되지만 5G DU 워크로드에서는 사용할 수 없습니다.
좋은 결과의 예
잘못된 결과의 예
14.4.3. oslat 실행 링크 복사링크가 클립보드에 복사되었습니다!
oslat 테스트는 CPU 집약적 DPDK 애플리케이션을 시뮬레이션하고 모든 중단 및 중단을 측정하여 클러스터가 CPU의 과도한 데이터 처리를 처리하는 방법을 테스트합니다.
항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.
podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.
사전 요구 사항
-
고객 포털 인증 정보를 사용하여
registry.redhat.io에 로그인했습니다. - Node Tuning Operator를 사용하여 클러스터 성능 프로필을 적용했습니다.
프로세스
oslat테스트를 수행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=worker-cnf \ -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat"Copy to Clipboard Copied! Toggle word wrap Toggle overflow LATENCY_TEST_CPUS는oslat명령으로 테스트할 CPU 목록을 지정합니다.이 명령은
oslat툴을 10분(600초) 동안 실행합니다. 최대 관찰 대기 시간이MAXIMUM_LATENCY(20 ECDHEs)보다 작으면 테스트가 성공적으로 실행됩니다.결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.
중요유효한 결과를 얻으려면 테스트가 최소 12 시간 동안 실행되어야 합니다.
실패 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 이 예에서 측정된 대기 시간은 최대 허용된 값 외부에 있습니다.
14.5. 대기 시간 테스트 실패 보고서 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 JUnit 대기 시간 테스트 출력 및 테스트 실패 보고서를 생성합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다.
프로세스
--report매개변수를 보고서가 덤프되는 경로와 함께 전달하여 문제 해결을 위한 클러스터 상태 및 리소스에 대한 정보가 포함된 테스트 실패 보고서를 생성합니다.podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig -e DISCOVERY_MODE=true -e FEATURES=performance \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh --report <report_folder_path> \ -ginkgo.focus="\[performance\]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig -e DISCOVERY_MODE=true -e FEATURES=performance \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh --report <report_folder_path> \ -ginkgo.focus="\[performance\]\ Latency\ Test"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <report_folder_path>
- 보고서가 생성된 폴더의 경로입니다.
14.6. JUnit 대기 시간 테스트 보고서 생성 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 JUnit 대기 시간 테스트 출력 및 테스트 실패 보고서를 생성합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다.
프로세스
보고서가 덤프되는 경로와 함께
--junit매개변수를 전달하여 JUnit 호환 XML 보고서를 생성합니다.podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junitdest:<junit_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig -e DISCOVERY_MODE=true -e FEATURES=performance \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh --junit <junit_folder_path> \ -ginkgo.focus="\[performance\]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junitdest:<junit_folder_path> \ -e KUBECONFIG=/kubeconfig/kubeconfig -e DISCOVERY_MODE=true -e FEATURES=performance \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh --junit <junit_folder_path> \ -ginkgo.focus="\[performance\]\ Latency\ Test"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <junit_folder_path>
- junit 보고서가 생성되는 폴더의 경로입니다.
14.7. 단일 노드 OpenShift 클러스터에서 대기 시간 테스트 실행 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행할 수 있습니다.
항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.
podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다.
프로세스
단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행하려면 다음 명령을 실행합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=master \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e DISCOVERY_MODE=true -e FEATURES=performance -e ROLE_WORKER_CNF=master \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고master가 노드가 속하는 유일한 시스템 풀이므로
ROLE_WORKER_CNF=master가 필요합니다. 대기 시간 테스트에 필요한MachineConfigPool을 설정하는 방법에 대한 자세한 내용은 "지시간 테스트 실행을 위한 전제 조건"을 참조하십시오.테스트 모음을 실행한 후에는 모든 무위 리소스가 정리됩니다.
14.8. 연결이 끊긴 클러스터에서 대기 시간 테스트 실행 링크 복사링크가 클립보드에 복사되었습니다!
CNF 테스트 이미지는 연결이 끊긴 클러스터에서 외부 레지스트리에 연결할 수 없는 테스트를 실행할 수 있습니다. 여기에는 두 단계가 필요합니다.
-
cnf-tests이미지를 사용자 연결 해제된 레지스트리에 미러링합니다. - 사용자 연결 해제된 레지스트리의 이미지를 사용하도록 테스트에 지시합니다.
클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링
이미지에 미러 실행 파일이 제공되어 oc 에서 테스트 이미지를 로컬 레지스트리에 미러링하는 데 필요한 입력을 제공합니다.
클러스터에 액세스할 수 있는 임시 머신에서 다음 명령을 실행합니다. registry.redhat.io:
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ /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-rhel8:v4.12 \ /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 DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY="<disconnected_registry>" \ -e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.12" \ /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY="<disconnected_registry>" \ -e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.12" \ /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"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 FEATURES=performance \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 /usr/bin/test-run.sh
$ 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 FEATURES=performance \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 /usr/bin/test-run.shCopy 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=mergeCopy 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 cnftestsCopy 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=cnftestsCopy 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=cnftestsCopy 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.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이미지 미러링을 수행합니다.
podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:4.12 \ /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-rhel8:4.12 \ /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 DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests \ cnf-tests-local:latest /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ -e DISCOVERY_MODE=true -e FEATURES=performance -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests \ cnf-tests-local:latest /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다른 테스트 이미지 세트 미러링
선택적으로 대기 시간 테스트를 위해 미러링된 기본 업스트림 이미지를 변경할 수 있습니다.
프로세스
mirror명령은 기본적으로 업스트림 이미지를 미러링합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 파일을
mirror명령에 전달합니다. 예를 들어images.json으로 로컬로 저장합니다. 다음 명령을 사용하면 로컬 경로가 컨테이너 내/kubeconfig에 마운트되어 mirror 명령에 전달될 수 있습니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 /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-rhel8:v4.12 /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
14.9. cnf-tests 컨테이너로 오류 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
대기 시간 테스트를 실행하려면 cnf-tests 컨테이너 내에서 클러스터에 액세스할 수 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다.
프로세스
다음 명령을 실행하여
cnf-tests컨테이너 내부에서 클러스터에 액세스할 수 있는지 확인합니다.podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ oc get nodes
$ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \ registry.redhat.io/openshift4/cnf-tests-rhel8:v4.12 \ oc get nodesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령이 작동하지 않으면 DNS, MTU 크기 또는 방화벽 액세스와 관련된 오류가 발생할 수 있습니다.
15장. 작업자 대기 시간 프로필을 사용하여 대기 시간이 높은 환경에서 클러스터 안정성 개선 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자가 플랫폼 확인을 위해 대기 시간 테스트를 수행한 경우 대기 시간이 긴 경우 안정성을 보장하기 위해 클러스터의 작동을 조정해야 할 수 있습니다. 클러스터 관리자는 파일에 기록된 하나의 매개 변수만 변경해야 합니다. 이 매개변수는 감독자 프로세스가 상태를 읽고 클러스터의 상태를 해석하는 방법에 영향을 미치는 매개변수 4개를 제어합니다. 하나의 매개변수만 변경하면 지원 가능한 방식으로 클러스터 튜닝이 제공됩니다.
Kubelet 프로세스는 클러스터 상태를 모니터링하기 위한 시작점을 제공합니다. Kubelet 은 OpenShift Container Platform 클러스터의 모든 노드에 대한 상태 값을 설정합니다. Kubernetes Controller Manager(kube 컨트롤러)는 기본적으로 10초마다 상태 값을 읽습니다. kube 컨트롤러에서 노드 상태 값을 읽을 수 없는 경우 구성된 기간이 지난 후 해당 노드와의 연결이 끊어집니다. 기본 동작은 다음과 같습니다.
-
컨트롤 플레인의 노드 컨트롤러는 노드 상태를
Unhealthy로 업데이트하고 노드Ready조건 'Unknown'을 표시합니다. - 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다.
-
Node Lifecycle Controller는
NoExecute효과가 있는node.kubernetes.io/unreachable테인트를 노드에 추가하고 기본적으로 5분 후에 제거하도록 노드에 Pod를 예약합니다.
이 동작은 특히 네트워크 엣지에 노드가 있는 경우 네트워크가 대기 시간 문제가 발생하는 경우 문제가 발생할 수 있습니다. 경우에 따라 네트워크 대기 시간으로 인해 Kubernetes 컨트롤러 관리자에서 정상적인 노드에서 업데이트를 수신하지 못할 수 있습니다. Kubelet 은 노드가 정상이지만 노드에서 Pod를 제거합니다.
이 문제를 방지하려면 작업자 대기 시간 프로필을 사용하여 Kubelet 및 Kubernetes 컨트롤러 관리자가 작업을 수행하기 전에 상태 업데이트를 기다리는 빈도를 조정할 수 있습니다. 이러한 조정은 컨트롤 플레인과 작업자 노드 간의 네트워크 대기 시간이 최적이 아닌 경우 클러스터가 올바르게 실행되도록 하는 데 도움이 됩니다.
이러한 작업자 대기 시간 프로필에는 대기 시간을 높이기 위해 클러스터의 응답을 제어하기 위해 신중하게 조정된 값으로 미리 정의된 세 가지 매개변수 세트가 포함되어 있습니다. 실험적으로 최상의 값을 수동으로 찾을 필요가 없습니다.
클러스터를 설치할 때 또는 언제든지 클러스터 네트워크에서 대기 시간을 늘릴 때 작업자 대기 시간 프로필을 구성할 수 있습니다.
15.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
-
노드를 비정상적으로 표시하고
node.kubernetes.io/not-ready또는node.kubernetes.io/unreachable테인트를 노드에 추가하기 전에 Kubernetes 컨트롤러 관리자가 kubelet에서 업데이트를 기다리는 시간(초)을 지정합니다. - default-not-ready-toleration-seconds
- 해당 노드에서 Pod를 제거하기 전에 Kube API Server Operator가 기다리는 비정상적인 노드를 표시한 후 시간(초)을 지정합니다.
- default-unreachable-toleration-seconds
- 해당 노드에서 Pod를 제거하기 전에 Kube API Server Operator가 대기할 수 없는 노드를 표시한 후 시간(초)을 지정합니다.
다음 Operator는 작업자 대기 시간 프로필에 대한 변경 사항을 모니터링하고 그에 따라 응답합니다.
-
MCO(Machine Config Operator)는 작업자 노드에서
node-status-update-frequency매개변수를 업데이트합니다. -
Kubernetes 컨트롤러 관리자는 컨트롤 플레인 노드에서
node-monitor-grace-period매개변수를 업데이트합니다. -
Kubernetes API Server Operator는 컨트롤 플레인 노드에서
default-not-ready-toleration-seconds및default-unreachable-toleration-seconds매개변수를 업데이트합니다.
기본 구성은 대부분의 경우 작동하지만 OpenShift Container Platform에서는 네트워크에서 평소보다 대기 시간이 더 높은 상황에 대해 두 개의 다른 작업자 대기 시간 프로필을 제공합니다. 세 개의 작업자 대기 시간 프로필은 다음 섹션에 설명되어 있습니다.
- 기본 작업자 대기 시간 프로필
Default프로필을 사용하면 각Kubelet이 10초마다 상태를 업데이트합니다(node-status-update-frequency).Kube Controller Manager는 5초마다Kubelet의 상태를 확인합니다(node-monitor-grace-period).Kubernetes 컨트롤러 관리자는
Kubelet비정상을 고려하기 전에Kubelet에서 상태 업데이트를 40초 동안 기다립니다. Kubernetes 컨트롤러 관리자에서 사용할 수 없는 상태가 없는 경우 노드를node.kubernetes.io/not-ready또는node.kubernetes.io/unreachable테인트로 표시하고 해당 노드에서 Pod를 제거합니다.해당 노드의 Pod에
NoExecute테인트가 있는 경우tolerationSeconds에 따라 Pod가 실행됩니다. Pod에 테인트가 없는 경우 300초(Kube API서버의default-not-ready-toleration-seconds및default-unreachable-toleration-seconds설정)가 제거됩니다.Expand Profile 구성 요소 매개변수 값 기본값
kubelet
node-status-update-frequency10s
kubelet 컨트롤러 관리자
node-monitor-grace-period40s
Kubernetes API Server Operator
default-not-ready-toleration-seconds300s
Kubernetes API Server Operator
default-unreachable-toleration-seconds300s
- 중간 작업자 대기 시간 프로파일
네트워크 대기 시간이 평소보다 약간 높은 경우
MediumUpdateAverageReaction프로필을 사용하십시오.MediumUpdateAverageReaction프로필은 kubelet 업데이트 빈도를 20초로 줄이고 Kubernetes 컨트롤러 관리자가 해당 업데이트를 2분으로 기다리는 기간을 변경합니다. 해당 노드의 Pod 제거 기간이 60초로 단축됩니다. Pod에tolerationSeconds매개변수가 있는 경우 제거는 해당 매개변수로 지정된 기간 동안 기다립니다.Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 2분 정도 기다립니다. 또 다른 순간에 제거 프로세스가 시작됩니다.
Expand Profile 구성 요소 매개변수 값 MediumUpdateAverageReaction
kubelet
node-status-update-frequency20s
kubelet 컨트롤러 관리자
node-monitor-grace-period2m
Kubernetes API Server Operator
default-not-ready-toleration-seconds60s
Kubernetes API Server Operator
default-unreachable-toleration-seconds60s
- 낮은 작업자 대기 시간 프로파일
네트워크 대기 시간이 매우 높은 경우
LowUpdateSlowReaction프로필을 사용합니다.LowUpdateSlowReaction프로필은 kubelet 업데이트 빈도를 1분으로 줄이고 Kubernetes 컨트롤러 관리자가 해당 업데이트를 5분으로 기다리는 기간을 변경합니다. 해당 노드의 Pod 제거 기간이 60초로 단축됩니다. Pod에tolerationSeconds매개변수가 있는 경우 제거는 해당 매개변수로 지정된 기간 동안 기다립니다.Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 5분 정도 기다립니다. 또 다른 순간에 제거 프로세스가 시작됩니다.
Expand Profile 구성 요소 매개변수 값 LowUpdateSlowReaction
kubelet
node-status-update-frequency1m
kubelet 컨트롤러 관리자
node-monitor-grace-period5m
Kubernetes API Server Operator
default-not-ready-toleration-seconds60s
Kubernetes API Server Operator
default-unreachable-toleration-seconds60s
15.2. 클러스터 생성 시 작업자 대기 시간 프로필 구현 링크 복사링크가 클립보드에 복사되었습니다!
설치 프로그램의 구성을 편집하려면 먼저 openshift-install create manifests 명령을 사용하여 기본 노드 매니페스트 및 기타 매니페스트 YAML 파일을 생성해야 합니다. 이 파일 구조는 workerLatencyProfile을 추가하기 전에 존재해야 합니다. 설치 중인 플랫폼에는 다양한 요구 사항이 있을 수 있습니다. 특정 플랫폼에 대한 설명서의 설치 섹션을 참조하십시오.
workerLatencyProfile 은 다음 순서로 매니페스트에 추가해야 합니다.
- 설치에 적합한 폴더 이름을 사용하여 클러스터를 빌드하는 데 필요한 매니페스트를 생성합니다.
-
YAML 파일을 생성하여
config.node를 정의합니다. 파일은manifests디렉터리에 있어야 합니다. -
매니페스트에
workerLatencyProfile을 처음 정의할 때 클러스터 생성 시기본,mediumUpdateAverageReaction또는LowUpdateSlowReaction.
검증
다음은 매니페스트 파일의
spec.workerLatencyProfileDefault값을 보여주는 매니페스트 생성 예제입니다.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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
15.3. 작업자 대기 시간 프로필 사용 및 변경 링크 복사링크가 클립보드에 복사되었습니다!
네트워크 대기 시간을 처리하기 위해 작업자 대기 시간 프로필을 변경하려면 node.config 오브젝트를 편집하여 프로필 이름을 추가합니다. 대기 시간이 증가하거나 감소하면 언제든지 프로필을 변경할 수 있습니다.
한 번에 하나의 작업자 대기 시간 프로필을 이동해야 합니다. 예를 들어 기본 프로필에서 LowUpdateSlowReaction 작업자 대기 시간 프로필로 직접 이동할 수 없습니다. 기본 작업자 대기 시간 프로필에서 먼저 MediumUpdateAverageReaction 프로필로 이동한 다음 LowUpdateSlowReaction 으로 이동해야 합니다. 마찬가지로 Default 프로필로 돌아갈 때 먼저 low 프로필에서 medium 프로필로 이동한 다음 Default 로 이동해야 합니다.
OpenShift Container Platform 클러스터를 설치할 때 작업자 대기 시간 프로필을 구성할 수도 있습니다.
절차
기본 작업자 대기 시간 프로필에서 이동하려면 다음을 수행합니다.
중간 작업자 대기 시간 프로파일로 이동합니다.
node.config오브젝트를 편집합니다.oc edit nodes.config/cluster
$ oc edit nodes.config/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 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/clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow spec.workerLatencyProfile값을LowUpdateSlowReaction으로 변경합니다.node.config오브젝트의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 낮은 작업자 대기 시간 정책 사용을 지정합니다.
변경 사항이 적용되므로 각 작업자 노드에서 예약이 비활성화됩니다.
검증
모든 노드가
Ready상태로 돌아 오면 다음 명령을 사용하여 Kubernetes 컨트롤러 관리자를 확인하여 적용되었는지 확인할 수 있습니다.oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5
$ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 프로필이 적용되고 활성 상태가 되도록 지정합니다.
미디어 프로필을 기본값으로 변경하거나 기본값을 medium로 변경하려면 node.config 오브젝트를 편집하고 spec.workerLatencyProfile 매개변수를 적절한 값으로 설정합니다.
15.4. workerLatencyProfile의 결과 값을 표시하는 단계의 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 명령을 사용하여 workerLatencyProfile 의 값을 표시할 수 있습니다.
검증
Kube API Server에서
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-monitorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
node-monitor-grace-period: - 40s
node-monitor-grace-period: - 40sCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kubelet에서
nodeStatusUpdateFrequency값을 확인합니다. 디버그 쉘 내에서/host디렉터리를 root 디렉터리로 설정합니다. 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 nodeStatusUpdateFrequencyCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
“nodeStatusUpdateFrequency”: “10s”
“nodeStatusUpdateFrequency”: “10s”Copy to Clipboard Copied! Toggle word wrap Toggle overflow
이러한 출력은 Worker Latency Profile의 타이밍 변수 집합의 유효성을 검사합니다.
16장. 성능 프로파일 작성 링크 복사링크가 클립보드에 복사되었습니다!
Performance Profile Creator(PPC)와 이를 사용하여 성능 프로필을 만드는 방법을 설명합니다.
현재 cgroup v2에서는 CPU 부하 분산을 비활성화하지 않습니다. 따라서 cgroup v2가 활성화된 경우 성능 프로필에서 원하는 동작을 얻지 못할 수 있습니다. 성능 프로필을 사용하는 경우에는 cgroup v2를 활성화하는 것은 권장되지 않습니다.
16.1. 성능 프로파일 작성툴 정보 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile Creator)는 성능 프로필을 생성하는 데 사용되는 Node Tuning Operator와 함께 제공되는 명령줄 툴입니다. 이 툴은 클러스터의 must-gather 데이터와 여러 사용자가 제공하는 프로필 인수를 사용합니다. PPC는 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
툴은 다음 방법 중 하나로 실행됩니다.
-
podman호출 - 래퍼 스크립트 호출
16.1.1. must-gather 명령을 사용하여 클러스터에 대한 데이터 수집 링크 복사링크가 클립보드에 복사되었습니다!
PPC(Performance Profile creator) 툴에는 must-gather 데이터가 필요합니다. 클러스터 관리자는 must-gather 명령을 실행하여 클러스터에 대한 정보를 캡처합니다.
이전 버전의 OpenShift Container Platform에서 Performance Addon Operator는 애플리케이션에 대한 짧은 대기 시간 성능 튜닝을 제공합니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다. 그러나 must-gather 명령을 실행할 때 performance-addon-operator-must-gather 이미지를 계속 사용해야 합니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. -
Performance Addon Operator에 액세스할 수 있는 경우 이미지를
수집해야 합니다. -
OpenShift CLI(
oc)가 설치되어 있습니다.
절차
선택 사항: 레이블과 일치하는 머신 구성 풀이 있는지 확인합니다.
oc describe mcp/worker-rt
$ oc describe mcp/worker-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rt
Name: worker-rt Namespace: Labels: machineconfiguration.openshift.io/role=worker-rtCopy to Clipboard Copied! Toggle word wrap Toggle overflow 일치하는 라벨이 없는 경우 MCP 이름과 일치하는 MCP(Machine config pool)의 라벨을 추가합니다.
oc label mcp <mcp_name> machineconfiguration.openshift.io/role=<mcp_name>
$ oc label mcp <mcp_name> machineconfiguration.openshift.io/role=<mcp_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
must-gather데이터를 저장하려는 디렉터리로 이동합니다. 클러스터에서
must-gather를 실행합니다.oc adm must-gather --image=<PAO_must_gather_image> --dest-dir=<dir>
$ oc adm must-gather --image=<PAO_must_gather_image> --dest-dir=<dir>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고must-gather명령은performance-addon-operator-must-gather이미지를 사용하여 실행해야 합니다. 출력을 선택적으로 압축할 수 있습니다. Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.예제
oc adm must-gather --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12 --dest-dir=<path_to_must-gather>/must-gather
$ oc adm must-gather --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.12 --dest-dir=<path_to_must-gather>/must-gatherCopy to Clipboard Copied! Toggle word wrap Toggle overflow must-gather디렉터리에서 압축 파일을 만듭니다.tar cvaf must-gather.tar.gz must-gather/
$ tar cvaf must-gather.tar.gz must-gather/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
16.1.2. podman을 사용하여 Performance Profile Creator 실행 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 관리자는 podman 및 Performance Profile Creator를 실행하여 성능 프로필을 만들 수 있습니다.
사전 요구 사항
-
cluster-admin역할의 사용자로 클러스터에 액세스할 수 있어야 합니다. - 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
-
podman및 OpenShift CLI(oc)가 설치된 노드가 있습니다. - Node Tuning Operator 이미지에 액세스합니다.
절차
머신 구성 풀을 확인합니다.
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker-cnf rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22h
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker-cnf rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22hCopy to Clipboard Copied! Toggle word wrap Toggle overflow Podman을 사용하여
registry.redhat.io에 인증합니다.podman login registry.redhat.io
$ podman login registry.redhat.ioCopy to Clipboard Copied! Toggle word wrap Toggle overflow Username: <username> Password: <password>
Username: <username> 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-operator:v4.12 -h
$ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 검색 모드에서 Performance Profile Creator 툴을 실행합니다.
참고검색 모드는
must-gather의 출력을 사용하여 클러스터를 검사합니다. 생성된 출력에는 다음에 대한 정보가 포함됩니다.- 할당된 CPU ID로 NUMA 셀 파티셔닝
- 하이퍼스레딩 활성화 여부
이 정보를 사용하여 Performance Profile Creator 툴에 제공된 일부 인수에 대해 적절한 값을 설정할 수 있습니다.
podman run --entrypoint performance-profile-creator -v <path_to_must-gather>/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 --info log --must-gather-dir-path /must-gather
$ podman run --entrypoint performance-profile-creator -v <path_to_must-gather>/must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 --info log --must-gather-dir-path /must-gatherCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고이 명령은 Performance Profile Creator 툴을
podman의 새 진입점으로 사용합니다. 호스트의must-gather데이터를 컨테이너 이미지에 매핑하고 필요한 사용자 제공 프로필 인수를 호출하여my-performance-profile.yaml파일을 생성합니다.-v옵션은 다음 중 하나로 설정할 수 있습니다.-
must-gather출력 디렉터리 -
must-gather압축 해제된 tarball이 포함된 기존 디렉터리
info옵션에는 출력 형식을 지정하는 값이 필요합니다. 가능한 값은 log 및 JSON입니다. JSON 형식은 디버깅을 위해 예약되어 있습니다.podman을 실행합니다.podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 --mcp-name=worker-cnf --reserved-cpu-count=4 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=6 > my-performance-profile.yaml
$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 --mcp-name=worker-cnf --reserved-cpu-count=4 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=6 > my-performance-profile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Performance Profile Creator 인수는 Performance Profile Creator 인수 테이블에 표시됩니다. 다음 인수가 필요합니다.
-
reserved-cpu-count -
mcp-name -
rt-kernel
이 예제의
mcp-name인수는oc get mcp명령의 출력에 따라worker-cnf로 설정됩니다. 단일 노드 OpenShift는--mcp-name=master를 사용합니다.-
생성된 YAML 파일을 검토합니다.
cat my-performance-profile.yaml
$ cat my-performance-profile.yamlCopy 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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.1.2.1. podman을 실행하여 성능 프로파일을 만드는 방법 링크 복사링크가 클립보드에 복사되었습니다!
다음 예제에서는 podman을 실행하여 NUMA 노드 간에 분할될 예약된 20개의 CPU가 있는 성능 프로필을 생성하는 방법을 보여줍니다.
노드 하드웨어 구성:
- 80 CPU
- 하이퍼 스레딩 활성화
- 두 개의 NUMA 노드
- 짝수 번호의 CPU는 NUMA 노드 0에서 실행되고 홀수 번호의 CPU는 NUMA 노드 1에서 실행
podman을 실행하여 성능 프로필을 생성합니다.
podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=true --must-gather-dir-path /must-gather > my-performance-profile.yaml
$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.12 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=true --must-gather-dir-path /must-gather > my-performance-profile.yaml
생성된 프로필은 다음 YAML에 설명되어 있습니다.
이 경우 NUMA 노드 0에 CPU 10개가 예약되고 NUMA 노드 1에 CPU 10개가 예약됩니다.
16.1.3. Performance Profile Creator 래퍼 스크립트 실행 링크 복사링크가 클립보드에 복사되었습니다!
성능 프로필 래퍼 스크립트는 PPC(Performance Profile Creator) 툴의 실행을 간소화합니다. podman 실행과 관련된 복잡성을 숨기고 매핑 디렉터리를 지정하면 성능 프로필을 만들 수 있습니다.
사전 요구 사항
- Node Tuning Operator 이미지에 액세스합니다.
-
must-gathertarball에 액세스합니다.
절차
예를 들어 다음과 같이
run-perf-profile-creator.sh라는 이름의 파일을 로컬 시스템에 생성합니다vi run-perf-profile-creator.sh
$ vi run-perf-profile-creator.shCopy 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.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항:
run-perf-profile-creator.sh명령 사용을 표시합니다../run-perf-profile-creator.sh -h
$ ./run-perf-profile-creator.sh -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예상 출력
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고두 가지 유형의 인수가 있습니다.
-
래퍼 인수 즉
-h,-p및-t - PPC 인수
-
래퍼 인수 즉
검색 모드에서 performance profile creator 툴을 실행합니다.
참고검색 모드는
must-gather의 출력을 사용하여 클러스터를 검사합니다. 생성된 출력에는 다음에 대한 정보가 포함됩니다.- 할당된 CPU ID로 NUMA 셀 파티션을 분할
- 하이퍼스레딩 활성화 여부
이 정보를 사용하여 Performance Profile Creator 툴에 제공된 일부 인수에 대해 적절한 값을 설정할 수 있습니다.
./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --info=log
$ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --info=logCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고info옵션에는 출력 형식을 지정하는 값이 필요합니다. 가능한 값은 log 및 JSON입니다. JSON 형식은 디버깅을 위해 예약되어 있습니다.머신 구성 풀을 확인합니다.
oc get mcp
$ oc get mcpCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker-cnf rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22h
NAME CONFIG UPDATED UPDATING DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE master rendered-master-acd1358917e9f98cbdb599aea622d78b True False False 3 3 3 0 22h worker-cnf rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826 False True False 2 1 1 0 22hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 성능 프로파일을 생성합니다.
./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=2 --rt-kernel=true > my-performance-profile.yaml
$ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=2 --rt-kernel=true > my-performance-profile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고Performance Profile Creator 인수는 Performance Profile Creator 인수 테이블에 표시됩니다. 다음 인수가 필요합니다.
-
reserved-cpu-count -
mcp-name -
rt-kernel
이 예제의
mcp-name인수는oc get mcp명령의 출력에 따라worker-cnf로 설정됩니다. 단일 노드 OpenShift는--mcp-name=master를 사용합니다.-
생성된 YAML 파일을 검토합니다.
cat my-performance-profile.yaml
$ cat my-performance-profile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 생성된 프로필을 적용합니다.
참고프로필을 적용하기 전에 Node Tuning Operator를 설치합니다.
oc apply -f my-performance-profile.yaml
$ oc apply -f my-performance-profile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
16.1.4. Performance Profile Creator 인수 링크 복사링크가 클립보드에 복사되었습니다!
| 인수 | 설명 |
|---|---|
|
| 하이퍼스레딩을 비활성화합니다.
가능한 값:
기본값: 주의
이 인수가 |
|
|
이는 클러스터 정보를 캡처하며 검색 모드에서만 사용됩니다. 검색 모드에서는 가능한 값은 다음과 같습니다.
기본값: |
|
|
대상 머신에 해당하는 MCP 이름 (예: |
|
| 디렉터리 경로를 수집해야 합니다. 이 매개 변수는 필수입니다.
사용자가 래퍼 스크립트 |
|
| 오프라인 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]
|
|
| 전력 소비 모드입니다. 가능한 값은 다음과 같습니다.
기본값: |
|
|
Pod 전원 관리당 활성화.
가능한 값:
기본값: |
|
|
생성할 성능 프로파일의 이름입니다. 기본값: |
|
| 예약된 CPU 수입니다. 이 매개 변수는 필수입니다. 참고 이것은 자연수여야 합니다. 0 값은 허용되지 않습니다. |
|
| 실시간 커널을 활성화합니다. 이 매개 변수는 필수입니다.
가능한 값: |
|
| NUMA 노드에서 예약된 CPU를 분할합니다.
가능한 값:
기본값: |
|
| 생성할 성능 프로필의 Kubelet Topology Manager 정책입니다. 가능한 값은 다음과 같습니다.
기본값: |
|
| DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.
가능한 값:
기본값: |
16.2. 성능 프로필 참조 링크 복사링크가 클립보드에 복사되었습니다!
16.2.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 키에 적합한 값을 삽입합니다.
성능 프로필을 생성하고 사용하는 방법을 알아보려면 OpenShift Container Platform 설명서의 "확장성 및 성능" 섹션의 "성능 프로필 생성" 페이지를 참조하십시오.
17장. 단일 노드 OpenShift에서 워크로드 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 배포와 같은 리소스가 제한적인 환경에서는 워크로드 파티셔닝을 사용하여 예약된 CPU 세트에서 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 분리합니다.
단일 노드 OpenShift에서 클러스터 관리에 필요한 최소 예약된 CPU 수는 4개의 CPU HT(Hyper-Threads)입니다. 워크로드 파티셔닝을 사용하면 클러스터 관리 Pod 세트와 클러스터 관리 워크로드 파티션에 포함하기 위한 일반적인 애드온 Operator 세트에 주석을 답니다. 이러한 Pod는 일반적으로 최소 크기 CPU 구성 내에서 작동합니다. 최소 클러스터 관리 Pod 세트 이외의 추가 Operator 또는 워크로드에 추가 CPU를 워크로드 파티션에 추가해야 합니다.
워크로드 파티셔닝은 표준 Kubernetes 스케줄링 기능을 사용하여 사용자 워크로드를 플랫폼 워크로드에서 격리합니다.
다음은 워크로드 파티셔닝에 필요한 구성의 개요입니다.
-
/etc/crio/crio.conf.d/01-workload-partitioning을 사용하는 워크로드 파티셔닝은 OpenShift Container Platform 인프라 Pod를 정의된cpuset구성에 고정합니다. 성능 프로필은 systemd 및 kubelet과 같은 클러스터 서비스를
spec.cpu.reserved필드에 정의된 CPU에 고정합니다.참고Node Tuning Operator를 사용하면 노드의 전체 워크로드 파티션 구성을 위해 시스템 수준 앱도 고정하도록 성능 프로필을 구성할 수 있습니다.
-
성능 프로필
spec.cpu.reserved필드에 지정하는 CPU와 워크로드 파티셔닝cpuset필드가 일치해야 합니다.
워크로드 파티셔닝에는 정의된 각 CPU 풀 또는 워크로드 유형에 대해 확장된 < workload-type>. workload.openshift.io/cores 리소스가 도입되었습니다. kubelet은 해당 리소스 내의 풀에 할당된 Pod의 리소스 및 CPU 요청을 알립니다. 워크로드 분할이 활성화되면 < workload-type>.workload.openshift.io/cores 리소스에서 기본 CPU 풀이 아닌 호스트의 CPU 용량에 액세스할 수 있습니다.
18장. Node Observability Operator를 사용하여 CRI-O 및 Kubelet 프로파일링 데이터 요청 링크 복사링크가 클립보드에 복사되었습니다!
Node Observability Operator는 작업자 노드의 CRI-O 및 Kubelet 프로파일링 데이터를 수집하고 저장합니다. 프로파일링 데이터를 쿼리하여 CRI-O 및 Kubelet 성능 추세를 분석하고 성능 관련 문제를 디버깅할 수 있습니다.
Node Observability Operator는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
18.1. Node Observability Operator의 워크플로 링크 복사링크가 클립보드에 복사되었습니다!
다음 워크플로우에서는 Node Observability Operator를 사용하여 프로파일링 데이터를 쿼리하는 방법에 대해 간단히 설명합니다.
- OpenShift Container Platform 클러스터에 노드 Observability Operator를 설치합니다.
- NodeObservability 사용자 정의 리소스를 생성하여 선택한 작업자 노드에서 CRI-O 프로파일링을 활성화합니다.
- 프로파일링 쿼리를 실행하여 프로파일링 데이터를 생성합니다.
18.2. 노드 Observability Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
노드 Observability Operator는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 Node Observability Operator를 설치할 수 있습니다.
18.2.1. CLI를 사용하여 노드 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-operatorCopy 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 9hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
node-observability-operator네임스페이스를 생성합니다.oc new-project node-observability-operator
$ oc new-project node-observability-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow OperatorGroup오브젝트 YAML 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Subscription오브젝트 YAML 파일을 생성하여 Operator에 네임스페이스를 등록합니다.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-dt54wCopy 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
COMPLETECopy to Clipboard Copied! Toggle word wrap Toggle overflow Node Observability Operator가 실행 중인지 확인합니다.
oc get deploy -n node-observability-operator
$ oc get deploy -n node-observability-operatorCopy 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 40hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
18.2.2. 웹 콘솔을 사용하여 노드 Observability Operator 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔에서 노드 Observability Operator를 설치할 수 있습니다.
사전 요구 사항
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다. - OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.
절차
- OpenShift Container Platform 웹 콘솔에 로그인합니다.
- Administrator의 탐색 패널에서 Operator → OperatorHub 를 확장합니다.
- All items 필드에 Node Observability Operator 를 입력하고 Node Observability Operator 타일을 선택합니다.
- 설치를 클릭합니다.
Operator 설치 페이지에서 다음 설정을 구성합니다.
- 업데이트 채널 영역에서 alpha 를 클릭합니다.
- 설치 모드 영역에서 클러스터의 특정 네임스페이스를 클릭합니다.
- 설치된 네임스페이스 목록에서 목록에서 node-observability-operator 를 선택합니다.
- 승인 업데이트 영역에서 자동 을 선택합니다.
- 설치를 클릭합니다.
검증
- 관리자의 탐색 패널에서 Operator → 설치된 Operator 를 확장합니다.
- Node Observability Operator가 Operator 목록에 나열되어 있는지 확인합니다.
18.3. 노드 Observability 사용자 정의 리소스 생성 링크 복사링크가 클립보드에 복사되었습니다!
프로파일링 쿼리를 실행하기 전에 NodeObservability CR(사용자 정의 리소스)을 생성하고 실행해야 합니다. NodeObservability CR을 실행하면 필요한 머신 구성 및 머신 구성 풀 CR을 생성하여 nodeSelector 와 일치하는 작업자 노드에서 CRI-O 프로파일링을 활성화합니다.
작업자 노드에서 CRI-O 프로파일링이 활성화되지 않으면 NodeObservabilityMachineConfig 리소스가 생성됩니다. NodeObservability CR에 지정된 nodeSelector 와 일치하는 작업자 노드가 다시 시작됩니다. 이 작업을 완료하는 데 10분 이상 걸릴 수 있습니다.
kubelet 프로필은 기본적으로 활성화되어 있습니다.
노드의 CRI-O unix 소켓은 에이전트 pod에 마운트되어 에이전트가 CRI-O와 통신하여 pprof 요청을 실행할 수 있습니다. 마찬가지로 kubelet-serving-ca 인증서 체인이 에이전트 pod에 마운트되어 에이전트와 노드의 kubelet 끝점 간에 안전하게 통신할 수 있습니다.
사전 요구 사항
- 노드 Observability Operator가 설치되어 있습니다.
- OpenShift CLI(oc)가 설치되어 있습니다.
-
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다.
절차
다음 명령을 실행하여 OpenShift Container Platform CLI에 로그인합니다.
oc login -u kubeadmin https://<HOSTNAME>:6443
$ oc login -u kubeadmin https://<HOSTNAME>:6443Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
node-observability-operator네임스페이스로 다시 전환합니다.oc project node-observability-operator
$ oc project node-observability-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 텍스트가 포함된
nodeobservability.yaml이라는 CR 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeObservabilityCR을 실행합니다.oc apply -f nodeobservability.yaml
oc apply -f nodeobservability.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
nodeobservability.olm.openshift.io/cluster created
nodeobservability.olm.openshift.io/cluster createdCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NodeObservabilityCR의 상태를 검토합니다.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 이유가
Ready이고 상태가True인 경우NodeObservabilityCR 실행이 완료됩니다.
18.4. 프로파일링 쿼리 실행 링크 복사링크가 클립보드에 복사되었습니다!
프로파일링 쿼리를 실행하려면 NodeObservabilityRun 리소스를 생성해야 합니다. 프로파일링 쿼리는 30초 동안 CRI-O 및 Kubelet 프로파일링 데이터를 가져오는 차단 작업입니다. 프로파일링 쿼리가 완료되면 컨테이너 파일 시스템 /run/node-observability 디렉터리 내에서 프로파일링 데이터를 검색해야 합니다. 데이터의 수명은 emptyDir 볼륨을 통해 에이전트 Pod에 바인딩되므로 에이전트 Pod가 running 상태인 동안 프로파일링 데이터에 액세스할 수 있습니다.
언제든지 하나의 프로파일링 쿼리만 요청할 수 있습니다.
사전 요구 사항
- 노드 Observability Operator가 설치되어 있습니다.
-
NodeObservabilityCR(사용자 정의 리소스)을 생성했습니다. -
cluster-admin권한이 있는 클러스터에 액세스할 수 있습니다.
절차
다음 텍스트가 포함된
nodeobservabilityrun.yaml이라는NodeObservabilityRun리소스 파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow NodeObservabilityRun리소스를 실행하여 프로파일링 쿼리를 트리거합니다.oc apply -f nodeobservabilityrun.yaml
$ oc apply -f nodeobservabilityrun.yamlCopy 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이고 유형이Finished인 경우 프로파일링 쿼리가 완료됩니다.다음 bash 스크립트를 실행하여 컨테이너의
/run/node-observability경로에서 프로파일링 데이터를 검색합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19장. 네트워크 엣지의 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
19.1. 네트워크 엣지의 문제 링크 복사링크가 클립보드에 복사되었습니다!
엣지 컴퓨팅은 지리적으로 교체된 위치에서 많은 사이트를 관리할 때 복잡한 문제를 초래합니다. zero touch provisioning (ZTP) 및 GitOps를 사용하여 네트워크의 맨 에지에서 사이트를 프로비저닝하고 관리합니다.
19.1.1. 네트워크 엣지의 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
현재 서비스 제공업체는 네트워크 엣지에 인프라를 배포하려고 합니다. 여기에는 중요한 문제가 있습니다.
- 여러 엣지 사이트의 배포를 병렬로 처리하려면 어떻게 해야 합니까?
- 연결이 끊긴 환경에서 사이트를 배포해야 하는 경우 어떻게 됩니까?
- 대규모 클러스터의 라이프사이클을 어떻게 관리합니까?
zero touch provisioning (ZTP) 및 GitOps 는 베어 메탈 장치에 대한 선언적 사이트 정의 및 구성으로 규모에 따라 원격 에지 사이트를 프로비저닝할 수 있으므로 이러한 문제를 해결합니다. 템플릿 또는 오버레이 구성은 CNF 워크로드에 필요한 OpenShift Container Platform 기능을 설치합니다. 설치 및 업그레이드의 전체 라이프사이클은 ZTP 파이프라인을 통해 처리됩니다.
ZTP는 인프라 배포에 GitOps를 사용합니다. GitOps에서는 Git 리포지토리에 저장된 선언적 YAML 파일 및 기타 정의된 패턴을 사용합니다. RHACM(Red Hat Advanced Cluster Management)은 Git 리포지토리를 사용하여 인프라 배포를 구동합니다.
GitOps는 추적 기능, RBAC(역할 기반 액세스 제어) 및 각 사이트의 원하는 상태에 대해 단일 정보 소스를 제공합니다. 확장성 문제는 웹 후크를 통해 Git 수행 및 이벤트 기반 작업에 의해 해결됩니다.
ZTP 파이프라인이 에지 노드에 제공하는 선언적 사이트 정의 및 구성 CR(사용자 정의 리소스)을 생성하여 ZTP 워크플로를 시작합니다.
다음 다이어그램은 멀리 있는 에지 프레임워크에서 ZTP가 작동하는 방식을 보여줍니다.
19.1.2. ZTP를 사용하여 네트워크 에지에서 클러스터 프로비저닝 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management)은 단일 허브 클러스터가 많은 스포크 클러스터를 관리하는 허브 및 스포크 아키텍처의 클러스터를 관리합니다. RHACM 프로비저닝을 실행하는 Hub 클러스터와 RHACM을 설치할 때 배포된 지원 서비스를 사용하여 관리 클러스터를 배포합니다.
지원 서비스는 단일 노드 클러스터, 3 노드 클러스터 또는 베어 메탈에서 실행되는 표준 클러스터에서 OpenShift Container Platform 프로비저닝을 처리합니다.
OpenShift Container Platform에서 베어 메탈 호스트를 프로비저닝하고 유지하기 위해 ZTP를 사용하는 고급 개요는 다음과 같습니다.
- RHACM을 실행하는 허브 클러스터는 OpenShift Container Platform 릴리스 이미지를 미러링하는 OpenShift 이미지 레지스트리를 관리합니다. RHACM은 OpenShift 이미지 레지스트리를 사용하여 관리 클러스터를 프로비저닝합니다.
- Git 리포지토리에 버전이 지정된 YAML 형식 인벤토리 파일에서 베어 메탈 호스트를 관리합니다.
- 호스트를 관리형 클러스터로 프로비저닝할 준비가 되어 있고 RHACM 및 지원 서비스를 사용하여 사이트에 베어 메탈 호스트를 설치할 수 있습니다.
클러스터 설치 및 배포는 초기 설치 단계 및 후속 구성 단계를 포함하는 2단계 프로세스입니다. 다음 다이어그램은 이 워크플로를 보여줍니다.
19.1.3. siteConfig 리소스 및 RHACM을 사용하여 관리형 클러스터 설치 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP는 Git 리포지토리에서 siteConfig CR(사용자 정의 리소스)을 사용하여 OpenShift Container Platform 클러스터를 설치하는 프로세스를 관리합니다. site Config CR에는 설치에 필요한 클러스터별 매개변수가 포함되어 있습니다. 사용자 정의 추가 매니페스트를 포함하여 설치 중에 선택한 구성 CR을 적용하는 옵션이 있습니다.
ZTP GitOps 플러그인 은 siteConfig CR을 처리하여 hub 클러스터에서 CR 컬렉션을 생성합니다. 이로 인해 RHACM(Red Hat Advanced Cluster Management)의 지원 서비스가 트리거되어 베어 메탈 호스트에 OpenShift Container Platform을 설치합니다. hub 클러스터의 이러한 CR에서 설치 상태 및 오류 메시지를 확인할 수 있습니다.
ZTP를 사용하여 수동으로 또는 배치로 단일 클러스터를 프로비저닝할 수 있습니다.
- 단일 클러스터 프로비저닝
-
클러스터에 대한 단일
SiteConfigCR 및 관련 설치 및 구성 CR을 생성하고 이를 hub 클러스터에 적용하여 클러스터 프로비저닝을 시작합니다. 이는 대규모에 배포하기 전에 CR을 테스트하는 좋은 방법입니다. - 여러 클러스터 프로비저닝
-
Git 리포지토리에서 site
Config 및 관련 CR을 정의하여 최대 400개로 관리되는 클러스터를 설치합니다. ArgoCD는 siteConfigCR을 사용하여 사이트를 배포합니다. RHACM 정책 생성기는 매니페스트를 생성하여 hub 클러스터에 적용합니다. 이렇게 하면 클러스터 프로비저닝 프로세스가 시작됩니다.
19.1.4. 정책 및 PolicyGenTemplate 리소스를 사용하여 관리형 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
zero touch provisioning (ZTP)은 Red Hat Advanced Cluster Management (RHACM)를 사용하여 구성 적용에 정책 기반 거버넌스 접근 방식을 사용하여 클러스터를 구성합니다.
정책 생성기 또는 PolicyGen 은 간결한 템플릿에서 RHACM 정책을 생성할 수 있는 GitOps Operator의 플러그인입니다. 이 툴은 여러 CR을 단일 정책으로 결합할 수 있으며, 함대에 있는 클러스터의 다양한 하위 집합에 적용되는 여러 정책을 생성할 수 있습니다.
확장성 및 클러스터 전체에서 구성 관리의 복잡성을 줄이기 위해 가능한 한 공통성으로 구성 CR을 사용하십시오.
- 가능한 경우 전체 공통 정책을 사용하여 구성 CR을 적용합니다.
- 다음 기본 설정은 그룹 정책에서 가능한 한 많은 나머지 구성을 관리할 클러스터의 논리 그룹을 생성하는 것입니다.
- 구성이 개별 사이트에 고유한 경우 hub 클러스터에서 RHACM 템플릿 정보를 사용하여 사이트별 데이터를 공통 또는 그룹 정책에 삽입합니다. 또는 사이트에 개별 사이트 정책을 적용합니다.
다음 다이어그램에서는 클러스터 배포의 구성 단계에서 정책 생성기가 GitOps 및 RHACM과 상호 작용하는 방법을 보여줍니다.
대규모 클러스터의 경우 일반적으로 클러스터 구성에 높은 수준의 일관성이 있어야 합니다.
다음 권장 정책 구조는 구성 CR을 결합하여 몇 가지 목표를 달성합니다.
- 공통 구성을 한 번 설명하고 함대에 적용합니다.
- 유지 관리 및 관리되는 정책의 수를 최소화합니다.
- 클러스터 변형을 위한 공통 구성의 유연성을 지원합니다.
| 정책 카테고리 | 설명 |
|---|---|
| common |
공통 카테고리에 존재하는 정책은 함의 모든 클러스터에 적용됩니다. Common |
| 그룹 |
그룹 카테고리에 존재하는 정책이 함의 클러스터 그룹에 적용됩니다. 그룹 |
| 사이트 | sites 카테고리에 존재하는 정책은 특정 클러스터 사이트에 적용됩니다. 모든 클러스터는 자체 특정 정책을 유지할 수 있습니다. |
19.2. ZTP용 hub 클러스터 준비 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경에서 RHACM을 사용하려면 필요한 Operator 이미지가 포함된 OpenShift Container Platform 릴리스 이미지 및 OLM(Operator Lifecycle Manager) 카탈로그를 미러링하는 미러 레지스트리를 생성합니다. OLM은 Operator 및 클러스터의 종속 항목을 관리, 설치, 업그레이드합니다. 연결이 끊긴 미러 호스트를 사용하여 베어 메탈 호스트를 프로비저닝하는 데 사용되는 RHCOS ISO 및 RootFS 디스크 이미지를 제공할 수도 있습니다.
19.2.1. telco RAN 4.12 검증 솔루션 소프트웨어 버전 링크 복사링크가 클립보드에 복사되었습니다!
Red Hat Telco radio Access Network (RAN) 버전 4.12 솔루션은 다음 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.
| 제품 | 소프트웨어 버전 |
|---|---|
| Hub 클러스터 OpenShift Container Platform 버전 | 4.12 |
| GitOps ZTP plugin | 4.10, 4.11 또는 4.12 |
| Red Hat Advanced Cluster Management (RHACM) | 2.6, 2.7 |
| Red Hat OpenShift GitOps | 1.9, 1.10 |
| 토폴로지 Aware Lifecycle Manager (TALM) | 4.10, 4.11 또는 4.12 |
19.2.2. 연결이 끊긴 환경에서 GitOps ZTP 설치 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경의 허브 클러스터에서 RHACM (RHACM), Red Hat OpenShift GitOps 및 Topology Aware Lifecycle Manager (TALM)를 사용하여 여러 관리 클러스터의 배포를 관리합니다.
사전 요구 사항
-
OpenShift Container Platform CLI(
oc)를 설치했습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. 클러스터에서 사용할 연결이 끊긴 미러 레지스트리를 구성했습니다.
참고생성한 연결이 끊긴 미러 레지스트리에는 허브 클러스터에서 실행되는 TALM 버전과 일치하는 TALM 백업 버전 및 사전 캐시 이미지가 포함되어야 합니다. 스포크 클러스터는 연결이 끊긴 미러 레지스트리에서 이러한 이미지를 해결할 수 있어야 합니다.
절차
- hub 클러스터에 RHACM을 설치합니다. 연결이 끊긴 환경에서 RHACM 설치를 참조하십시오.
- hub 클러스터에 GitOps 및 TALM을 설치합니다.
19.2.3. 연결이 끊긴 미러 호스트에 RHCOS ISO 및 RootFS 이미지 추가 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management)을 사용하여 연결이 끊긴 환경에서 클러스터를 설치하기 전에 먼저 사용할 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅해야 합니다. 연결이 끊긴 미러를 사용하여 RHCOS 이미지를 호스팅합니다.
사전 요구 사항
- 네트워크에서 RHCOS 이미지 리소스를 호스팅하도록 HTTP 서버를 배포하고 구성합니다. 사용자 컴퓨터에서 HTTP 서버에 액세스하고 사용자가 생성한 시스템에서 액세스할 수 있어야 합니다.
RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 버전과 같거나 그 이하의 버전 중 가장 높은 버전의 이미지를 다운로드해야 합니다. 사용 가능한 경우 OpenShift Container Platform 버전과 일치하는 이미지 버전을 사용합니다. 호스트에 RHCOS를 설치하려면 ISO 및 RootFS 이미지가 필요합니다. 이 설치 유형에서는 RHCOS QCOW2 이미지가 지원되지 않습니다.
절차
- 미러 호스트에 로그인합니다.
mirror.openshift.com 에서 RHCOS ISO 및 RootFS 이미지를 가져옵니다. 예를 들면 다음과 같습니다.
필요한 이미지 이름과 OpenShift Container Platform 버전을 환경 변수로 내보냅니다.
export ISO_IMAGE_NAME=<iso_image_name>
$ export ISO_IMAGE_NAME=<iso_image_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow export ROOTFS_IMAGE_NAME=<rootfs_image_name>
$ export ROOTFS_IMAGE_NAME=<rootfs_image_name>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow export OCP_VERSION=<ocp_version>
$ export OCP_VERSION=<ocp_version>1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 필요한 이미지를 다운로드합니다.
sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.12/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.12/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.12/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}$ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.12/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증 단계
다운로드한 이미지가 연결이 끊긴 미러 호스트에 제공되어 있는지 확인합니다. 예를 들면 다음과 같습니다.
wget http://$(hostname)/${ISO_IMAGE_NAME}$ wget http://$(hostname)/${ISO_IMAGE_NAME}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Saving to: rhcos-4.12.1-x86_64-live.x86_64.iso rhcos-4.12.1-x86_64-live.x86_64.iso- 11%[====> ] 10.01M 4.71MB/s
Saving to: rhcos-4.12.1-x86_64-live.x86_64.iso rhcos-4.12.1-x86_64-live.x86_64.iso- 11%[====> ] 10.01M 4.71MB/sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.4. 지원 서비스 활성화 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management)은 지원 서비스를 사용하여 OpenShift Container Platform 클러스터를 배포합니다. RHACM(Red Hat Advanced Cluster Management)에서 MultiClusterHub Operator를 활성화하면 Helped 서비스가 자동으로 배포됩니다. 그 후에는 모든 네임스페이스를 감시하고 AgentServiceConfig CR(사용자 정의 리소스)을 미러 레지스트리 HTTP 서버에서 호스팅되는 ISO 및 RootFS 이미지에 대한 참조로 업데이트하도록 Provisioning 리소스를 구성해야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - MultiClusterHub가 활성화된 RHACM이 있어야 합니다.
절차
-
프로비저닝리소스를 활성화하여 모든 네임스페이스를 조사하고 연결이 끊긴 환경에 대한 미러를 구성합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오. 다음 명령을 실행하여
AgentServiceConfigCR을 업데이트합니다.oc edit AgentServiceConfig
$ oc edit AgentServiceConfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow CR의
items.spec.osImages필드에 다음 항목을 추가합니다.- cpuArchitecture: x86_64 openshiftVersion: "4.12" rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso- cpuArchitecture: x86_64 openshiftVersion: "4.12" rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img url: https://<mirror-registry>/<path>/rhcos-live.x86_64.isoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <host>
- 대상 미러 레지스트리 HTTP 서버의 FQDN(정규화된 도메인 이름)입니다.
- <path>
- 대상 미러 레지스트리의 이미지 경로입니다.
편집기를 저장하고 종료하여 변경 사항을 적용합니다.
19.2.5. 연결이 끊긴 미러 레지스트리를 사용하도록 hub 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
연결이 끊긴 환경에 연결이 끊긴 미러 레지스트리를 사용하도록 hub 클러스터를 구성할 수 있습니다.
사전 요구 사항
- RHACM(Red Hat Advanced Cluster Management) 2.7이 설치된 연결이 끊긴 허브 클러스터 설치가 있어야 합니다.
-
HTTP 서버에
rootfs및iso이미지를 호스팅했습니다. OpenShift Container Platform 이미지 리포지토리 미러링에 대한 지침은 추가 리소스 섹션을 참조하십시오.
HTTP 서버에 대해 TLS를 활성화하는 경우 루트 인증서가 클라이언트가 신뢰하는 기관에서 서명한지 확인하고 OpenShift Container Platform 허브와 관리형 클러스터와 HTTP 서버 간의 신뢰할 수 있는 인증서 체인을 확인해야 합니다. 신뢰할 수 없는 인증서로 구성된 서버를 사용하면 이미지를 이미지 생성 서비스로 다운로드할 수 없습니다. 신뢰할 수 없는 HTTPS 서버 사용은 지원되지 않습니다.
절차
미러 레지스트리 구성이 포함된
ConfigMap을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ConfigMap네임스페이스는multicluster-engine으로 설정해야 합니다.- 2
- 미러 레지스트리를 생성할 때 사용되는 미러 레지스트리의 인증서입니다.
- 3
- 미러 레지스트리의 구성 파일입니다. 미러 레지스트리 구성은 Discovery 이미지의
/etc/containers/registries.conf에 미러 정보를 추가합니다. 미러 정보는 설치 프로그램에 전달될 때install-config.yaml파일의imageContentSources섹션에 저장됩니다. HUB 클러스터에서 실행 중인 지원 서비스 Pod는 구성된 미러 레지스트리에서 컨테이너 이미지를 가져옵니다. - 4
- 미러 레지스트리의 URL입니다. 미러 레지스트리를 구성할 때
oc adm release mirror명령을 실행하여imageContentSources섹션의 URL을 사용해야 합니다. 자세한 내용은 OpenShift Container Platform 이미지 저장소 미러링 섹션을 참조하십시오.
이 업데이트는 다음과 같이
AgentServiceConfig사용자 정의 리소스에서mirrorRegistryRef를 업데이트합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터 설치 중에 유효한 NTP 서버가 필요합니다. 적절한 NTP 서버를 사용할 수 있고 연결이 끊긴 네트워크를 통해 설치된 클러스터에서 도달할 수 있는지 확인합니다.
19.2.6. 인증되지 않은 레지스트리를 사용하도록 hub 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
인증되지 않은 레지스트리를 사용하도록 hub 클러스터를 구성할 수 있습니다. 인증되지 않은 레지스트리는 이미지에 액세스하여 다운로드하는 데 인증이 필요하지 않습니다.
사전 요구 사항
- hub 클러스터를 설치 및 구성하고 hub 클러스터에 RHACM(Red Hat Advanced Cluster Management)을 설치했습니다.
- OpenShift Container Platform CLI(oc)가 설치되어 있습니다.
-
cluster-admin권한이 있는 사용자로 로그인했습니다. - hub 클러스터에서 사용할 인증되지 않은 레지스트리를 구성했습니다.
절차
다음 명령을 실행하여
AgentServiceConfigCR(사용자 정의 리소스)을 업데이트합니다.oc edit AgentServiceConfig agent
$ oc edit AgentServiceConfig agentCopy to Clipboard Copied! Toggle word wrap Toggle overflow CR에
unauthenticatedRegistries필드를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인증되지 않은 레지스트리는
AgentServiceConfig리소스의spec.unauthenticatedRegistries에 나열됩니다. 이 목록의 레지스트리는 설명된 클러스터 설치에 사용된 풀 시크릿에 항목이 필요하지 않습니다.assisted-service는 설치에 사용되는 모든 이미지 레지스트리에 대한 인증 정보가 포함되어 있는지 확인하여 풀 시크릿을 검증합니다.
미러 레지스트리는 무시 목록에 자동으로 추가되며 spec.unauthenticatedRegistries 에서 추가할 필요가 없습니다. ConfigMap 에서 PUBLIC_CONTAINER_REGISTRIES 환경 변수를 지정하면 기본값이 지정된 값으로 재정의됩니다. PUBLIC_CONTAINER_REGISTRIES 기본값은 quay.io 및 registry.svc.ci.openshift.org 입니다.
검증
다음 명령을 실행하여 hub 클러스터에서 새로 추가된 레지스트리에 액세스할 수 있는지 확인합니다.
hub 클러스터에 대한 디버그 쉘 프롬프트를 엽니다.
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 인증되지 않은 레지스트리에 대한 액세스를 테스트합니다.
podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>
sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <unauthenticated_registry>
-
새 레지스트리(예:
unauthenticated-image-registry.openshift-image-registry.svc:5000)입니다.
출력 예
Login Succeeded!
Login Succeeded!Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.7. ArgoCD로 hub 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
GitOps zero touch provisioning(ZTP)을 사용하여 각 사이트에 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하는 ArgoCD 애플리케이션 세트로 hub 클러스터를 구성할 수 있습니다.
RHACM(Red Hat Advanced Cluster Management)은 site Config CR을 사용하여 ArgoCD의 1일 차 관리 클러스터 설치 CR을 생성합니다. 각 ArgoCD 애플리케이션은 최대 300개의 site Config CR을 관리할 수 있습니다.
사전 요구 사항
- RHACM(Red Hat Advanced Cluster Management) 및 Red Hat OpenShift GitOps가 설치된 OpenShift Container Platform 허브 클러스터가 있어야 합니다.
-
" GitOps ZTP 사이트 구성 리포지토리 준비" 섹션에 설명된 대로 ZTP GitOps 플러그인 컨테이너에서 참조 배포를 추출했습니다. 참조 배포를 추출하면 다음 절차에서 참조되는
out/argocd/deployment디렉터리가 생성됩니다.
절차
ArgoCD 파이프라인 구성을 준비합니다.
- 예제 디렉터리와 유사한 디렉터리 구조를 사용하여 Git 리포지토리를 생성합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
ArgoCD UI를 사용하여 리포지토리에 대한 액세스를 구성합니다. 설정에서 다음을 구성합니다.
-
리포지토리 - 연결 정보를 추가합니다. URL은
.git로 끝나야 합니다(예:https://repo.example.com/repo.git및 인증 정보). - 인증서 - 필요한 경우 리포지토리의 공용 인증서를 추가합니다.
-
리포지토리 - 연결 정보를 추가합니다. URL은
Git 리포지토리를 기반으로 두 개의 ArgoCD 애플리케이션
out/argocd/deployment/clusters-app.yaml및out/argocd/deployment/policies-app.yaml을 수정합니다.-
Git 리포지토리를 가리키도록 URL을 업데이트합니다. URL은
.git로 끝납니다(예:https://repo.example.com/repo.git). -
targetRevision은 모니터링할 Git 리포지토리 분기를 나타냅니다. -
path는 각각 siteConfig 및PolicyGenTemplateCR의 경로를 지정합니다.
-
Git 리포지토리를 가리키도록 URL을 업데이트합니다. URL은
ZTP GitOps 플러그인을 설치하려면 이전에
out/argocd/deployment/디렉터리에 추출된 패치 파일을 사용하여 hub 클러스터의 ArgoCD 인스턴스를 패치해야 합니다. 다음 명령을 실행합니다.oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고연결이 끊긴 환경의 경우 로컬 레지스트리에 미러링된
ztp-site-generate이미지를 사용하여out/argocd/deployment/argocd-openshift-gitops-patch.json파일을 수정합니다. 다음 명령을 실행합니다.oc patch argocd openshift-gitops -n openshift-gitops --type='json' \ -p='[{"op": "replace", "path": "/spec/repo/initContainers/0/image", \ "value": "<local_registry>/<ztp_site_generate_image_ref>"}]'$ oc patch argocd openshift-gitops -n openshift-gitops --type='json' \ -p='[{"op": "replace", "path": "/spec/repo/initContainers/0/image", \ "value": "<local_registry>/<ztp_site_generate_image_ref>"}]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음과 같습니다.
- <local_registry>
-
연결이 끊긴 레지스트리의 URL입니다(예:
my.local.registry:5000). - <ztp-site-generate-image-ref>
-
로컬 레지스트리의 미러링된
ztp-site-generate이미지의 경로입니다(예:openshift4-ztp-site-generate:custom).
RHACM 2.7 이상에서는 다중 클러스터 엔진에서 기본적으로
cluster-proxy-addon기능을 활성화합니다. 이 기능을 비활성화하려면 다음 패치를 적용하여 이 애드온을 담당하는 관련 허브 클러스터 및 관리 클러스터 Pod를 비활성화하고 제거합니다.oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
$ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 허브 클러스터에 파이프라인 구성을 적용합니다.
oc apply -k out/argocd/deployment
$ oc apply -k out/argocd/deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.2.8. GitOps ZTP 사이트 구성 리포지토리 준비 링크 복사링크가 클립보드에 복사되었습니다!
ZTP GitOps 파이프라인을 사용하려면 먼저 사이트 구성 데이터를 호스팅할 Git 리포지토리를 준비해야 합니다.
사전 요구 사항
- 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하기 위해 hub 클러스터 GitOps 애플리케이션을 구성했습니다.
- ZTP(zero touch provisioning)를 사용하여 관리형 클러스터를 배포했습니다.
절차
-
site
Config 및별도의 경로를 사용하여 디렉터리 구조를 생성합니다.PolicyGenTemplateCR에 대한 다음 명령을 사용하여
ztp-site-generate컨테이너 이미지에서argocd디렉터리를 내보냅니다.podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12
$ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12Copy to Clipboard Copied! Toggle word wrap Toggle overflow mkdir -p ./out
$ mkdir -p ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow out디렉터리에 다음 하위 디렉터리가 포함되어 있는지 확인합니다.-
아웃/extra-manifest에는SiteConfig에서 추가 매니페스트configMap을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다. -
out/source-crs에는PolicyGenTemplate이 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다. -
out/argocd/deployment에는 이 프로세스의 다음 단계에서 사용할 수 있도록 hub 클러스터에 적용하는 패치 및 YAML 파일이 포함되어 있습니다. -
out/argocd/example에는 권장 구성을 나타내는SiteConfig및PolicyGenTemplate파일의 예가 포함되어 있습니다.
-
out/argocd/example 아래의 디렉터리 구조는 Git 리포지토리의 구조 및 콘텐츠에 대한 참조 역할을 합니다. 이 예제에는 단일 노드, 3-노드 및 표준 클러스터에 대한 SiteConfig 및 PolicyGenTemplate 참조 CR이 포함됩니다. 사용하지 않는 클러스터 유형에 대한 참조를 제거합니다. 다음 예제에서는 단일 노드 클러스터 네트워크에 대한 CR 세트를 설명합니다.
SiteConfig 및 PolicyGenTemplate CR을 별도의 디렉터리에 보관합니다. SiteConfig 및 PolicyGenTemplate 디렉터리에는 해당 디렉터리에 파일을 명시적으로 포함하는 kustomization.yaml 파일이 포함되어야 합니다.
이 디렉터리 구조와 kustomization.yaml 파일을 커밋하고 Git 리포지토리로 내보내야 합니다. Git의 초기 푸시에는 kustomization.yaml 파일이 포함되어야 합니다. SiteConfig (예-sno.yaml) 및 PolicyGenTemplate (Common-ranGen.yaml,group-du 배포할 때 필요에 따라 나중에 생략하고 내보낼 수 있습니다.
-sno*.yaml.yaml )은 사이트를
KlusterletAddonConfigOverride.yaml 파일은 하나 이상의 SiteConfig CR을 커밋하고 Git로 푸시하는 경우에만 필요합니다. 사용 방법의 예는 example-sno.yaml 을 참조하십시오.
19.3. RHACM 및 siteConfig 리소스를 사용하여 관리형 클러스터 설치 링크 복사링크가 클립보드에 복사되었습니다!
지원 서비스 및 core-reduction 기술이 활성화된 GitOps 플러그인 정책 생성기를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 OpenShift Container Platform 클러스터를 스케일링하여 프로비저닝할 수 있습니다. zero touch priovisioning (ZTP) 파이프라인은 클러스터 설치를 수행합니다. ZTP는 연결이 끊긴 환경에서 사용할 수 있습니다.
19.3.1. GitOps ZTP 및 토폴로지 Aware Lifecycle Manager 링크 복사링크가 클립보드에 복사되었습니다!
GitOps zero touch provisioning (ZTP)은 Git에 저장된 매니페스트에서 설치 및 구성 CR을 생성합니다. 이러한 아티팩트는 RHACM(Red Hat Advanced Cluster Management), 지원 서비스 및 TALM( Topology Aware Lifecycle Manager)이 CR을 사용하여 관리되는 클러스터를 설치 및 구성하는 중앙 집중식 허브 클러스터에 적용됩니다. ZTP 파이프라인의 구성 단계에서는 TALM을 사용하여 구성 CR의 애플리케이션을 클러스터에 오케스트레이션합니다. GitOps ZTP와 TALM 간에는 몇 가지 주요 통합 지점이 있습니다.
- 정책 정보
-
기본적으로 GitOps ZTP는 알림 수정 작업을 사용하여 모든 정책을
생성합니다. 이러한 정책을 통해 RHACM은 정책과 관련된 클러스터의 규정 준수 상태를 보고하지만 원하는 구성은 적용하지 않습니다. ZTP 프로세스 중에 OpenShift를 설치한 후 TALM은 생성된정보보호 정책을 단계별로 진행하여 대상 관리 클러스터에서 이를 적용합니다. 이는 관리 클러스터에 구성을 적용합니다. 클러스터 라이프사이클의 ZTP 단계 외부에서는 영향을 받는 관리형 클러스터로 변경 사항을 즉시 롤아웃할 위험 없이 정책을 변경할 수 있습니다. TALM을 사용하여 시간 및 수정된 클러스터 세트를 제어할 수 있습니다. - ClusterGroupUpgrade CR 자동 생성
새로 배포된 클러스터의 초기 구성을 자동화하기 위해 TALM은 hub 클러스터에서 모든
ManagedClusterCR의 상태를 모니터링합니다. 새로 생성된ManagedClusterCR을 포함하여ztp-done레이블이 적용되지 않은ManagedClusterCR을 사용하면 TALM이 다음과 같은 특성을 가진ClusterGroupUpgradeCR을 자동으로 생성합니다.-
ztp-install네임스페이스에서ClusterGroupUpgradeCR이 생성되고 활성화됩니다. -
ClusterGroupUpgradeCR은ManagedClusterCR과 이름이 동일합니다. -
클러스터 선택기에는 해당
ManagedClusterCR과 연결된 클러스터만 포함됩니다. -
관리 정책 세트에는 RHACM이
ClusterGroupUpgrade가 생성될 때 클러스터에 바인딩한 모든 정책이 포함됩니다. - 사전 캐싱이 비활성화되어 있습니다.
- 시간 제한은 4시간(240분)으로 설정합니다.
활성화된
ClusterGroupUpgrade의 자동 생성을 통해 클러스터의 초기 배포를 사용자 개입할 필요 없이 진행할 수 있습니다. 또한ztp-done라벨이 없는ManagedCluster에 대한ClusterGroupUpgradeCR을 자동으로 생성하면 클러스터의ClusterGroupUpgradeCR을 간단히 삭제하여 ZTP 설치를 시작할 수 있습니다.-
- 웨이브
PolicyGenTemplateCR에서 생성된 각 정책에는ztp-deploy-wave주석이 포함됩니다. 이 주석은 해당 정책에 포함된 각 CR의 동일한 주석을 기반으로 합니다. 웨이브 주석은 자동 생성된ClusterGroupUpgradeCR에서 정책을 주문하는 데 사용됩니다. parse 주석은 자동 생성된ClusterGroupUpgradeCR 이외의 용도로 사용되지 않습니다.참고동일한 정책에 있는 모든 CR에는
ztp-deploy-wave주석에 동일한 설정이 있어야 합니다. 각 CR에 대한 이 주석의 기본값은PolicyGenTemplate에서 재정의할 수 있습니다. 소스 CR의 웨이브 주석은 정책 웨이브 주석을 결정하고 설정하는 데 사용됩니다. 이 주석은 런타임에 생성된 정책에 포함된 각 빌드 CR에서 제거됩니다.TALM은 웨이브 주석에 지정된 순서로 구성 정책을 적용합니다. TALM은 다음 정책으로 이동하기 전에 각 정책을 준수할 때까지 기다립니다. 각 CR의 웨이브 주석이 클러스터에 적용되려면 해당 CR의 사전 요구 사항을 고려해야 합니다. 예를 들어 Operator의 구성 전 또는 동시에 Operator를 설치해야 합니다. 마찬가지로 Operator 서브스크립션 이전 또는 동시에 Operator의
CatalogSource를 웨이브에 설치해야 합니다. 각 CR의 기본 웨이브 값은 이러한 사전 요구 사항을 고려합니다.여러 CR 및 정책이 동일한 파동 번호를 공유할 수 있습니다. 정책이 줄어들면 배포 속도가 빨라지고 CPU 사용량을 줄일 수 있습니다. 많은 CR을 비교적 몇 개의 파도로 그룹화하는 것이 가장 좋습니다.
각 소스 CR의 기본 파도 값을 확인하려면 ztp-site-generate 컨테이너 이미지에서 추출된 out/source-crs 디렉터리에 대해 다음 명령을 실행합니다.
grep -r "ztp-deploy-wave" out/source-crs
$ grep -r "ztp-deploy-wave" out/source-crs
- 단계 라벨
ClusterGroupUpgradeCR은 자동으로 생성되며 ZTP 프로세스의 시작 및 종료 시 라벨을 사용하여ManagedClusterCR에 주석을 답니다.ZTP 구성 후 설치가 시작되면
ManagedCluster에ztp-running레이블이 적용됩니다. 모든 정책이 클러스터로 수정되고 완전히 호환되면 이러한 지시문으로 인해 TALM이ztp-running레이블을 제거하고ztp-done레이블을 적용합니다.informDuValidator정책을 사용하는 배포의 경우 클러스터가 애플리케이션 배포를 완전히 준비할 때ztp-done레이블이 적용됩니다. 여기에는 ZTP 적용 구성 CR의 모든 조정 및 결과 효과가 포함됩니다.ztp-done레이블은 TALM의 자동ClusterGroupUpgradeCR 생성에 영향을 미칩니다. 클러스터의 초기 ZTP 설치 후 이 라벨을 조작하지 마십시오.- 연결된 CR
-
자동으로 생성된
ClusterGroupUpgradeCR에는 파생된ManagedCluster로 설정된 소유자 참조가 있습니다. 이 참조를 사용하면ManagedClusterCR을 삭제하면 지원 리소스와 함께ClusterGroupUpgrade인스턴스가 삭제됩니다.
19.3.2. ZTP를 사용하여 관리형 클러스터 배포 개요 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management)은 zero touch provisioning(ZTP)을 사용하여 단일 노드 OpenShift Container Platform 클러스터, 3노드 클러스터 및 표준 클러스터를 배포합니다. Git 리포지토리에서 사이트 구성 데이터를 OpenShift Container Platform CR(사용자 정의 리소스)으로 관리합니다. ZTP는 선언적 GitOps 접근 방식을 사용하여 한 번 개발하여 관리 클러스터를 배포합니다.
클러스터 배포에는 다음이 포함됩니다.
- 빈 서버에 호스트 운영 체제(RHCOS) 설치
- OpenShift Container Platform 배포
- 클러스터 정책 및 사이트 서브스크립션 생성
- 서버 운영 체제에 필요한 네트워크 구성
- 프로필 Operator 배포 및 성능 프로필, PTP 및 SR-IOV와 같은 필요한 소프트웨어 관련 구성 수행
관리되는 사이트 설치 프로세스 개요
hub 클러스터에서 관리 사이트 CR(사용자 정의 리소스)을 적용하면 다음 작업이 자동으로 수행됩니다.
- 검색 이미지 ISO 파일이 생성되어 대상 호스트에서 부팅됩니다.
- ISO 파일이 대상 호스트에서 성공적으로 부팅되면 호스트 하드웨어 정보를 RHACM에 보고합니다.
- 모든 호스트가 검색되면 OpenShift Container Platform이 설치됩니다.
-
OpenShift Container Platform 설치가 완료되면 허브가 대상 클러스터에
klusterlet서비스를 설치합니다. - 요청된 애드온 서비스가 대상 클러스터에 설치되어 있습니다.
hub 클러스터에서 관리 클러스터의 에이전트 CR이 생성되면 검색 이미지 ISO 프로세스가 완료됩니다.
대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대해 권장 단일 노드 OpenShift 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.
19.3.3. 관리형 베어 메탈 호스트 시크릿 생성 링크 복사링크가 클립보드에 복사되었습니다!
관리 베어 메탈 호스트에 필요한 Secret CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. 레지스트리에서 클러스터 설치 이미지를 가져오기 위해 BMC(Baseboard Management Controller) 및 지원 설치 서비스 시크릿에 액세스하려면 ZTP 파이프라인의 시크릿이 필요합니다.
보안은 이름으로 site Config CR 에서 참조됩니다. 네임스페이스는 SiteConfig 네임스페이스와 일치해야 합니다.
절차
OpenShift 및 모든 애드온 클러스터 Operator를 설치하는 데 필요한 BMC(Host Baseboard Management Controller) 및 풀 시크릿(pull secret)의 인증 정보가 포함된 YAML 시크릿 파일을 생성합니다.
-
클러스터를 설치하는 데 사용하는
kustomization.yaml파일에 상대 경로를example-sno-secret.yaml에 추가합니다.
19.3.4. GitOps ZTP를 사용하여 설치에 대한 Discovery ISO 커널 인수 구성 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP 워크플로는 관리형 베어 메탈 호스트에서 OpenShift Container Platform 설치 프로세스의 일부로 Discovery ISO를 사용합니다. InfraEnv 리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어, 클러스터의 정적 네트워킹을 용이하게 하거나 설치 중에 루트 파일 시스템을 다운로드하기 전에 DHCP 주소를 수신하도록 Discovery ISO의 rd.net.timeout.carrier 커널 인수를 구성합니다.
OpenShift Container Platform 4.12에서는 커널 인수만 추가할 수 있습니다. 커널 인수를 교체하거나 삭제할 수 없습니다.
사전 요구 사항
- OpenShift CLI(oc)가 설치되어 있습니다.
- cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
InfraEnvCR을 생성하고spec.kernelArguments사양을 편집하여 커널 인수를 구성합니다.다음 YAML을
InfraEnv-example.yaml파일에 저장합니다.참고이 예제의
InfraEnvCR은 siteConfigCR의 값에 따라 채워지는{{ .Cluster.ClusterName }}와 같은 템플릿 구문을 사용합니다. siteConfigCR은 배포 중에 이러한 템플릿에 대한 값을 자동으로 채웁니다. 템플릿을 수동으로 편집하지 마십시오.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
InfraEnv-example.yamlCR을 Git 리포지토리의 동일한 위치에 커밋하고 변경 사항을 내보냅니다.다음 예는 샘플 Git 리포지토리 구조를 보여줍니다.~/example-ztp/install └── site-install ├── siteconfig-example.yaml ├── InfraEnv-example.yaml ...~/example-ztp/install └── site-install ├── siteconfig-example.yaml ├── InfraEnv-example.yaml ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git 리포지토리의
InfraEnv-example.yamlCR을 참조하도록 siteConfigCR의spec.clusters.crTemplates사양을 편집합니다.clusters: crTemplates: InfraEnv: "InfraEnv-example.yaml"clusters: crTemplates: InfraEnv: "InfraEnv-example.yaml"Copy to Clipboard Copied! Toggle word wrap Toggle overflow site
ConfigCR을 커밋하고 푸시하여 클러스터를 배포할 준비가 되면 빌드 파이프라인은 Git 리포지토리의 사용자 지정InfraEnv-exampleCR을 사용하여 사용자 정의 커널 인수를 포함한 인프라 환경을 구성합니다.
검증
커널 인수가 적용되었는지 확인하려면 Discovery 이미지에서 OpenShift Container Platform을 설치할 준비가 되었는지 확인한 후 설치 프로세스가 시작되기 전에 대상 호스트에 SSH를 실행할 수 있습니다. 이 시점에서 /proc/cmdline 파일에서 Discovery ISO의 커널 인수를 볼 수 있습니다.
대상 호스트를 사용하여 SSH 세션을 시작합니다.
ssh -i /path/to/privatekey core@<host_name>
$ ssh -i /path/to/privatekey core@<host_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.
cat /proc/cmdline
$ cat /proc/cmdlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.5. siteConfig 및 ZTP를 사용하여 관리형 클러스터 배포 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 site Config CR(사용자 정의 리소스) 및 관련 파일을 생성하고 zero touch provisioning (ZTP) 클러스터 배포를 시작합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 필요한 설치 및 정책 CR을 생성하기 위해 hub 클러스터를 구성하셨습니다.
사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD 애플리케이션의 소스 리포지토리로 구성해야 합니다. 자세한 내용은 "GITOP ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
참고소스 리포지토리를 생성할 때
ztp-site-generate컨테이너에서 추출한argocd/deployment/argocd-openshift-gitops-patch.jsonpatch-file을 사용하여 ArgoCD 애플리케이션을 패치해야 합니다. " ArgoCD를 사용하여 hub 클러스터 구성"을 참조하십시오.관리 클러스터를 프로비저닝할 준비를 하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.
- 네트워크 연결
- 네트워크에는 DNS가 필요합니다. hub 클러스터에서 관리 클러스터 호스트에 연결할 수 있어야 합니다. hub 클러스터와 관리 클러스터 호스트 간에 계층 3 연결이 있는지 확인합니다.
- BMC(Baseboard Management Controller) 세부 정보
-
ZTP는 BMC 사용자 이름과 암호 세부 정보를 사용하여 클러스터 설치 중에 BMC에 연결합니다. GitOps ZTP 플러그인은 사이트 Git 리포지토리의 site
ConfigCR을 기반으로 hub 클러스터에서ManagedClusterCR을 관리합니다. 각 호스트에 대해 개별BMCSecretCR을 수동으로 생성합니다.
절차
hub 클러스터에서 필요한 관리 클러스터 시크릿을 생성합니다. 이러한 리소스는 클러스터 이름과 일치하는 이름이 있는 네임스페이스에 있어야 합니다. 예를 들어
out/argocd/example/siteconfig/example-sno.yaml에서 클러스터 이름과 네임스페이스는example-sno입니다.다음 명령을 실행하여 클러스터 네임스페이스를 내보냅니다.
export CLUSTERNS=example-sno
$ export CLUSTERNS=example-snoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 네임스페이스를 생성합니다.
oc create namespace $CLUSTERNS
$ oc create namespace $CLUSTERNSCopy to Clipboard Copied! Toggle word wrap Toggle overflow
관리형 클러스터의 pull secret 및 BMC
SecretCR을 생성합니다. 풀 시크릿에는 OpenShift Container Platform 및 모든 필수 Operator 설치에 필요한 모든 인증 정보가 포함되어야 합니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.참고보안은 이름으로
SiteConfigCR(사용자 정의 리소스)에서 참조합니다. 네임스페이스는SiteConfig네임스페이스와 일치해야 합니다.Git 리포지토리의 로컬 복제본에 클러스터용
SiteConfigCR을 생성합니다.out/argocd/example/siteconfig/디렉터리에서 CR에 대한 적절한 예제를 선택합니다. 폴더에는 단일 노드, 3-노드 및 표준 클러스터의 예제 파일이 포함되어 있습니다.-
example-sno.yaml -
example-3node.yaml -
example-standard.yaml
-
예제 파일의 클러스터와 호스트 세부 정보를 원하는 클러스터 유형과 일치하도록 변경합니다. 예를 들면 다음과 같습니다.
# example-node1-bmh-secret & assisted-deployment-pull-secret은 동일한 네임스페이스 example-sno --- apiVersion: ran.openshift.io/v1 종류 아래에 생성해야 합니다. siteConfig metadata: name: "example-sno" namespace: "example-sno" spec: baseDomain: "example.com" pullSecretRef: name: "assisted-deployment-pull-secret" clusterImageSetNameRef: "openshift-4.10" sshPublicKey: "ssh-rsa AAAA…" 클러스터: - clusterName: "example-sno" networkType: "OVNKubernetes" # installConfigOverrides는 siteConfig를 통해 install-config # 매개변수를 전달하는 일반적인 방법입니다. 'capabilities' 필드는 # 구성 가능 openshift 기능을 구성합니다. 이 'capabilities' 설정에서 # 구성 요소의 선택적 세트에서 marketplace 구성 요소를 모두 제거합니다. # - OperatorLifecycleManager는 4.15 이상에 필요합니다. NodeTuning은 4.13 이상에 필요합니다. 4.12 및 이전 installConfigOverrides: | "capabilities": { "baselineCapabilitySet": "None", # - OperatorLifecycleManager에 필요합니다. "additionalEnabledCapabilities": [ "NodeTuning", "OperatorLifecycleManager" ] } # crun 매니페스트를 4.13+의 추가 설치 시간 매니페스트의 일부로 포함하는 것이 좋습니다. # crun 매니페스트는 source-crs/optional-extra-manifest/에서 가져올 수 있으며 git repo ie.sno-extra-manifest에 추가할 수 있습니다. # extraManifestPath: sno-extra-manifest clusterLabels: # 이 예제 클러스터 라벨은 PolicyGenTemplate 예제 ut-profile 예제 "latest"의 bindingRules에 해당합니다. 이 예제 클러스터 레이블은 ../policygentemplates: # ./policygentemplates/common-ranGen.yaml의 PolicyGenTemplate 예제에 있는 bindingRules에 해당합니다. 은 'common: true' common: true: true # ../policygentemplates/group-du-sno-ranGen.yaml이 있는 모든 클러스터에 적용됩니다. 'group-du-sno: ""' group-du-sno: "" # ../policygentemplates/example-sno-site.yaml이 적용됩니다. 'sites: "example-sno"'가 있는 모든 클러스터의 경우 일반적으로 클러스터 이름이 일치하거나 포함해야 합니다. 단일 클러스터 사이트 : "example-sno" clusterNetwork: -cidr: 1001:1::/48 hostPrefix: 64 machineNetwork: - cidr: 1111:2222:3333:4444::/64 serviceNetwork: - 1001:2::/112 추가NTPSources: - 1111:2222:3333:4444::2 # 워크로드 파티셔닝을 위해 클러스터를 시작합니다. 특정 예약/isolated CPUSets 설정은 PolicyTemplate #을 통해 수행됩니다. 전체 안내서는 Workload 파티셔닝 기능을 참조하십시오. cpu CryostatingMode: AllNodes # 필요한 경우 이 클러스터에 대해 생성된 KlusterletAddonConfig를 재정의하는 데 사용할 수 있습니다. crTemplates: # KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 노드: - hostName: "example-node1.example.com" role: "master" # optionally; 호스트에서 원하는 BIOS 설정을 구성하는 데 사용할 수 있습니다. #biosConfigRef: # filePath: "example-hw.profile" bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1" bmcCredentialsName: name: "example-node1-bmh-secret" bootMACAddress: "AA:#159:CC:DD:EE:11" # UEFISecureBoot를 사용하여 보안 부팅 bootMode: "UEFI" rootDeviceHints: deviceName: "/dev/disk/by-path/pci-0000:01:00.0:2:0:0" # ignitionConfigOverride를 사용하여
/var/lib/containers의 디스크 파티션을 활성화합니다. 일부 값을 업데이트해야 합니다. 자세한 내용은 ignitionConfigOverride: | { "ignition": { "version": "3.2.0" }, "storage": { "disks": [ { "device": "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0", " { "label": "var-lib-containers", " { "label": "var-lib-containers"를 참조하십시오. "sizeMiB": 0, "startMiB": 250000 } ], "wipeTable": false } ], "filesystems": [ { "device": "/dev/disk/by-partlabel/var-lib-containers", "format": "xfs", "mountOptions": [ "defaults", "prjquota" ], "path": "/var/lib/containers", "wipeFilesystem": true } ], "systemd": { "units": " "contents": " Butane\n[Unit]\nRequires=systemd-disk-by\dev-disk-by\x2dlabel-var2dlib\x2dcontainers\x2dcontainers. prjquota\n\n\n[Install]\n[Install]\nRequiredBy=local-fs.target", "enabled": true, "name": "var-lib-containers.mount" } } nodeNetwork: interfaces: - name: eno1 macAddress: "AA:#159:CC:DD:EE:11" config: interfaces: interface: interface: - name: eno1 type: ethernet state: up ipv4: enabled: false ipv6: enabled: true address: # 고정 IP 주소가 있는 SNO 사이트의 경우 노드별 # API 및 Ingress IP는 모두 동일해야 합니다. # ip: 1111:22:22:22:22:22:22:22:3333:4444::aaa:1 접두사-length: 64 dns-resolver: config: search:- example.com 서버: - 1111:22:3333:4444::2 routes: config: - destination: ::/0 next-hop-interface: eno1 next-hop-address: 1111:2222:3333:4444::1 table-id: 254+
참고BMC 주소 지정에 대한 자세한 내용은 "ECDHE 리소스" 섹션을 참조하십시오.
installConfigOverrides및ignitionConfigOverride필드는 쉽게 읽을 수 있도록 확장됩니다.-
out/argocd/extra-manifest에서 기본 extra-manifestMachineConfigCR 세트를 검사할 수 있습니다. 이는 설치 시 클러스터에 자동으로 적용됩니다. -
선택 사항: 프로비저닝된 클러스터에서 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리(예:
sno-extra-manifest/)를 생성하고 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다.SiteConfig.yaml이extraManifestPath필드에서 이 디렉터리를 참조하는 경우 이 참조되는 디렉터리의 모든 CR이 기본 매니페스트 세트에 추가됩니다.
-
out/argocd/example/siteconfig/에 표시된 예와 유사하게kustomization.yamlgenerators섹션의 kustomization.yaml 파일에SiteConfigCR을 추가합니다. Git 리포지토리
에서 siteConfigCR 및 관련kustomization.yaml변경 사항을 커밋하고 변경 사항을 내보냅니다.ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.
19.3.5.1. 단일 노드 OpenShift SiteConfig CR 설치 참조 링크 복사링크가 클립보드에 복사되었습니다!
| siteConfig CR 필드 | 설명 |
|---|---|
|
|
|
|
|
사이트의 모든 클러스터에 대해 hub 클러스터에서 사용 가능한 이미지 세트를 구성합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 |
|
|
클러스터 설치 전에 선택적 구성 요소를 활성화하거나 비활성화하려면 중요
예제 |
|
|
사용자가 정의한 |
|
|
선택 사항: |
|
|
단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 3개의 호스트를 정의합니다. 표준 배포의 경우 |
|
| 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. {ztp}는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "ECDHE 리소스" 섹션을 참조하십시오. |
|
| 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. {ztp}는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "ECDHE 리소스" 섹션을 참조하십시오. 참고 지금까지 엣지 Telco 사용 사례에서는 가상 미디어만 {ztp}와 함께 사용할 수 있도록 지원됩니다. |
|
|
호스트 BMC 인증 정보를 사용하여 별도로 생성하는 |
|
|
호스트의 부팅 모드를 |
|
|
배포 장치를 지정합니다. 재부팅 시 안정적인 식별자를 사용하는 것이 좋습니다. 예를 들어 |
|
|
워크로드 파티셔닝을 위해 클러스터 |
|
| 노드의 네트워크 설정을 구성합니다. |
|
| 호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다. |
19.3.6. 관리형 클러스터 설치 진행 상황 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
ArgoCD 파이프라인은 siteConfig CR을 사용하여 클러스터 구성 CR을 생성하고 hub 클러스터와 동기화합니다. ArgoCD 대시보드에서 동기화 진행 상황을 모니터링할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
동기화가 완료되면 설치는 일반적으로 다음과 같이 진행됩니다.
Assisted Service Operator는 클러스터에 OpenShift Container Platform을 설치합니다. RHACM 대시보드 또는 명령줄에서 다음 명령을 실행하여 클러스터 설치 진행 상황을 모니터링할 수 있습니다.
클러스터 이름을 내보냅니다.
export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 클러스터의
AgentClusterInstallCR을 쿼리합니다.oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq$ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 설치 이벤트를 가져옵니다.
curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'$ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}') | jq '.[-2,-1]'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.7. 설치 CR을 검증하여 GitOps ZTP 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
ArgoCD 파이프라인은 site Config 및 PolicyGenTemplate 사용자 정의 리소스(CR)를 사용하여 클러스터 구성 CR 및 RHACM(Red Hat Advanced Cluster Management) 정책을 생성합니다. 다음 단계를 사용하여 이 프로세스 중에 발생할 수 있는 문제를 해결합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
다음 명령을 사용하여 설치 CR이 생성되었는지 확인합니다.
oc get AgentClusterInstall -n <cluster_name>
$ oc get AgentClusterInstall -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 반환된 오브젝트가 없는 경우 다음 단계를 사용하여 site
Config파일에서 설치 CR로의 ArgoCD 파이프라인 흐름 문제를 해결합니다.hub 클러스터에서 site
ConfigCR을 사용하여ManagedClusterCR이 생성되었는지 확인합니다.oc get managedcluster
$ oc get managedclusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow ManagedCluster가 누락된 경우클러스터애플리케이션이 Git 리포지토리에서 hub 클러스터와 파일을 동기화하지 못하는지 확인합니다.oc describe -n openshift-gitops application clusters
$ oc describe -n openshift-gitops application clustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow Status.Conditions필드가 있는지 확인하여 관리형 클러스터의 오류 로그를 확인합니다. 예를 들어, siteConfigCR에서extraManifestPath:에 유효하지 않은 값을 설정하면 다음 오류가 발생합니다.Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1 Type: ComparisonErrorStatus: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1 Type: ComparisonErrorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Status.Sync필드를 확인합니다. 로그 오류가 있는 경우Status.Sync필드에Unknown오류가 표시될 수 있습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.8. Supermicro 서버에서 {ztp} 가상 미디어 부팅 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
Supermicro X11 서버는 https 프로토콜을 사용하여 이미지를 제공하는 경우 가상 미디어 설치를 지원하지 않습니다. 결과적으로 이 환경의 단일 노드 OpenShift 배포가 대상 노드에서 부팅되지 않습니다. 이 문제를 방지하려면 hub 클러스터에 로그인하고 프로비저닝 리소스에서 TLS(Transport Layer Security)를 비활성화합니다. 이렇게 하면 이미지 주소가 https 스키마를 사용하더라도 TLS로 이미지가 제공되지 않습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
다음 명령을 실행하여
프로비저닝리소스에서 TLS를 비활성화합니다.oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'$ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 단일 노드 OpenShift 클러스터를 배포하려면 단계를 계속합니다.
19.3.9. ZTP 파이프라인에서 관리형 클러스터 사이트 제거 링크 복사링크가 클립보드에 복사되었습니다!
ZTP 파이프라인에서 관리되는 사이트 및 관련 설치 및 구성 정책 CR을 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
kustomization.yaml파일에서 관련 siteConfig 및및 관련 CR을 제거합니다.PolicyGenTemplate파일을 제거하여 사이트ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.
-
선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site
Config및 사이트별PolicyGenTemplate파일도 제거해야 합니다. -
선택 사항: 사이트를 임시로 제거하려면 예를 들어 사이트를 재배포할 때 사이트별
PolicyGenTemplateCR을 Git 리포지토리에 남겨 둘 수 있습니다.
19.3.10. ZTP 파이프라인에서 더 이상 사용되지 않는 콘텐츠 제거 링크 복사링크가 클립보드에 복사되었습니다!
PolicyGenTemplate 구성을 변경하면 정책과 같이 더 이상 사용되지 않는 정책이 생성되는 경우 다음 절차를 사용하여 더 이상 사용되지 않는 정책을 제거합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
-
Git 리포지토리에서 영향을 받는
PolicyGenTemplate파일을 제거하고 원격 리포지토리로 커밋하고 내보냅니다. - 애플리케이션 및 영향을 받는 정책이 hub 클러스터에서 제거될 때까지 변경 사항이 동기화될 때까지 기다립니다.
업데이트된
PolicyGenTemplate파일을 Git 리포지토리에 다시 추가한 다음 원격 리포지토리를 커밋하고 내보냅니다.참고Git 리포지토리에서 zero touch provisioning(ZTP) 정책을 제거하면 hub 클러스터에서도 해당 정책을 제거하면 관리 클러스터 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리형 클러스터에서 유지됩니다.
선택 사항: 더 이상 사용되지 않는 정책을 생성하는
PolicyGenTemplateCR을 변경한 후 허브 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.oc delete policy -n <namespace> <policy_name>
$ oc delete policy -n <namespace> <policy_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.3.11. ZTP 파이프라인 제거 링크 복사링크가 클립보드에 복사되었습니다!
ArgoCD 파이프라인 및 생성된 모든 ZTP 아티팩트를 제거할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
- hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.
다음 명령을 사용하여
배포디렉터리에서kustomization.yaml파일을 삭제합니다.oc delete -k out/argocd/deployment
$ oc delete -k out/argocd/deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.
19.4. 정책 및 PolicyGenTemplate 리소스를 사용하여 관리형 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
적용된 정책 CR(사용자 정의 리소스)은 프로비저닝하는 관리형 클러스터를 구성합니다. RHACM(Red Hat Advanced Cluster Management)에서 PolicyGenTemplate CR을 사용하여 적용된 정책 CR을 생성하는 방법을 사용자 지정할 수 있습니다.
19.4.1. PolicyGenTemplate CRD 정보 링크 복사링크가 클립보드에 복사되었습니다!
PolicyGenTemplate CRD(사용자 정의 리소스 정의)는 PolicyGen 정책 생성기에 클러스터 구성에 포함할 CR(사용자 정의 리소스), CR을 생성된 정책에 결합하는 방법, 오버레이 콘텐츠를 사용하여 업데이트해야 하는 항목을 지시합니다.
다음 예제에서는 ztp-site-generate 참조 컨테이너에서 추출된 PolicyGenTemplate CR(common-du-ranGen.yaml)을 보여줍니다. common-du-ranGen.yaml 파일은 RHACM(Red Hat Advanced Cluster Management) 정책을 정의합니다. 정책은 CR에서 policyName 의 각 고유한 값에 대해 구성 CR 컬렉션을 관리합니다. common-du-ranGen.yaml 은 단일 배치 바인딩과 바인딩 규칙을 생성하여 bindingRules 섹션에 나열된 레이블을 기반으로 정책을 클러스터에 바인딩합니다.
PolicyGenTemplate CR - common-du-ranGen.yaml
- 1
Common: "true"는 이 레이블이 있는 모든 클러스터에 정책을 적용합니다.- 2
sourceFiles에 나열된 파일은 설치된 클러스터에 대한 Operator 정책을 생성합니다.- 3
OperatorHub.yaml은 연결이 끊긴 레지스트리에 대한 OperatorHub를 구성합니다.- 4
DefaultCatsrc.yaml은 연결이 끊긴 레지스트리의 카탈로그 소스를 구성합니다.- 5
PolicyName: "config-policy"는 Operator 서브스크립션을 구성합니다.OperatorHubCR은 기본값을 비활성화하고 이 CR은redhat-operators를 연결이 끊긴 레지스트리를 가리키는CatalogSourceCR로 대체합니다.
PolicyGenTemplate CR은 포함된 여러 CR로 구성할 수 있습니다. hub 클러스터에 다음 예제 CR을 적용하여 단일 CR을 포함하는 정책을 생성합니다.
소스 파일 PtpConfigSlave.yaml 을 예로 사용하여 파일은 PtpConfig CR을 정의합니다. PtpConfigSlave 예제에 대해 생성된 정책의 이름은 group-du-sno-config-policy 입니다. 생성된 group-du-sno-config-policy 에 정의된 PtpConfig CR의 이름은 du-ptp-slave 입니다. PtpConfigSlave.yaml 에 정의된 사양 은 소스 파일에 정의된 다른 사양 항목과 함께 du-ptp-slave 아래에 배치됩니다.
다음 예제에서는 group-du-sno-config-policy CR을 보여줍니다.
19.4.2. PolicyGenTemplate CR을 사용자 정의할 때 권장 사항 링크 복사링크가 클립보드에 복사되었습니다!
사이트 구성 PolicyGenTemplate 사용자 정의 리소스(CR)를 사용자 정의할 때 다음 모범 사례를 고려하십시오.
-
필요한 경우 몇 가지 정책을 사용하십시오. 정책을 더 적게 사용하려면 리소스를 줄일 수 있습니다. 각 추가 정책은 hub 클러스터 및 배포된 관리형 클러스터에 대한 오버헤드를 생성합니다. CR은
PolicyGenTemplateCR의policyName필드를 기반으로 정책과 결합됩니다.policyName의 값이 동일한 동일한PolicyGenTemplate의 CR은 단일 정책으로 관리됩니다. -
연결이 끊긴 환경에서는 모든 Operator가 포함된 단일 인덱스로 레지스트리를 구성하여 모든 Operator에 대해 단일 카탈로그 소스를 사용합니다. 관리 클러스터의 추가
CatalogSourceCR마다 CPU 사용량이 증가합니다. -
MachineConfigCR은 설치 중에 적용되도록SiteConfigCR에추가Manifest로 포함되어야 합니다. 이렇게 하면 클러스터가 애플리케이션을 배포할 준비가 될 때까지 전체 시간이 단축될 수 있습니다. -
PolicyGenTemplates는 원하는 버전을 명시적으로 식별하기 위해 channel 필드를 재정의해야 합니다. 이렇게 하면 업그레이드 중 소스 CR의 변경 사항이 생성된 서브스크립션을 업데이트하지 않습니다.
hub 클러스터에서 많은 수의 통화 클러스터를 관리할 때 리소스 사용량을 줄이기 위한 정책 수를 최소화합니다.
여러 구성 CR을 단일 또는 제한된 정책 수로 그룹화하는 것은 hub 클러스터의 전체 정책 수를 줄이는 한 가지 방법입니다. 사이트 구성 관리 정책의 공통, 그룹 및 사이트 계층을 사용하는 경우 사이트별 구성을 단일 정책으로 결합하는 것이 특히 중요합니다.
19.4.3. RAN 배포를 위한 PolicyGenTemplate CR 링크 복사링크가 클립보드에 복사되었습니다!
PGT( PolicyGenTemplate ) 사용자 정의 리소스(CR)를 사용하여 GitOps zero touch provisioning(ZTP) 파이프라인을 사용하여 클러스터에 적용된 구성을 사용자 지정합니다. PGT CR을 사용하면 클러스터에서 구성 CR 세트를 관리하기 위해 하나 이상의 정책을 생성할 수 있습니다. PGT는 관리형 CR 세트를 식별하고, 이를 정책으로 번들하고, 해당 CR을 기반으로 정책을 빌드하며, 라벨 바인딩 규칙을 사용하여 정책을 클러스터와 연결합니다.
GitOps ZTP 컨테이너에서 얻은 참조 구성은 클러스터가 RAN(Radio Access Network) 분산 장치(DU) 애플리케이션의 일반적인 성능 및 리소스 사용률 제약 조건을 지원할 수 있도록 중요한 기능 및 노드 튜닝 설정 세트를 제공하도록 설계되었습니다. 기본 구성의 변경 또는 누락은 기능 가용성, 성능 및 리소스 사용률에 영향을 줄 수 있습니다. 참조 PolicyGenTemplate CR을 기반으로 사용하여 특정 사이트 요구 사항에 맞게 구성 파일의 계층을 생성합니다.
RAN DU 클러스터 구성에 대해 정의된 기준의 PolicyGenTemplate CR은 GitOps ZTP ztp-site-generate 컨테이너에서 추출할 수 있습니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
PolicyGenTemplate CR은 ./out/argocd/example/policygentemplates 폴더에 있습니다. 참조 아키텍처에는 공통, 그룹 및 사이트별 구성 CR이 있습니다. 각 PolicyGenTemplate CR은 ./out/source-crs 폴더에 있는 다른 CR을 나타냅니다.
RAN 클러스터 구성과 관련된 PolicyGenTemplate CR은 아래에 설명되어 있습니다. PolicyGenTemplate CR은 단일 노드, 3 노드 컴팩트 및 표준 클러스터 구성의 차이점을 설명하기 위해 그룹 PolicyGenTemplate CR에 대해 제공됩니다. 마찬가지로 단일 노드 클러스터 및 다중 노드(컴파일 또는 표준) 클러스터에 사이트별 구성 변형이 제공됩니다. 배포와 관련된 그룹 및 사이트별 구성 변형을 사용합니다.
| PolicyGenTemplate CR | 설명 |
|---|---|
|
| 다중 노드 클러스터에 적용할 CR 세트가 포함되어 있습니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다. |
|
| 단일 노드 OpenShift 클러스터에 적용되는 CR 세트가 포함되어 있습니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다. |
|
| 모든 클러스터에 적용되는 공통 RAN CR 세트를 포함합니다. 이러한 CR은 RAN과 기본 클러스터 튜닝에 대한 일반적인 클러스터 기능을 제공하는 운영자 세트를 구독합니다. |
|
| 3-노드 클러스터에 대한 RAN 정책만 포함합니다. |
|
| 단일 노드 클러스터에 대한 RAN 정책만 포함합니다. |
|
| 표준 3개의 컨트롤 플레인 클러스터에 대한 RAN 정책을 포함합니다. |
|
|
3-노드 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 |
|
|
|
|
|
|
19.4.4. PolicyGenTemplate CR을 사용하여 관리형 클러스터 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 zero touch provisioning(ZTP) 파이프라인을 사용하여 프로비저닝하는 관리형 클러스터에 적용되는 정책을 사용자 지정합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 필요한 설치 및 정책 CR을 생성하기 위해 hub 클러스터를 구성하셨습니다.
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
절차
사이트별 구성 CR에 대한
PolicyGenTemplateCR을 생성합니다.-
out/argocd/example/policygentemplates폴더(예:example-sno-site.yaml또는example-multinode-site.yaml)에서 CR에 대한 적절한 예를 선택합니다. 예제 파일의
바인딩Rules필드를 siteConfigCR에 포함된 사이트별 레이블과 일치하도록 변경합니다. 예제 siteConfig 파일에서 사이트별 레이블은sites: example-sno입니다.참고PolicyGenTemplatebindingRules필드에 정의된 레이블이 관련 관리 클러스터 siteConfigCR에 정의된 라벨과 일치하는지 확인합니다.- 예제 파일의 내용을 원하는 구성과 일치하도록 변경합니다.
-
선택 사항: 전체 클러스터에 적용되는 공통 구성 CR에 대해
PolicyGenTemplateCR을 생성합니다.-
out/argocd/example/policygentemplates폴더에 있는 CR에 대한 적절한 예를 선택합니다(예:common-ranGen.yaml). - 예제 파일의 내용을 원하는 구성과 일치하도록 변경합니다.
-
선택 사항: 플롯의 특정 클러스터 그룹에 적용되는 모든 그룹 구성 CR에 대해
PolicyGenTemplateCR을 생성합니다.오버라이드 사양 파일의 내용이 원하는 최종 상태와 일치하는지 확인합니다. out/source-crs 디렉터리에는 PolicyGenTemplate 템플릿에서 포함 및 덮어쓸 수 있는 source-crs의 전체 목록이 포함되어 있습니다.
참고클러스터의 특정 요구 사항에 따라 클러스터 유형당 단일 그룹 정책이 필요할 수 있습니다. 특히 예제 그룹 정책에는 동일한 하드웨어 구성으로 구성된 클러스터 세트에서만 공유할 수 있는 단일 PerformancePolicy.yaml 파일이 있습니다.
-
out/argocd/example/policygentemplates폴더(예:group-du-sno-ranGen.yaml)에서 CR에 대한 적절한 예를 선택합니다. - 예제 파일의 내용을 원하는 구성과 일치하도록 변경합니다.
-
-
선택 사항: 검증기를 생성하여 배포된 클러스터의 ZTP 설치 및 구성이 완료될 때 알리도록 정책
PolicyGenTemplateCR에 알릴 수 있습니다. 자세한 내용은 "Create a validator inform policy"를 참조하십시오. out/argocd/example/policygentemplates/ns.yaml파일과 유사한 YAML 파일에 모든 정책 네임스페이스를 정의합니다.중요PolicyGenTemplateCR을 사용하여 동일한 파일에NamespaceCR을 포함하지 마십시오.-
out/argocd/example/policygentemplates/에 표시된 예제와 유사한 generators 섹션의 kustomization.yaml 파일에kustomization.yamlPolicyGenTemplateCR 및NamespaceCR을 추가합니다. Git 리포지토리에
PolicyGenTemplateCR,네임 스페이스CR 및 관련kustomization.yaml파일을 커밋하고 변경 사항을 내보냅니다.ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.
SiteConfigCR과PolicyGenTemplateCR로 동시에 변경 사항을 푸시할 수 있습니다.
19.4.5. 관리형 클러스터 정책 배포 진행 상황 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
ArgoCD 파이프라인은 Git에서 PolicyGenTemplate CR을 사용하여 RHACM 정책을 생성한 다음 hub 클러스터에 동기화합니다. 지원 서비스가 관리형 클러스터에 OpenShift Container Platform을 설치한 후 관리형 클러스터 정책 동기화의 진행 상황을 모니터링할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
Topology Aware Lifecycle Manager (TALM)는 클러스터에 바인딩된 구성 정책을 적용합니다.
클러스터 설치가 완료되고 클러스터가
Ready가 되면 이 클러스터에 해당하는ClusterGroupUpgradeCR과 함께ran.openshift.io/ztp-deploy-wave 주석이 정의된 순서가 지정된 정책 목록이 TALM에 의해 자동으로 생성됩니다. 클러스터의 정책은ClusterGroupUpgradeCR에 나열된 순서대로 적용됩니다.다음 명령을 사용하여 구성 정책 조정의 상위 수준 진행 상황을 모니터링할 수 있습니다.
export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM 대시보드 또는 명령줄을 사용하여 자세한 클러스터 정책 준수 상태를 모니터링할 수 있습니다.
oc를 사용하여 정책 준수를 확인하려면 다음 명령을 실행합니다.oc get policies -n $CLUSTER
$ oc get policies -n $CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM 웹 콘솔에서 정책 상태를 확인하려면 다음 작업을 수행합니다.
- 관리 → 정책 찾기를 클릭합니다.
- 클러스터 정책을 클릭하여 상태를 확인합니다.
모든 클러스터 정책이 호환되면 클러스터의 ZTP 설치 및 구성이 완료됩니다. ztp-done 레이블이 클러스터에 추가되었습니다.
참조 구성에서 준수되는 최종 정책은 *-du-validator-policy 정책에 정의된 정책입니다. 이 정책은 클러스터를 준수하는 경우 모든 클러스터 구성, Operator 설치 및 Operator 구성이 완료되었는지 확인합니다.
19.4.6. 구성 정책 CR 생성 검증 링크 복사링크가 클립보드에 복사되었습니다!
CR(Policy 사용자 정의 리소스)은 생성된 PolicyGenTemplate 과 동일한 네임스페이스에 생성됩니다. 다음 명령을 사용하여 표시된 대로 동일한 문제 해결 흐름은 ztp-common,ztp-group 또는 ztp-site 기반 여부에 관계없이 PolicyGenTemplate 에서 생성된 모든 정책 CR에 적용됩니다.
export NS=<namespace>
$ export NS=<namespace>
oc get policy -n $NS
$ oc get policy -n $NS
정책 줄 바꿈 CR 세트가 표시되어야 합니다.
정책이 동기화에 실패한 경우 다음 문제 해결 단계를 사용하십시오.
절차
정책에 대한 자세한 정보를 표시하려면 다음 명령을 실행합니다.
oc describe -n openshift-gitops application policies
$ oc describe -n openshift-gitops application policiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow Status: Conditions:to show the error logs를 확인합니다. 예를 들어 유효하지 않은sourceFile NetNamespacefileName을 설정하면 아래 표시된 오류가 생성됩니다.Status: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonErrorStatus: Conditions: Last Transition Time: 2021-11-26T17:21:39Z Message: rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1 Type: ComparisonErrorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 상태 확인: 동기화:.Status: Conditions:에 로그 오류가 있는 경우Status: Sync:showsUnknown또는Error:가 표시됩니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM(Red Hat Advanced Cluster Management)이
ManagedCluster오브젝트에 적용되는 정책을 인식할 때 정책 CR 오브젝트가 클러스터 네임스페이스에 적용됩니다. 정책이 클러스터 네임스페이스에 복사되었는지 확인합니다.oc get policy -n $CLUSTER
$ oc get policy -n $CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예:
Copy to Clipboard Copied! Toggle word wrap Toggle overflow RHACM은 적용되는 모든 정책을 클러스터 네임스페이스에 복사합니다. 복사한 정책 이름에는 <
policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName> 형식이 있습니다.클러스터 네임스페이스에 복사되지 않은 정책의 배치 규칙을 확인합니다. 해당 정책에 대한
PlacementRule의matchSelector는ManagedCluster오브젝트의 라벨과 일치해야 합니다.oc get placementrule -n $NS
$ oc get placementrule -n $NSCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 누락된 정책, 일반, 그룹 또는 사이트에 적합한
PlacementRule이름을 기록해 둡니다.oc get placementrule -n $NS <placementRuleName> -o yaml
$ oc get placementrule -n $NS <placementRuleName> -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow - status-decisions에는 클러스터 이름이 포함되어야 합니다.
-
사양에서
matchSelector의 키-값 쌍은 관리 클러스터의 라벨과 일치해야 합니다.
다음 명령을 사용하여
ManagedCluster오브젝트에서 라벨을 확인합니다.oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 어떤 정책이 호환되는지 확인하십시오.
oc get policy -n $CLUSTER
$ oc get policy -n $CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow Namespace,OperatorGroup,Subscription정책이 준수하지만 Operator 구성 정책이 일치하지 않으면 Operator가 관리 클러스터에 설치되지 않은 것입니다. 이로 인해 CRD가 아직 spoke에 적용되지 않기 때문에 Operator 구성 정책이 적용되지 않습니다.
19.4.7. 정책 조정 다시 시작 링크 복사링크가 클립보드에 복사되었습니다!
예를 들어 ClusterGroupUpgrade CR(사용자 정의 리소스)이 시간 초과된 경우 예기치 않은 규정 준수 문제가 발생하면 정책 조정을 다시 시작할 수 있습니다.
절차
관리형 클러스터가
Ready가 되면 Topology Aware Lifecycle Manager의ztp-install네임스페이스에ClusterGroupUpgradeCR이 생성됩니다.export CLUSTER=<clusterName>
$ export CLUSTER=<clusterName>Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc get clustergroupupgrades -n ztp-install $CLUSTER
$ oc get clustergroupupgrades -n ztp-install $CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow 예기치 않은 문제가 발생하고 정책이 구성된 시간 내에 불만이 발생하지 않는 경우 (기본값은 4시간)
ClusterGroupUpgradeCR의 상태에UpgradeTimedOut이 표시됩니다.oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow UpgradeTimedOut상태의ClusterGroupUpgradeCR은 매시간 정책 조정을 자동으로 재시작합니다. 정책을 변경한 경우 기존ClusterGroupUpgradeCR을 삭제하여 즉시 재시도를 시작할 수 있습니다. 이렇게 하면 정책을 즉시 조정하기 시작하는 새ClusterGroupUpgradeCR의 자동 생성이 트리거됩니다.oc delete clustergroupupgrades -n ztp-install $CLUSTER
$ oc delete clustergroupupgrades -n ztp-install $CLUSTERCopy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterGroupUpgrade CR이 UpgradeCompleted 상태로 완료되고 관리 클러스터에 ztp-done 레이블이 적용된 경우 PolicyGenTemplate 을 사용하여 추가 구성을 변경할 수 있습니다. 기존 ClusterGroupUpgrade CR을 삭제하면 TALM이 새 CR을 생성하지 않습니다.
이 시점에서 ZTP는 클러스터와의 상호 작용을 완료했으며 추가 상호 작용을 업데이트로 처리하고 정책 수정을 위해 생성된 새로운 ClusterGroupUpgrade CR을 처리해야 합니다.
19.4.8. 정책을 사용하여 적용된 관리 클러스터 CR 변경 링크 복사링크가 클립보드에 복사되었습니다!
정책을 통해 관리 클러스터에 배포된 CR(사용자 정의 리소스)에서 콘텐츠를 제거할 수 있습니다.
기본적으로 CR에서 생성된 모든 Policy CR에는 Policy GenTemplatecomplianceType 필드가 musthave 로 설정되어 있습니다. 관리 클러스터의 CR에 지정된 콘텐츠가 모두 있으므로 제거된 콘텐츠가 없는 musthave 정책은 계속 호환됩니다. 이 구성을 사용하면 CR에서 콘텐츠를 제거할 때 TALM은 정책에서 콘텐츠를 제거하지만 콘텐츠는 관리 클러스터의 CR에서 제거되지 않습니다.
mustonlyhave 에 complianceType 필드를 사용하면 정책에서 클러스터의 CR이 정책에 지정된 내용과 정확히 일치하도록 합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - RHACM을 실행하는 허브 클러스터에서 관리 클러스터를 배포했습니다.
- hub 클러스터에 Topology Aware Lifecycle Manager를 설치했습니다.
절차
영향을 받는 CR에서 더 이상 필요하지 않은 콘텐츠를 제거합니다. 이 예에서는
disableDrain: false행이SriovOperatorConfigCR에서 제거되었습니다.CR 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 영향을 받는 정책의
complianceType을group-du-sno-ranGen.yaml파일에서mustonlyhave로 변경합니다.YAML의 예
# ... - fileName: SriovOperatorConfig.yaml policyName: "config-policy" complianceType: mustonlyhave # ...
# ... - fileName: SriovOperatorConfig.yaml policyName: "config-policy" complianceType: mustonlyhave # ...Copy to Clipboard Copied! Toggle word wrap Toggle overflow ClusterGroupUpdatesCR을 생성하고 CR 변경 사항을 받아야 하는 클러스터를 지정합니다.ClusterGroupUpdates CR의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ClusterGroupUpgradeCR을 생성합니다.oc create -f cgu-remove.yaml
$ oc create -f cgu-remove.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 적절한 유지 관리 기간 동안 변경 사항을 적용할 준비가 되면 다음 명령을 실행하여
spec.enable필드의 값을true로 변경합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 정책의 상태를 확인합니다.
oc get <kind> <changed_cr_name>
$ oc get <kind> <changed_cr_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 정책의
COMPLIANCE STATE가Compliant인 경우 CR이 업데이트되고 원하지 않는 콘텐츠가 제거됨을 의미합니다.관리 클러스터에서 다음 명령을 실행하여 정책이 대상 클러스터에서 제거되었는지 확인합니다.
oc get <kind> <changed_cr_name>
$ oc get <kind> <changed_cr_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과가 없는 경우 관리 클러스터에서 CR이 제거됩니다.
19.4.9. ZTP 설치에 대한 수행 표시 링크 복사링크가 클립보드에 복사되었습니다!
제로 대화 프로비저닝(ZTP)은 클러스터의 ZTP 설치 상태를 확인하는 프로세스를 단순화합니다. ZTP 상태는 클러스터 설치, 클러스터 구성 및 ZTP의 세 단계로 이동합니다.
- 클러스터 설치 단계
-
클러스터 설치 단계는
ManagedClusterCR의ManagedCluster join및ManagedClusterAvailable조건에 의해 표시됩니다.ManagedClusterCR에 이러한 조건이 없거나 조건이False로 설정된 경우 클러스터는 여전히 설치 단계에 있습니다. 설치에 대한 자세한 내용은AgentClusterInstall및ClusterDeploymentCR에서 확인할 수 있습니다. 자세한 내용은 " GitOps ZTP 문제 해결"을 참조하십시오. - 클러스터 구성 단계
-
클러스터 구성 단계는
ztp-running라벨에 의해 표시됩니다. 클러스터 구성 단계는 클러스터에ManagedClusterCR을 적용했습니다. - ZTP 수행
클러스터 설치 및 구성이 ZTP 완료 단계에서 완료됩니다. 이는
ztp-running레이블을 제거하고ManagedClusterCR에ztp-done라벨을 추가하여 표시됩니다.ztp-done레이블은 구성이 적용되었으며 기준 DU 구성이 클러스터 튜닝을 완료했음을 보여줍니다.ZTP done 상태로 전환하는 것은 RHACM(Red Hat Advanced Cluster Management) 유효성 검사기의 준수 상태에 대한 조건입니다. 이 정책은 완료된 설치에 대한 기존 기준을 캡처하고 관리 클러스터의 ZTP 프로비저닝이 완료된 경우에만 규정 준수 상태로 이동하는지 검증합니다.
유효성 검사기 알림 정책은 클러스터의 구성이 완전히 적용되고 Operator가 초기화를 완료했는지 확인합니다. 정책은 다음을 검증합니다.
-
대상
MachineConfigPool에는 예상 항목이 포함되어 있으며 업데이트를 완료했습니다. 모든 노드를 사용할 수 있으며 성능이 저하되지 않습니다. -
SR-IOV Operator는 하나 이상의
SriovNetworkNodeState에syncStatus: Succeeded에 표시된 초기화를 완료했습니다. - PTP Operator 데몬 세트가 있습니다.
-
대상
19.5. ZTP로 단일 노드 OpenShift 클러스터 수동 설치 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management) 및 지원 서비스를 사용하여 관리형 단일 노드 OpenShift 클러스터를 배포할 수 있습니다.
여러 개의 관리 클러스터를 생성하는 경우 ZTP를 사용하여 멀리 엣지 사이트 배포에 설명된 site Config 방법을 사용하십시오.
대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대한 권장 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.
19.5.1. 수동으로 ZTP 설치 및 구성 CR 생성 링크 복사링크가 클립보드에 복사되었습니다!
ztp-site-generate 컨테이너의 생성기 진입점을 사용하여 site Config 및 PolicyGenTemplate CR을 기반으로 클러스터의 사이트 설치 및 구성 CR(사용자 정의 리소스)을 생성합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
절차
다음 명령을 실행하여 출력 폴더를 생성합니다.
mkdir -p ./out
$ mkdir -p ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow ztp-site-generate컨테이너 이미지에서argocd디렉터리를 내보냅니다.podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow ./out디렉터리에는out/argocd/example/폴더에 참조PolicyGenTemplate및SiteConfigCR이 있습니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사이트 설치 CR의 출력 폴더를 생성합니다.
mkdir -p ./site-install
$ mkdir -p ./site-installCopy to Clipboard Copied! Toggle word wrap Toggle overflow 설치하려는 클러스터 유형의
SiteConfigCR 예제를 수정합니다.example-sno.yaml을site-1-sno.yaml에 복사하고 CR을 수정하여 설치하려는 사이트 및 베어 메탈 호스트의 세부 정보와 일치하도록 수정합니다.단일 노드 OpenShift 클러스터 siteConfig CR의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- site
Config CR과 동일한 네임스페이스를 사용하여을 생성합니다.assisted-deployment-pull-secretCR - 2
clusterImageSetNameRef는 hub 클러스터에서 사용 가능한 이미지 세트를 정의합니다. hub 클러스터에서 지원되는 버전 목록을 보려면oc get clusterimagesets를 실행합니다.- 3
- 클러스터에 액세스하는 데 사용되는 SSH 공개 키를 구성합니다.
- 4
- 클러스터 레이블은 사용자가 정의한
PolicyGenTemplateCR의bindingRules필드에 대응해야 합니다. 예를 들어policygentemplates/common-ranGen.yaml은common: trueset,policygentemplates/group-du-sno-ranGen.yaml이group-du-sno: ""가 설정된 모든 클러스터에 적용됩니다. - 5
- 선택 사항:
KlusterletAddonConfig아래에 있는 CR 사양을 사용하여 클러스터에 대해 생성된 기본KlusterletAddonConfig를 덮어씁니다. - 6
- 단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 3개의 호스트를 정의합니다. 표준 배포의 경우
master와 role으로 정의된 두 개 이상의 호스트인worker를 사용하여 3개의 호스트를 정의합니다. - 7
- 호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다.
- 8
- 호스트 BMC 자격 증명을 사용하여 별도로 생성하는
bmh-secretCR의 이름입니다.bmh-secretCR을 생성할 때 호스트를 프로비저닝하는 siteConfig CR과 동일한 네임스페이스를 사용합니다. - 9
- 호스트의 부팅 모드를 구성합니다. 기본값은
UEFI입니다.UEFISecureBoot를 사용하여 호스트에서 보안 부팅을 활성화합니다. - 10
cpuset는 워크로드 파티셔닝을 위해 클러스터PerformanceProfileCRspec.cpu.reserved필드에 설정된 값과 일치해야 합니다.- 11
- 노드의 네트워크 설정을 지정합니다.
- 12
- 호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다.
다음 명령을 실행하여 수정된 site
ConfigCRsite-1-sno.yaml을 처리하여 day-0 설치 CR을 생성합니다.podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install site-1-sno.yaml /output
$ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-install:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install site-1-sno.yaml /outputCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항:
-E옵션을 사용하여 참조 siteConfigCR을 처리하여 특정 클러스터 유형의 Day-0MachineConfig설치 CR만 생성합니다. 예를 들어 다음 명령을 실행합니다.MachineConfigCR의 출력 폴더를 생성합니다.mkdir -p ./site-machineconfig
$ mkdir -p ./site-machineconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow MachineConfig설치 CR을 생성합니다.podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install -E site-1-sno.yaml /output
$ podman run -it --rm -v `pwd`/out/argocd/example/siteconfig:/resources:Z -v `pwd`/site-machineconfig:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator install -E site-1-sno.yaml /outputCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
site-machineconfig └── site-1-sno ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yamlsite-machineconfig └── site-1-sno ├── site-1-sno_machineconfig_02-master-workload-partitioning.yaml ├── site-1-sno_machineconfig_predefined-extra-manifests-master.yaml └── site-1-sno_machineconfig_predefined-extra-manifests-worker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
이전 단계의 참조를 사용하여 Day-2
구성 CR을 생성하고 내보냅니다. 다음 명령을 실행합니다.2일 차 CR의 출력 폴더를 생성합니다.
mkdir -p ./ref
$ mkdir -p ./refCopy to Clipboard Copied! Toggle word wrap Toggle overflow Day-2 구성 CR을 생성하고 내보냅니다.
podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator config -N . /output
$ podman run -it --rm -v `pwd`/out/argocd/example/policygentemplates:/resources:Z -v `pwd`/ref:/output:Z,U registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 generator config -N . /outputCopy to Clipboard Copied! Toggle word wrap Toggle overflow 이 명령은 단일 노드 OpenShift, 3 노드 클러스터 및
./ref폴더에 표준 클러스터에 대한 예제 그룹 및 사이트별PolicyGenTemplateCR을 생성합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 생성된 CR을 클러스터를 설치하는 데 사용하는 CR의 기준으로 사용합니다. "단일 관리 클러스터 설치"에 설명된 대로 hub 클러스터에 설치 CR을 적용합니다. 클러스터 설치가 완료된 후 구성 CR을 클러스터에 적용할 수 있습니다.
19.5.2. 관리형 베어 메탈 호스트 시크릿 생성 링크 복사링크가 클립보드에 복사되었습니다!
관리 베어 메탈 호스트에 필요한 Secret CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. 레지스트리에서 클러스터 설치 이미지를 가져오기 위해 BMC(Baseboard Management Controller) 및 지원 설치 서비스 시크릿에 액세스하려면 ZTP 파이프라인의 시크릿이 필요합니다.
보안은 이름으로 site Config CR 에서 참조됩니다. 네임스페이스는 SiteConfig 네임스페이스와 일치해야 합니다.
절차
OpenShift 및 모든 애드온 클러스터 Operator를 설치하는 데 필요한 BMC(Host Baseboard Management Controller) 및 풀 시크릿(pull secret)의 인증 정보가 포함된 YAML 시크릿 파일을 생성합니다.
-
클러스터를 설치하는 데 사용하는
kustomization.yaml파일에 상대 경로를example-sno-secret.yaml에 추가합니다.
19.5.3. GitOps ZTP를 사용하여 수동 설치에 대한 Discovery ISO 커널 인수 구성 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP 워크플로는 관리형 베어 메탈 호스트에서 OpenShift Container Platform 설치 프로세스의 일부로 Discovery ISO를 사용합니다. InfraEnv 리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어, 클러스터의 정적 네트워킹을 용이하게 하거나 설치 중에 루트 파일 시스템을 다운로드하기 전에 DHCP 주소를 수신하도록 Discovery ISO의 rd.net.timeout.carrier 커널 인수를 구성합니다.
OpenShift Container Platform 4.12에서는 커널 인수만 추가할 수 있습니다. 커널 인수를 교체하거나 삭제할 수 없습니다.
사전 요구 사항
- OpenShift CLI(oc)가 설치되어 있습니다.
- cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
- 설치 및 구성 CR(사용자 정의 리소스)을 수동으로 생성했습니다.
절차
-
InfraEnvCR에서spec.kernelArguments사양을 편집하여 커널 인수를 구성합니다.
site Config CR은 Day-0 설치 CR의 일부로 InfraEnv 리소스를 생성합니다.
검증
커널 인수가 적용되었는지 확인하려면 Discovery 이미지에서 OpenShift Container Platform을 설치할 준비가 되었는지 확인한 후 설치 프로세스가 시작되기 전에 대상 호스트에 SSH를 실행할 수 있습니다. 이 시점에서 /proc/cmdline 파일에서 Discovery ISO의 커널 인수를 볼 수 있습니다.
대상 호스트를 사용하여 SSH 세션을 시작합니다.
ssh -i /path/to/privatekey core@<host_name>
$ ssh -i /path/to/privatekey core@<host_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.
cat /proc/cmdline
$ cat /proc/cmdlineCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.4. 단일 관리형 클러스터 설치 링크 복사링크가 클립보드에 복사되었습니다!
지원 서비스 및 RHACM(Red Hat Advanced Cluster Management)을 사용하여 단일 관리 클러스터를 수동으로 배포할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. -
베이스 보드 관리 컨트롤러 (BMC)
Secret및 이미지 pull-secretSecret(CR)을 생성했습니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오. - 대상 베어 메탈 호스트는 관리 클러스터의 네트워킹 및 하드웨어 요구 사항을 충족합니다.
절차
배포할 각 특정 클러스터 버전에 대한
ClusterImageSet을 생성합니다(예:clusterImageSet-4.12.yaml).ClusterImageSet의 형식은 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow clusterImageSetCR을 적용합니다.oc apply -f clusterImageSet-4.12.yaml
$ oc apply -f clusterImageSet-4.12.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-namespace.yaml파일에NamespaceCR을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
NamespaceCR을 적용합니다.oc apply -f cluster-namespace.yaml
$ oc apply -f cluster-namespace.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ztp-site-generate컨테이너에서 추출하고 요구 사항을 충족하도록 사용자 정의된 생성된 day-0 CR을 적용합니다.oc apply -R ./site-install/site-sno-1
$ oc apply -R ./site-install/site-sno-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.5. 관리형 클러스터 설치 상태 모니터링 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 상태를 확인하여 클러스터 프로비저닝에 성공했는지 확인합니다.
사전 요구 사항
-
모든 사용자 정의 리소스가 구성 및 프로비저닝되었으며
Agent사용자 정의 리소스는 관리형 클러스터의 허브에 생성됩니다.
절차
관리 클러스터의 상태를 확인합니다.
oc get managedcluster
$ oc get managedclusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow true는 관리 클러스터가 준비되었음을 나타냅니다.에이전트 상태를 확인합니다.
oc get agent -n <cluster_name>
$ oc get agent -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow describe명령을 사용하여 에이전트 상태에 대한 심층적인 설명을 제공합니다. Statuss to be aware of includeBackendError,InputError,ValidationsFailing,InstallationFailed, andAgentIsConnected. 이러한 상태는Agent및AgentClusterInstall사용자 정의 리소스와 관련이 있습니다.oc describe agent -n <cluster_name>
$ oc describe agent -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터 프로비저닝 상태를 확인합니다.
oc get agentclusterinstall -n <cluster_name>
$ oc get agentclusterinstall -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow describe명령을 사용하여 클러스터 프로비저닝 상태에 대한 심층적인 설명을 제공합니다.oc describe agentclusterinstall -n <cluster_name>
$ oc describe agentclusterinstall -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 클러스터의 애드온 서비스의 상태를 확인합니다.
oc get managedclusteraddon -n <cluster_name>
$ oc get managedclusteraddon -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리형 클러스터에 대한
kubeconfig파일의 인증 정보를 검색합니다.oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig$ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.5.6. 관리형 클러스터 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터에서 발생할 수 있는 설치 문제를 진단하려면 다음 절차를 사용하십시오.
절차
관리 클러스터의 상태를 확인합니다.
oc get managedcluster
$ oc get managedclusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE SNO-cluster true True True 2d19h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE SNO-cluster true True True 2d19hCopy to Clipboard Copied! Toggle word wrap Toggle overflow AVAILABLE열의 상태가True이면 관리 클러스터는 허브에 의해 관리되고 있습니다.AVAILABLE열의 상태가알 수 없는경우 관리 클러스터는 허브에서 관리하지 않습니다. 더 많은 정보를 얻으려면 다음 단계를 따르십시오.AgentClusterInstall설치 상태를 확인합니다.oc get clusterdeployment -n <cluster_name>
$ oc get clusterdeployment -n <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME PLATFORM REGION CLUSTERTYPE INSTALLED INFRAID VERSION POWERSTATE AGE Sno0026 agent-baremetal false Initialized 2d14h
NAME PLATFORM REGION CLUSTERTYPE INSTALLED INFRAID VERSION POWERSTATE AGE Sno0026 agent-baremetal false Initialized 2d14hCopy to Clipboard Copied! Toggle word wrap Toggle overflow INSTALLED열의 상태가false이면 설치에 실패합니다.설치에 실패한 경우 다음 명령을 입력하여
AgentClusterInstall리소스의 상태를 검토합니다.oc describe agentclusterinstall -n <cluster_name> <cluster_name>
$ oc describe agentclusterinstall -n <cluster_name> <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 오류를 해결하고 클러스터를 재설정합니다.
클러스터의 관리 클러스터 리소스를 제거합니다.
oc delete managedcluster <cluster_name>
$ oc delete managedcluster <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터의 네임스페이스를 제거합니다.
oc delete namespace <cluster_name>
$ oc delete namespace <cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이렇게 하면 이 클러스터에 대해 생성된 모든 네임스페이스 범위의 사용자 정의 리소스가 삭제됩니다. 계속하기 전에
ManagedClusterCR 삭제가 완료될 때까지 기다려야 합니다.- 관리 클러스터의 사용자 정의 리소스를 다시 생성합니다.
19.5.7. RHACM 생성 클러스터 설치 CR 참조 링크 복사링크가 클립보드에 복사되었습니다!
RHACM(Red Hat Advanced Cluster Management)은 각 사이트에 대해 site Config CR을 사용하여 생성하는 특정 설치 사용자 정의 리소스(CR) 세트가 있는 단일 노드 클러스터, 3-노드 클러스터, 표준 클러스터 배포를 지원합니다.
모든 관리형 클러스터에는 고유한 네임스페이스가 있으며 ManagedCluster 및 ClusterImageSet 을 제외한 모든 설치 CR이 해당 네임스페이스에 있습니다. ManagedCluster 및 ClusterImageSet 은 네임스페이스 범위가 아닌 cluster-scoped입니다. 네임스페이스 및 CR 이름은 클러스터 이름과 일치합니다.
다음 표에는 구성하는 site Config CR을 사용하여 클러스터를 설치할 때 RHACM 지원 서비스에서 자동으로 적용하는 설치 CR이 나열되어 있습니다.
| CR | 설명 | 사용법 |
|---|---|---|
|
| 대상 베어 메탈 호스트의 BMC(Baseboard Management Controller)에 대한 연결 정보가 포함되어 있습니다. | Redfish 프로토콜을 사용하여 대상 서버에서 검색 이미지를 로드하고 시작할 BMC에 대한 액세스를 제공합니다. |
|
| 대상 베어 메탈 호스트에 OpenShift Container Platform을 설치하는 데 필요한 정보를 포함합니다. |
|
|
|
네트워킹 및 컨트롤 플레인 노드 수와 같은 관리 클러스터 구성의 세부 정보를 지정합니다. 설치가 완료되면 클러스터 | 관리형 클러스터 구성 정보를 지정하고 클러스터를 설치하는 동안 상태를 제공합니다. |
|
|
사용할 |
|
|
|
| 관리형 클러스터 Kube API 서버의 고정 IP 주소를 설정합니다. |
|
| 대상 베어 메탈 호스트에 대한 하드웨어 정보를 포함합니다. | 대상 시스템의 검색 이미지가 부팅될 때 허브에서 자동으로 생성됩니다. |
|
| 허브에서 클러스터를 관리하려면 클러스터를 가져오고 알아야 합니다. 이 Kubernetes 오브젝트는 해당 인터페이스를 제공합니다. | 허브는 이 리소스를 사용하여 관리 클러스터의 상태를 관리하고 표시합니다. |
|
|
|
|
|
|
hub의 |
리소스를 |
|
|
|
|
|
| 리포지토리 및 이미지 이름과 같은 OpenShift Container Platform 이미지 정보가 포함되어 있습니다. | OpenShift Container Platform 이미지를 제공하기 위해 리소스로 전달됩니다. |
19.6. vDU 애플리케이션 워크로드에 권장되는 단일 노드 OpenShift 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 참조 정보를 사용하여 클러스터에서 vDU(가상 분산 단위) 애플리케이션을 배포하는 데 필요한 단일 노드 OpenShift 구성을 파악합니다. 구성에는 고성능 워크로드를 위한 클러스터 최적화, 워크로드 파티셔닝 활성화, 설치 후 필요한 재부팅 횟수 최소화가 포함됩니다.
19.6.1. OpenShift Container Platform에서 짧은 대기 시간 애플리케이션 실행 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform을 사용하면 다음과 같은 여러 기술 및 특수 하드웨어 장치를 사용하여 COTS(상용 장치) 하드웨어에서 실행되는 애플리케이션의 대기 시간을 단축할 수 있습니다.
- RHCOS용 실시간 커널
- 높은 수준의 프로세스 결정성으로 워크로드 처리 가능.
- CPU 격리
- CPU 스케줄링 지연을 방지하고 CPU 용량을 일관되게 사용할 수 있도록 합니다.
- NUMA 인식 토폴로지 관리
- CPU 및 PCI 장치와 메모리 및 대규모 페이지를 조정하여 보장된 컨테이너 메모리 및 대규모 페이지를 NUMA(Non-Uniform Memory Access) 노드에 고정합니다. 모든 QoS(Quality of Service) 클래스에 대한 Pod 리소스는 동일한 NUMA 노드에 남아 있습니다. 이렇게 하면 대기 시간이 줄어들고 노드의 성능이 향상됩니다.
- 대규모 페이지 메모리 관리
- 대규모 페이지 크기를 사용하면 페이지 테이블에 액세스하는 데 필요한 시스템 리소스의 양을 줄임으로써 시스템 성능이 향상됩니다.
- PTP를 사용한 정밀 타이밍 동기화
- 네트워크의 노드 간 동기화를 하위 마이크로초 정확도로 허용합니다.
19.6.2. vDU 애플리케이션 워크로드에 대한 권장되는 클러스터 호스트 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
vDU 애플리케이션 워크로드를 실행하려면 OpenShift Container Platform 서비스 및 프로덕션 워크로드를 실행하기에 충분한 리소스가 있는 베어 메탈 호스트가 필요합니다.
| Profile | vCPU | 메모리 | 스토리지 |
|---|---|---|---|
| 최소 | 4에서 8 vCPU | 32GB RAM | 120GB |
하나의 vCPU는 하나의 물리적 코어와 동일합니다. 그러나 동시 멀티스레딩(SMT) 또는 Hyper-Threading을 활성화하면 다음 공식을 사용하여 하나의 물리적 코어를 나타내는 vCPU 수를 계산합니다.
- (threads per core × cores) × sockets = vCPUs
가상 미디어를 사용하여 부팅할 때 서버에 BMC(Baseboard Management Controller)가 있어야 합니다.
19.6.3. 짧은 대기 시간과 고성능을 위해 호스트 펌웨어 구성 링크 복사링크가 클립보드에 복사되었습니다!
베어 메탈 호스트를 사용하려면 호스트를 프로비저닝하기 전에 펌웨어를 구성해야 합니다. 펌웨어 구성은 특정 하드웨어 및 설치 요구 사항에 따라 다릅니다.
절차
-
UEFI/BIOS 부팅 모드 를
UEFI로 설정합니다. - 호스트 부팅 순서 순서에서 먼저 하드 드라이브를 설정합니다.
하드웨어에 대한 특정 펌웨어 구성을 적용합니다. 다음 표에서는 Intel Xeon Skylake 또는 Intel Cascade Lake 서버에 대한 대표 펌웨어 구성을 설명합니다. 이는 IntelECDHERAN 4G 및 5G 베이스bandECDHEY 참조 설계를 기반으로 합니다.
중요정확한 펌웨어 구성은 특정 하드웨어 및 네트워크 요구 사항에 따라 다릅니다. 다음 샘플 구성은 설명 목적으로만 사용됩니다.
Expand 표 19.7. Intel Xeon Skylake 또는 Cascade Lake 서버의 펌웨어 구성 샘플 펌웨어 설정 설정 CPU 전원 및 성능 정책
성능
Uncore Frequency Scaling
disabled
성능 P-limit
disabled
강화된 Intel SpeedStep ® Tech
enabled
Intel Configurable TDP
enabled
구성 가능한 TDP 수준
수준 2
Intel® declared Boost Technology
enabled
기술 지원
disabled
하드웨어 P-States
disabled
패키지 C-State
C0/C1 상태
C1E
disabled
프로세서 C6
disabled
호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.
19.6.4. 관리형 클러스터 네트워크에 대한 연결 사전 요구 사항 링크 복사링크가 클립보드에 복사되었습니다!
zero touch provisioning(ZTP) GitOps 파이프라인을 사용하여 관리 클러스터를 설치하고 프로비저닝하려면 먼저 관리 클러스터 호스트가 다음 네트워킹 사전 요구 사항을 충족해야 합니다.
- hub 클러스터의 ZTP GitOps 컨테이너와 대상 베어 메탈 호스트의 BMC(Baseboard Management Controller) 간에 양방향 연결이 있어야 합니다.
관리 클러스터는 hub hostname 및
*.apps호스트 이름의 API 호스트 이름을 확인하고 도달할 수 있어야 합니다. 다음은 허브의 API 호스트 이름과*.apps호스트 이름의 예입니다.-
api.hub-cluster.internal.domain.com -
console-openshift-console.apps.hub-cluster.internal.domain.com
-
hub 클러스터는 관리형 클러스터의 API 및
*.apps호스트 이름을 확인하고 도달할 수 있어야 합니다. 다음은 관리형 클러스터의 API 호스트 이름과*.apps호스트 이름의 예입니다.-
api.sno-managed-cluster-1.internal.domain.com -
console-openshift-console.apps.sno-managed-cluster-1.internal.domain.com
-
19.6.5. GitOps ZTP를 사용한 단일 노드 OpenShift의 워크로드 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
워크로드 파티셔닝에서는 예약된 수의 호스트 CPU에서 실행되도록 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 구성합니다.
GitOps ZTP를 사용하여 워크로드 파티셔닝을 구성하려면 site Config CR(사용자 정의 리소스)의 cpuset 필드와 그룹 PolicyGenTemplate CR의 reserved 필드를 사용하여 클러스터 관리 CPU 리소스를 지정합니다. GitOps ZTP 파이프라인은 이러한 값을 사용하여 단일 노드 OpenShift 클러스터를 구성하는 워크로드 파티셔닝 MachineConfig CR(CPU세트) 및 PerformanceProfile CR(reserved)의 필수 필드를 채웁니다.
최대 성능의 경우 예약 된 CPU 세트와 분리된 CPU 세트가 NUMA 영역의 CPU 코어를 공유하지 않는지 확인합니다.
-
워크로드 파티셔닝
MachineConfigCR은 OpenShift Container Platform 인프라 Pod를 정의된cpuset구성에 고정합니다. -
PerformanceProfileCR은 systemd 서비스를 예약된 CPU에 고정합니다.
PerformanceProfile CR에 지정된 reserved 필드의 값은 워크로드 파티셔닝 MachineConfig CR의 cpuset 필드와 일치해야 합니다.
19.6.6. 권장되는 설치 시간 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
ZTP 파이프라인은 클러스터 설치 중에 다음 CR(사용자 정의 리소스)을 적용합니다. 이러한 구성 CR은 클러스터가 vDU 애플리케이션 실행에 필요한 기능 및 성능 요구 사항을 충족하는지 확인합니다.
클러스터 배포에 ZTP GitOps 플러그인 및 siteConfig CR을 사용하는 경우 기본적으로 다음 MachineConfig CR이 포함됩니다.
site Config extraManifests 필터를 사용하여 기본적으로 포함된 CR을 변경합니다. 자세한 내용은 SiteConfig CR을 사용한 고급 관리 클러스터 구성 을 참조하십시오.
19.6.6.1. 워크로드 파티셔닝 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 워크로드 분할이 필요합니다. 이로 인해 플랫폼 서비스를 실행할 수 있는 코어가 제한되어 애플리케이션 페이로드에 대한 CPU 코어가 증가합니다.
워크로드 파티션은 클러스터 설치 중에만 활성화할 수 있습니다. 워크로드 파티션 설치 후 비활성화할 수 없습니다. 그러나 성능 프로필에 정의된 cpu 값과 관련 MachineConfig 사용자 정의 리소스(CR)를 업데이트하여 워크로드 파티션을 재구성할 수 있습니다.
워크로드 파티셔닝을 가능하게 하는 base64로 인코딩된 CR에는 관리 워크로드가 제한된 CPU 세트가 포함됩니다.
crio.conf및kubelet.conf의 호스트별 값을 base64로 인코딩합니다. 클러스터 성능 프로필에 지정된 CPU 세트와 일치하도록 콘텐츠를 조정합니다. 클러스터 호스트의 코어 수와 일치해야 합니다.권장되는 워크로드 파티션 구성
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터 호스트에 구성하면
/etc/crio/crio.conf.d/01-workload-partitioning의 내용은 다음과 같아야 합니다.[crio.runtime.workloads.management] activation_annotation = "target.workload.openshift.io/management" annotation_prefix = "resources.workload.openshift.io" resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }[crio.runtime.workloads.management] activation_annotation = "target.workload.openshift.io/management" annotation_prefix = "resources.workload.openshift.io" resources = { "cpushares" = 0, "cpuset" = "0-1,52-53" }1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpuset값은 설치에 따라 다릅니다. Hyper-Threading이 활성화된 경우 각 코어에 대해 두 스레드를 모두 지정합니다.cpuset값은 성능 프로필의spec.cpu.reserved필드에 정의된 예약된 CPU와 일치해야 합니다.
클러스터에서 구성하면
/etc/kubernetes/openshift-workload-pinning의 내용은 다음과 같아야 합니다.{ "management": { "cpuset": "0-1,52-53" } }{ "management": { "cpuset": "0-1,52-53"1 } }Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cpuset는/etc/crio/crio.conf.d/01-workload-partitioning의cpuset값과 일치해야 합니다.
검증
애플리케이션과 클러스터 시스템 CPU 고정이 올바른지 확인합니다. 다음 명령을 실행합니다.
관리 클러스터에 대한 원격 쉘 연결을 엽니다.
oc debug node/example-sno-1
$ oc debug node/example-sno-1Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift 인프라 애플리케이션 CPU 고정이 올바른지 확인합니다.
pgrep ovn | while read i; do taskset -cp $i; done
sh-4.4# pgrep ovn | while read i; do taskset -cp $i; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 시스템 애플리케이션 CPU 고정이 올바른지 확인합니다.
pgrep systemd | while read i; do taskset -cp $i; done
sh-4.4# pgrep systemd | while read i; do taskset -cp $i; doneCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
pid 1's current affinity list: 0-1,52-53 pid 938's current affinity list: 0-1,52-53 pid 962's current affinity list: 0-1,52-53 pid 1197's current affinity list: 0-1,52-53
pid 1's current affinity list: 0-1,52-53 pid 938's current affinity list: 0-1,52-53 pid 962's current affinity list: 0-1,52-53 pid 1197's current affinity list: 0-1,52-53Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.6.6.2. 플랫폼 관리 공간 감소 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼의 전반적인 관리 풋프린트를 줄이기 위해 MachineConfig 사용자 정의 리소스 (CR)는 새 네임스페이스에 모든 Kubernetes별 마운트 지점을 호스트 운영 체제와 별도로 배치해야합니다. 다음 base64로 인코딩된 예제 MachineConfig CR은 이 구성을 보여줍니다.
권장되는 컨테이너 마운트 네임스페이스 구성
19.6.6.3. SCTP 링크 복사링크가 클립보드에 복사되었습니다!
SCTP(스트림 제어 전송 프로토콜)는 RAN 애플리케이션에서 사용되는 주요 프로토콜입니다. 이 MachineConfig 오브젝트는 이 프로토콜을 활성화하기 위해 SCTP 커널 모듈을 노드에 추가합니다.
권장되는 SCTP 구성
19.6.6.4. 컨테이너 시작 가속화 링크 복사링크가 클립보드에 복사되었습니다!
다음 MachineConfig CR은 시스템 시작 및 종료 중에 사용 가능한 모든 CPU 코어를 사용하도록 핵심 OpenShift 프로세스 및 컨테이너를 구성합니다. 따라서 초기 부팅 및 재부팅 중에 시스템 복구가 빨라집니다.
권장되는 가속화 컨테이너 시작 구성
19.6.6.5. kdump를 사용한 자동 커널 충돌 덤프 링크 복사링크가 클립보드에 복사되었습니다!
kdump Linux 커널 기능은 커널이 충돌할 때 커널 크래시 덤프를 생성합니다. kdump 기능은 다음 MachineConfig CR을 사용하여 활성화됩니다.
컨트롤 플레인 kdump 로그에서 원래 드라이버를 제거하려면 MachineConfig CR을 권장함 (05-kdump-config-master.yaml)
권장 컨트롤 플레인 노드 kdump 구성 (06-kdump-master.yaml)
작업자 노드 kdump 로그에서 원래 드라이버를 제거하려면 MachineConfig CR을 권장함 (05-kdump-config-worker.yaml)
권장 kdump 작업자 노드 구성 (06-kdump-worker.yaml)
19.6.7. 설치 후 클러스터 구성 권장 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 설치가 완료되면 ZTP 파이프라인에서 DU 워크로드를 실행하는 데 필요한 다음 CR(사용자 정의 리소스)을 적용합니다.
{ztp} v4.10 및 이전 버전에서는 MachineConfig CR을 사용하여 UEFI 보안 부팅을 구성합니다. {ztp} v4.11 이상에서는 더 이상 필요하지 않습니다. v4.11에서는 클러스터를 설치하는 데 사용하는 site Config CR에서 spec.clusters.nodes.bootMode 필드를 업데이트하여 단일 노드 OpenShift 클러스터에 대해 UEFI 보안 부팅을 구성합니다. 자세한 내용은 site Config 및 {ztp}를 사용하여 관리되는 클러스터 배포를 참조하십시오.
19.6.7.1. Operator 네임스페이스 및 Operator groups 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 다음 OperatorGroup 및 Namespace CR(사용자 정의 리소스)이 필요합니다.
- Local Storage Operator
- Operator 로깅
- PTP Operator
- SR-IOV 네트워크 Operator
다음 YAML은 이러한 CR을 요약합니다.
권장되는 Operator 네임스페이스 및 OperatorGroup 구성
19.6.7.2. Operator 서브스크립션 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 다음과 같은 Subscription CR이 필요합니다. 서브스크립션은 다음 Operator를 다운로드할 수 있는 위치를 제공합니다.
- Local Storage Operator
- Operator 로깅
- PTP Operator
- SR-IOV 네트워크 Operator
권장되는 Operator 서브스크립션
19.6.7.3. 클러스터 로깅 및 로그 전달 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 디버깅을 위해 로깅 및 로그 전달이 필요합니다. 다음 예제 YAML은 필수 ClusterLogging 및 ClusterLogForwarder CR을 보여줍니다.
권장되는 클러스터 로깅 및 로그 전달 구성
19.6.7.4. 성능 프로필 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 실시간 호스트 기능 및 서비스를 사용하려면 Node Tuning Operator 성능 프로파일이 필요합니다.
이전 버전의 OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현하기 위해 자동 튜닝을 구현하는 데 Performance Addon Operator를 사용했습니다. OpenShift Container Platform 4.11 이상에서는 이 기능은 Node Tuning Operator의 일부입니다.
다음 예제 PerformanceProfile CR은 필요한 클러스터 구성을 보여줍니다.
권장되는 성능 프로파일 구성
- 1
이름값이TunedPerformancePatch.yaml의spec.profile.data필드에 지정된 값과 일치하고validatorCRs/informDuValidator.yaml의status.configuration.source.name필드와 일치하는지 확인합니다.- 2
- 클러스터 호스트에 대한 UEFI 보안 부팅을 구성합니다.
- 3
- 분리된 CPU를 설정합니다. 모든 하이퍼 스레딩 쌍이 일치하는지 확인합니다.중요
예약 및 분리된 CPU 풀은 겹치지 않아야 하며 함께 사용 가능한 모든 코어에 걸쳐 있어야 합니다. 고려하지 않은 CPU 코어로 인해 시스템에서 정의되지 않은 동작이 발생합니다.
- 4
- 예약된 CPU를 설정합니다. 워크로드 파티셔닝이 활성화되면 시스템 프로세스, 커널 스레드 및 시스템 컨테이너 스레드가 이러한 CPU로 제한됩니다. 분리되지 않은 모든 CPU는 예약해야 합니다.
- 5
- 대규모 페이지 수를 설정합니다.
- 6
- 대규모 페이지 크기를 설정합니다.
- 7
node를hugepages가 할당된 NUMA 노드로 설정합니다.- 8
- 실시간 Linux 커널을 설치하려면
enabled를true로 설정합니다.
19.6.7.5. 클러스터 시간 동기화 구성 링크 복사링크가 클립보드에 복사되었습니다!
컨트롤 플레인 또는 작업자 노드에 대한 일회성 시스템 시간 동기화 작업을 실행합니다.
컨트롤 플레인 노드에 대해 한 번의 시간 동기화 (99-sync-time-once-master.yaml)
작업자 노드에 대해 한 번의 시간 동기화 (99-sync-time-once-worker.yaml)
19.6.7.6. PTP 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 클러스터는 네트워크 시간 동기화에 PTP(Precision Time Protocol)를 사용합니다. 다음 예제 PtpConfig CR은 필요한 PTP 슬레이브 구성을 보여줍니다.
권장되는 PTP 구성
- 1
- PTP 클럭 신호를 수신하는 데 사용되는 인터페이스를 설정합니다.
19.6.7.7. 확장 Tuned 프로파일 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 고성능 워크로드에 필요한 추가 성능 튜닝 구성이 필요합니다. 다음 예제 Tuned CR은 Tuned 프로필을 확장합니다.
권장되는 확장 Tuned 프로파일 구성
19.6.7.8. SR-IOV 링크 복사링크가 클립보드에 복사되었습니다!
SR-IOV(Single Root I/O virtualization)는 일반적으로 fronthaul 및 midhaul 네트워크를 활성화하는 데 사용됩니다. 다음 YAML 예제에서는 단일 노드 OpenShift 클러스터에 대해 SR-IOV를 구성합니다.
권장되는 SR-IOV 구성
19.6.7.9. Console Operator 링크 복사링크가 클립보드에 복사되었습니다!
console-operator는 클러스터에서 웹 콘솔을 설치하고 유지 관리합니다. 노드를 중앙에서 관리할 때 Operator가 필요하지 않고 애플리케이션 워크로드를 위한 공간을 만듭니다. 다음 콘솔 CR(사용자 정의 리소스) 예에서는 콘솔을 비활성화합니다.
권장되는 콘솔 구성
19.6.7.10. Alertmanager 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 OpenShift Container Platform 모니터링 구성 요소에서 사용하는 CPU 리소스가 감소해야 합니다. 다음 ConfigMap CR(사용자 정의 리소스)은 Alertmanager를 비활성화합니다.
권장되는 클러스터 모니터링 구성
19.6.7.11. Operator Lifecycle Manager 링크 복사링크가 클립보드에 복사되었습니다!
분산 단위 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 CPU 리소스에 대한 일관된 액세스 권한이 필요합니다. OLM(Operator Lifecycle Manager)은 정기적으로 Operator에서 성능 데이터를 수집하여 CPU 사용률이 증가합니다. 다음 ConfigMap CR(사용자 정의 리소스)은 OLM의 Operator 성능 데이터 수집을 비활성화합니다.
권장되는 클러스터 OLM 구성(ReduceOLMFootprint.yaml)
19.6.7.12. 네트워크 진단 링크 복사링크가 클립보드에 복사되었습니다!
DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 Pod에서 생성하는 추가 로드를 줄이기 위해 포드 간 네트워크 연결 검사가 줄어듭니다. 다음 CR(사용자 정의 리소스)은 이러한 검사를 비활성화합니다.
권장되는 네트워크 진단 구성
19.7. vDU 애플리케이션 워크로드에 대한 단일 노드 OpenShift 클러스터 튜닝 검증 링크 복사링크가 클립보드에 복사되었습니다!
vDU(가상 분산 장치) 애플리케이션을 배포하기 전에 클러스터 호스트 펌웨어 및 기타 다양한 클러스터 구성 설정을 튜닝하고 구성해야 합니다. 다음 정보를 사용하여 vDU 워크로드를 지원하는 클러스터 구성의 유효성을 검증합니다.
19.7.1. vDU 클러스터 호스트에 권장되는 펌웨어 구성 링크 복사링크가 클립보드에 복사되었습니다!
다음 표를 기준으로 사용하여 OpenShift Container Platform 4.12에서 실행되는 vDU 애플리케이션의 클러스터 호스트 펌웨어를 구성합니다.
다음 표는 vDU 클러스터 호스트 펌웨어 구성에 대한 일반적인 권장 사항입니다. 정확한 펌웨어 설정은 요구 사항 및 특정 하드웨어 플랫폼에 따라 다릅니다. 펌웨어 자동 설정은 제로 툴 프로비저닝 파이프라인에 의해 처리되지 않습니다.
| 펌웨어 설정 | 설정 | 설명 |
|---|---|---|
| HyperTransport (HT) | enabled | HyperTransport (HT) 버스는 AMD에서 개발한 버스 기술입니다. HT는 호스트 메모리의 구성 요소와 다른 시스템 주변 장치 간의 고속 링크를 제공합니다. |
| UEFI | enabled | vDU 호스트의 UEFI에서 부팅을 활성화합니다. |
| CPU 전원 및 성능 정책 | 성능 | CPU 전원 및 성능 정책을 설정하여 전력 효율성보다 성능을 최적화합니다. |
| Uncore Frequency Scaling | disabled | CPU가 아닌 부분의 가중 및 빈도가 독립적으로 설정되지 않도록 Uncore Frequency 스케일링을 비활성화합니다. |
| Uncore Frequency | 최대 | 캐시 및 메모리 컨트롤러와 같은 CPU의 코어가 아닌 부분을 최대 작업 빈도로 설정합니다. |
| 성능 P-limit | disabled | 프로세서의 Uncore 빈도 조정되지 않도록 성능 P-limit를 비활성화합니다. |
| 향상된 Intel® SpeedStep Tech | enabled | 강화된 Intel SpeedStep을 사용하면 시스템이 호스트의 전력 소비와 heat 프로덕션을 줄이는 프로세서의 부족과 코어 빈도를 동적으로 조정할 수 있습니다. |
| Intel® declared Boost Technology | enabled | 활성화된 Intel 기반 CPU용 FeatureGate Boost Technology를 사용하면 프로세서 코어가 전력, 현재 및 온도 사양 제한 미만의 작동 빈도보다 프로세서 코어를 자동으로 실행할 수 있습니다. |
| Intel Configurable TDP | enabled | CPU에 대해 TDP(rmal Design Power)를 활성화합니다. |
| 구성 가능한 TDP 수준 | 수준 2 | TDP 수준은 특정 성능 등급에 필요한 CPU 전력 사용량을 설정합니다. TDP 레벨 2는 전력 소비에 따라 CPU를 가장 안정적인 성능 수준으로 설정합니다. |
| 기술 지원 | disabled | VMC Efficient FeatureGate를 비활성화하여 프로세서가 전력 효율성 기반 정책을 사용하지 못하도록 합니다. |
| 하드웨어 P-States | Enabled 또는 Disabled |
OS를 제어하는 P-State를 활성화하여 절전 구성을 허용합니다. |
| 패키지 C-State | C0/C1 상태 | C0 또는 C1 상태를 사용하여 프로세서를 완전히 활성 상태(C0)로 설정하거나 소프트웨어 (C1)에서 실행되는 CPU 내부 클럭을 중지합니다. |
| C1E | disabled | CPU Enhanced Halt (C1E)는 Intel 칩의 전력 절약 기능입니다. C1E를 비활성화하면 운영 체제가 비활성화될 때 CPU에 stop 명령을 보내지 않습니다. |
| 프로세서 C6 | disabled | C6 절전은 유휴 CPU 코어 및 캐시를 자동으로 비활성화하는 CPU 기능입니다. C6을 비활성화하면 시스템 성능이 향상됩니다. |
| 하위 NUMA 클러스터링 | disabled | 하위 NUMA 클러스터링은 프로세서 코어, 캐시 및 메모리를 여러 NUMA 도메인으로 나눕니다. 이 옵션을 비활성화하면 대기 시간에 민감한 워크로드의 성능이 향상될 수 있습니다. |
호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.
C-states 및 OS-controlled P-States 를 모두 활성화하여 Pod 전원 관리에 사용할 수 있습니다.
19.7.2. vDU 애플리케이션을 실행하기 위한 권장 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
가상화된 DCN(Distributed Unit) 애플리케이션을 실행하는 클러스터에는 고도로 조정되고 최적화된 구성이 필요합니다. 다음 정보는 OpenShift Container Platform 4.12 클러스터에서 vDU 워크로드를 지원하는 데 필요한 다양한 요소를 설명합니다.
19.7.2.1. 권장되는 클러스터 MachineConfig CR 링크 복사링크가 클립보드에 복사되었습니다!
ztp-site-generate 컨테이너에서 추출한 MachineConfig 사용자 정의 리소스(CR)가 클러스터에 적용되었는지 확인합니다. CR은 추출된 out/source-crs/extra-manifest/ 폴더에 있습니다.
ztp-site-generate 컨테이너의 다음 MachineConfig CR은 클러스터 호스트를 구성합니다.
| CR filename | 설명 |
|---|---|
|
|
클러스터의 워크로드 파티셔닝을 구성합니다. 클러스터를 설치할 때 이 |
|
|
SCTP 커널 모듈을 로드합니다. 이러한 |
|
| 컨테이너 마운트 네임스페이스 및 Kubelet 구성을 구성합니다. |
|
| 클러스터의 빠른 시작을 구성합니다. |
|
|
클러스터에 대한 |
19.7.2.2. 권장되는 클러스터 Operator 링크 복사링크가 클립보드에 복사되었습니다!
다음 Operator는 가상화된 분산 장치(vDU) 애플리케이션을 실행하는 클러스터에 필요하며 기준 참조 구성의 일부입니다.
- Node Tuning Operator(NTO). NTO 패키지 기능은 이제 NTO의 일부인 Performance Addon Operator와 함께 제공되었습니다.
- PTP Operator
- SR-IOV 네트워크 Operator
- Red Hat OpenShift Logging Operator
- Local Storage Operator
19.7.2.3. 권장되는 클러스터 커널 구성 링크 복사링크가 클립보드에 복사되었습니다!
클러스터에서 항상 지원되는 최신 실시간 커널 버전을 사용하십시오. 클러스터에서 다음 구성을 적용해야 합니다.
클러스터 성능 프로필에 다음
additionalKernelArgs가 설정되어 있는지 확인합니다.spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime"
spec: additionalKernelArgs: - "rcupdate.rcu_normal_after_boot=0" - "efi=runtime"Copy to Clipboard Copied! Toggle word wrap Toggle overflow TunedCR의performance-patch프로필이 관련PerformanceProfileCR에서 설정된 분리된 CPU와 일치하는 올바른 CPU격리세트를 구성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 나열된 CPU는 호스트 하드웨어 구성, 특히 시스템 및 CPU 토폴로지에서 사용 가능한 CPU 수에 따라 다릅니다.
19.7.2.4. 실시간 커널 버전 확인 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 클러스터에서 항상 최신 버전의 realtime 커널을 사용하십시오. 클러스터에서 사용 중인 커널 버전에 대해 확실하지 않은 경우 현재 실시간 커널 버전을 릴리스 버전과 다음 절차와 비교할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인되어 있습니다. -
podman이 설치되어 있어야 합니다.
절차
다음 명령을 실행하여 클러스터 버전을 가져옵니다.
OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')$ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')Copy to Clipboard Copied! Toggle word wrap Toggle overflow 릴리스 이미지 SHA 번호를 가져옵니다.
DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)
$ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 릴리스 이미지 컨테이너를 실행하고 클러스터의 현재 릴리스와 함께 패키지로 제공되는 커널 버전을 추출합니다.
podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'
$ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
4.18.0-305.49.1.rt7.121.el8_4.x86_64
4.18.0-305.49.1.rt7.121.el8_4.x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow 이는 릴리스와 함께 제공되는 기본 실시간 커널 버전입니다.
참고realtime 커널은 커널 버전의
.rt문자열로 표시됩니다.
검증
클러스터의 현재 릴리스에 대해 나열된 커널 버전이 클러스터에서 실행 중인 실제 실시간 커널과 일치하는지 확인합니다. 다음 명령을 실행하여 실행 중인 실시간 커널 버전을 확인합니다.
클러스터 노드에 대한 원격 쉘 연결을 엽니다.
oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 실시간 커널 버전을 확인합니다.
uname -r
sh-4.4# uname -rCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
4.18.0-305.49.1.rt7.121.el8_4.x86_64
4.18.0-305.49.1.rt7.121.el8_4.x86_64Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.7.3. 권장 클러스터 구성 적용 링크 복사링크가 클립보드에 복사되었습니다!
클러스터가 올바른 구성을 실행 중인지 확인할 수 있습니다. 다음 절차에서는 OpenShift Container Platform 4.12 클러스터에서 DU 애플리케이션을 배포하는 데 필요한 다양한 구성을 확인하는 방법을 설명합니다.
사전 요구 사항
- 클러스터를 배포하고 vDU 워크로드에 맞게 조정했습니다.
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다.
절차
기본 OperatorHub 소스가 비활성화되어 있는지 확인합니다. 다음 명령을 실행합니다.
oc get operatorhub cluster -o yaml
$ oc get operatorhub cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
spec: disableAllDefaultSources: truespec: disableAllDefaultSources: trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 워크로드 분할(
PreferredDuringScheduling)에 필요한 모든CatalogSource리소스에 주석이 추가되었는지 확인합니다.oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'$ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
certified-operators -- {"effect": "PreferredDuringScheduling"} community-operators -- {"effect": "PreferredDuringScheduling"} ran-operators redhat-marketplace -- {"effect": "PreferredDuringScheduling"} redhat-operators -- {"effect": "PreferredDuringScheduling"}certified-operators -- {"effect": "PreferredDuringScheduling"} community-operators -- {"effect": "PreferredDuringScheduling"} ran-operators1 redhat-marketplace -- {"effect": "PreferredDuringScheduling"} redhat-operators -- {"effect": "PreferredDuringScheduling"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 주석이 없는
CatalogSource리소스도 반환됩니다. 이 예에서는ran-operatorsCatalogSource리소스에 주석이 추가되지 않으며PreferredDuringScheduling주석이 없습니다.
참고올바르게 구성된 vDU 클러스터에는 주석이 있는 단일 카탈로그 소스만 나열됩니다.
적용 가능한 모든 OpenShift Container Platform Operator 네임 스페이스가 워크로드 파티셔닝을 위해 주석이 추가되었는지 확인합니다. 여기에는 핵심 OpenShift Container Platform과 참조 DU 튜닝 구성에 포함된 추가 Operator 세트를 사용하여 설치된 모든 Operator가 포함됩니다. 다음 명령을 실행합니다.
oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'$ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
default -- openshift-apiserver -- management openshift-apiserver-operator -- management openshift-authentication -- management openshift-authentication-operator -- management
default -- openshift-apiserver -- management openshift-apiserver-operator -- management openshift-authentication -- management openshift-authentication-operator -- managementCopy to Clipboard Copied! Toggle word wrap Toggle overflow 중요워크로드 파티셔닝을 위해 추가 Operator에 주석을 달 수 없습니다. 이전 명령의 출력에서
--separator의 오른쪽에 있는 값 없이 추가 Operator를 나열해야 합니다.ClusterLogging구성이 올바른지 확인합니다. 다음 명령을 실행합니다.적절한 입력 및 출력 로그가 구성되어 있는지 확인합니다.
oc get -n openshift-logging ClusterLogForwarder instance -o yaml
$ oc get -n openshift-logging ClusterLogForwarder instance -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 큐레이션 일정이 애플리케이션에 적합한지 확인합니다.
oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml
$ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 웹 콘솔이 비활성화(
managementState: Removed)인지 확인합니다.oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"$ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Removed
RemovedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 클러스터 노드에서
chronyd가 비활성화되어 있는지 확인합니다.oc debug node/<node_name>
$ oc debug node/<node_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 노드에서
chronyd의 상태를 확인합니다.chroot /host
sh-4.4# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow systemctl status chronyd
sh-4.4# systemctl status chronydCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)● chronyd.service - NTP client/server Loaded: loaded (/usr/lib/systemd/system/chronyd.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:chronyd(8) man:chrony.conf(5)Copy to Clipboard Copied! Toggle word wrap Toggle overflow PTP 인터페이스가
linuxptp-daemon컨테이너 및 PTP 관리 클라이언트(pmc) 도구에 원격 쉘 연결을 사용하여 기본 시계와 성공적으로 동기화되었는지 확인합니다.다음 명령을 실행하여
linuxptp-daemonPod의 이름으로$PTP_POD_NAME변수를 설정합니다.PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)
$ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 PTP 장치의 동기화 상태를 확인합니다.
oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET PORT_DATA_SET'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음
pmc명령을 실행하여 PTP 클럭 상태를 확인합니다.oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'$ oc -n openshift-ptp rsh -c linuxptp-daemon-container ${PTP_POD_NAME} pmc -u -f /var/run/ptp4l.0.config -b 0 'GET TIME_STATUS_NP'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow /var/run/ptp4l.0.config의 값에 해당하는 예상마스터 오프셋값이linuxptp-daemon-container로그에 있는지 확인합니다.oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container
$ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-containerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset -1731092 s2 freq -1546242 delay 497 ptp4l[56020.390]: [ptp4l.1.config] master offset -2 s2 freq -5863 path delay 541 ptp4l[56020.390]: [ptp4l.0.config] master offset -8 s2 freq -10699 path delay 533
phc2sys[56020.341]: [ptp4l.1.config] CLOCK_REALTIME phc offset -1731092 s2 freq -1546242 delay 497 ptp4l[56020.390]: [ptp4l.1.config] master offset -2 s2 freq -5863 path delay 541 ptp4l[56020.390]: [ptp4l.0.config] master offset -8 s2 freq -10699 path delay 533Copy to Clipboard Copied! Toggle word wrap Toggle overflow
다음 명령을 실행하여 SR-IOV 구성이 올바른지 확인합니다.
SriovOperatorConfig리소스의disableDrain값이true로 설정되어 있는지 확인합니다.oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"$ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
true
trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SriovNetworkNodeState동기화 상태가Succeeded상태인지 확인합니다.oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Succeeded
SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV용으로 구성된 각 인터페이스에서
Vfs(가상 기능)의 예상 수 및 구성이 있는지 확인하고.status.interfaces필드에 올바른지 확인합니다. 예를 들면 다음과 같습니다.oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml
$ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터 성능 프로필이 올바른지 확인합니다.
cpu및hugepages섹션은 하드웨어 구성에 따라 다릅니다. 다음 명령을 실행합니다.oc get PerformanceProfile openshift-node-performance-profile -o yaml
$ oc get PerformanceProfile openshift-node-performance-profile -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고CPU 설정은 서버에서 사용 가능한 코어 수에 따라 다르며 워크로드 파티션 설정에 맞게 조정해야 합니다.
hugepages구성은 서버 및 애플리케이션에 따라 다릅니다.다음 명령을 실행하여
PerformanceProfile이 클러스터에 적용되었는지 확인합니다.oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"$ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Available -- True Upgradeable -- True Progressing -- False Degraded -- False
Available -- True Upgradeable -- True Progressing -- False Degraded -- FalseCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
Tuned성능 패치 설정을 확인합니다.oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml
$ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cmdline=nohz_full=의 cpu 목록은 하드웨어 구성에 따라 달라집니다.
다음 명령을 실행하여 클러스터 네트워킹 진단이 비활성화되어 있는지 확인합니다.
oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'$ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
true
trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kubelet하우스키핑 간격이 느린 속도로 조정되었는지 확인합니다. 이는containerMountNS머신 구성에 설정되어 있습니다. 다음 명령을 실행합니다.oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION
$ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATIONCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Grafana 및
alertManagerMain이 비활성화되어 있으며 Prometheus 보존 기간이 24h로 설정되어 있는지 확인합니다.oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"$ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 사용하여 Grafana 및
alertManagerMain경로가 클러스터에 없는 것을 확인합니다.oc get route -n openshift-monitoring alertmanager-main
$ oc get route -n openshift-monitoring alertmanager-mainCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get route -n openshift-monitoring grafana
$ oc get route -n openshift-monitoring grafanaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 두 쿼리 모두
서버(NotFound) 메시지에서 Error를 반환해야 합니다.
다음 명령을 실행하여
PerformanceProfile,Tunedperformance-patch, workload partitioning 및 kernel 명령줄 인수 각각에 대해예약된최소 4개의 CPU가 있는지 확인합니다.oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"$ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
0-3
0-3Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고워크로드 요구 사항에 따라 예약된 CPU를 추가로 할당해야 할 수 있습니다.
19.8. siteConfig 리소스를 사용한 고급 관리형 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
site Config CR(사용자 정의 리소스)을 사용하여 설치 시 관리 클러스터에 사용자 정의 기능 및 구성을 배포할 수 있습니다.
19.8.1. ZTP GitOps 파이프라인에서 추가 설치 매니페스트 사용자 정의 링크 복사링크가 클립보드에 복사되었습니다!
제로 건스 프로비저닝(ZTP) GitOps 파이프라인의 설치 단계에 포함하기 위해 추가 매니페스트 세트를 정의할 수 있습니다. 이러한 매니페스트는 SiteConfig CR(사용자 정의 리소스)에 연결되며 설치 중에 클러스터에 적용됩니다. 설치 시 MachineConfig CR을 포함하면 설치 프로세스를 보다 효율적으로 수행할 수 있습니다.
사전 요구 사항
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
절차
- ZTP 파이프라인에서 클러스터 설치를 사용자 지정하는 데 사용하는 추가 매니페스트 CR 세트를 생성합니다.
사용자 정의
/siteconfig디렉터리에서 추가 매니페스트를 위한/extra-manifest폴더를 생성합니다. 다음 예제에서는/extra-manifest폴더가 포함된 샘플/siteconfig를 보여줍니다.siteconfig ├── site1-sno-du.yaml ├── site2-standard-du.yaml └── extra-manifest └── 01-example-machine-config.yamlsiteconfig ├── site1-sno-du.yaml ├── site2-standard-du.yaml └── extra-manifest └── 01-example-machine-config.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
사용자 지정 추가 매니페스트 CR을
siteconfig/extra-manifest디렉터리에 추가합니다. SiteConfigCR에서extraManifestPath필드에 디렉터리 이름을 입력합니다. 예를 들면 다음과 같습니다.clusters: - clusterName: "example-sno" networkType: "OVNKubernetes" extraManifestPath: extra-manifest
clusters: - clusterName: "example-sno" networkType: "OVNKubernetes" extraManifestPath: extra-manifestCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
SiteConfigCR 및/extra-manifestCR을 저장하고 사이트 구성 리포지토리로 내보냅니다.
ZTP 파이프라인은 /extra-manifest 디렉터리의 CR을 클러스터 프로비저닝 중에 기본 추가 매니페스트 세트에 추가합니다.
19.8.2. SiteConfig 필터를 사용하여 사용자 정의 리소스 필터링 링크 복사링크가 클립보드에 복사되었습니다!
필터를 사용하면ZTP(zero touch provisioning) GitOps 파이프라인의 설치 단계에서 사용할 다른 CR을 포함하거나 제외하도록 SiteConfig CR(CR)을 쉽게 사용자 지정할 수 있습니다.
포함되거나 제외 하려는 특정 extraManifest RAN CR 목록과 함께 SiteConfig CR에 대해 include 또는 exclude에 대해 inclusionDefault 값을 지정할 수 있습니다. include 로 inclusionDefault 를 설정하면 ZTP 파이프라인이 설치 중에 /source-crs/extra-manifest 에 있는 모든 파일을 적용합니다. exclude 로 inclusionDefault 를 설정하면 그 반대입니다.
기본적으로 포함된 /source-crs/extra-manifest 폴더에서 개별 CR을 제외할 수 있습니다. 다음 예제에서는 설치 시 /source-crs/extra-manifest/03-sctp-machine-config-worker.yaml CR을 제외하도록 사용자 지정 단일 노드 OpenShift SiteConfig CR을 구성합니다.
몇 가지 추가 선택적 필터링 시나리오도 설명되어 있습니다.
사전 요구 사항
- 필요한 설치 및 정책 CR을 생성하기 위해 hub 클러스터를 구성하셨습니다.
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
절차
ZTP 파이프라인이
03-sctp-machine-config-worker.yamlCR 파일을 적용하지 않으려면SiteConfigCR에 다음 YAML을 적용합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow ZTP 파이프라인은 설치 중에
03-sctp-machine-config-worker.yamlCR을 건너뜁니다./source-crs/extra-manifest의 다른 모든 CR이 적용됩니다.SiteConfigCR을 저장하고 변경 사항을 사이트 구성 리포지토리로 내보냅니다.ZTP 파이프라인은
SiteConfig필터 지침에 따라 적용되는 CR을 모니터링하고 조정합니다.선택 사항: ZTP 파이프라인이 클러스터 설치 중에 모든
/source-crs/extra-manifestCR을 적용하지 않도록 하려면SiteConfigCR에 다음 YAML을 적용합니다.- clusterName: "site1-sno-du" extraManifests: filter: inclusionDefault: exclude- clusterName: "site1-sno-du" extraManifests: filter: inclusionDefault: excludeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 선택 사항: 모든
/source-crs/extra-manifestRAN CR을 제외하고 설치 중에 사용자 정의 CR 파일을 포함하려면 사용자 정의 매니페스트 폴더 및포함파일을 설정합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제에서는 사용자 지정 폴더 구조를 보여줍니다.
siteconfig ├── site1-sno-du.yaml └── user-custom-manifest └── custom-sctp-machine-config-worker.yamlsiteconfig ├── site1-sno-du.yaml └── user-custom-manifest └── custom-sctp-machine-config-worker.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9. PolicyGenTemplate 리소스를 사용한 고급 관리형 클러스터 구성 링크 복사링크가 클립보드에 복사되었습니다!
PolicyGenTemplate CR을 사용하여 관리 클러스터에 사용자 정의 기능을 배포할 수 있습니다.
19.9.1. 클러스터에 추가 변경 사항 배포 링크 복사링크가 클립보드에 복사되었습니다!
기본 GitOps ZTP 파이프라인 구성 외부에서 클러스터 구성을 변경해야 하는 경우 다음 세 가지 옵션이 있습니다.
- ZTP 파이프라인이 완료된 후 추가 설정 적용
- GitOps ZTP 파이프라인 배포가 완료되면 배포된 클러스터는 애플리케이션 워크로드에 사용할 수 있습니다. 이 시점에서 추가 Operator를 설치하고 요구 사항에 맞는 구성을 적용할 수 있습니다. 추가 구성이 플랫폼 성능 또는 할당된 CPU 예산에 부정적인 영향을 미치지 않도록 합니다.
- ZTP 라이브러리에 콘텐츠 추가
- GitOps ZTP 파이프라인을 사용하여 배포하는 기본 소스 CR(사용자 정의 리소스)은 필요에 따라 사용자 정의 콘텐츠로 보강될 수 있습니다.
- 클러스터 설치에 대한 추가 매니페스트 생성
- 추가 매니페스트는 설치 중에 적용되며 설치 프로세스를 보다 효율적으로 수행할 수 있습니다.
추가 소스 CR을 제공하거나 기존 소스 CR을 수정하면 OpenShift Container Platform의 성능 또는 CPU 프로파일에 심각한 영향을 미칠 수 있습니다.
19.9.2. PolicyGenTemplate CR을 사용하여 소스 CR 콘텐츠 재정의 링크 복사링크가 클립보드에 복사되었습니다!
PolicyGenTemplate 사용자 정의 리소스(CR)를 사용하면 ztp-site-generate 컨테이너에서 GitOps 플러그인과 함께 제공되는 기본 소스 CR 상단에 추가 구성 세부 정보를 오버레이할 수 있습니다. PolicyGenTemplate CR을 기본 CR에 대한 논리 병합 또는 패치로 간주할 수 있습니다. PolicyGenTemplate CR을 사용하여 기본 CR의 단일 필드를 업데이트하거나 기본 CR의 전체 콘텐츠를 오버레이합니다. 기본 CR에 없는 값 및 삽입 필드를 업데이트할 수 있습니다.
다음 예제 절차에서는 group-du-sno-ranGen.yaml 파일의 PolicyGenTemplate CR을 기반으로 참조 구성에 대해 생성된 PerformanceProfile CR의 필드를 업데이트하는 방법을 설명합니다. 이 절차는 요구 사항에 따라 PolicyGenTemplate 의 다른 부분을 수정하기 위한 기초로 사용하십시오.
사전 요구 사항
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD의 소스 리포지토리로 정의해야 합니다.
절차
기존 콘텐츠의 기준 소스 CR을 검토합니다. 제로 대화 프로비저닝 (ZTP) 컨테이너에서 추출하여 참조
PolicyGenTemplateCR에 나열된 소스 CR을 검토할 수 있습니다./out폴더를 생성합니다.mkdir -p ./out
$ mkdir -p ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow 소스 CR을 추출합니다.
podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 extract /home/ztp --tar | tar x -C ./out
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 extract /home/ztp --tar | tar x -C ./outCopy to Clipboard Copied! Toggle word wrap Toggle overflow
./out/source-crs/에서 기준 PerformanceProfile CR을 검토합니다.PerformanceProfile.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고$…가 포함된 소스 CR의 필드는PolicyGenTemplateCR에 제공되지 않는 경우 생성된 CR에서 제거됩니다.group-du-sno-ranGen.yaml참조 파일에서PerformanceProfile의PolicyGenTemplate항목을 업데이트합니다. 다음 예제PolicyGenTemplateCR 스탠자는 적절한 CPU 사양을 제공하고,hugepages구성을 설정하고,globallyDisableIrqLoadBalancing을 false로 설정하는 새 필드를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git에서
PolicyGenTemplate변경 사항을 커밋한 다음 GitOps ZTP argo CD 애플리케이션에서 모니터링 중인 Git 리포지토리로 내보냅니다.
출력 예
ZTP 애플리케이션은 생성된 PerformanceProfile CR을 포함하는 RHACM 정책을 생성합니다. PolicyGenTemplate 의 PerformanceProfile 항목의 metadata 및 spec 콘텐츠를 소스 CR에 병합하여 해당 CR의 콘텐츠를 파생시킵니다. 결과 CR에는 다음 내용이 있습니다.
ztp-site-generate 컨테이너에서 추출한 /source-crs 폴더의 경우 구문에 따라 템플릿 대체에 $ 구문이 사용되지 않습니다. 대신 policyGen 툴이 문자열에 대한 $ 접두사를 확인하고 관련 PolicyGenTemplate CR에서 해당 필드에 대한 값을 지정하지 않으면 해당 필드가 출력 CR에서 완전히 생략됩니다.
이 예외는 PolicyGenTemplate CR에서 mcp 에 지정된 값으로 대체되는 /source-crs YAML 파일의 $mcp 변수입니다. 예를 들어 example/policygentemplates/group-du-standard-ranGen.yaml 에서 mcp 는 worker 입니다.
spec:
bindingRules:
group-du-standard: ""
mcp: "worker"
spec:
bindingRules:
group-du-standard: ""
mcp: "worker"
policyGen 툴은 출력 CR에서 $mcp 의 인스턴스를 worker 로 바꿉니다.
19.9.3. GitOps ZTP 파이프라인에 사용자 정의 콘텐츠 추가 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 ZTP 파이프라인에 새 콘텐츠를 추가합니다.
절차
-
PolicyGenTemplateCR(사용자 정의 리소스)에 대한kustomization.yaml파일이 포함된 디렉터리에source-crs라는 하위 디렉터리를 생성합니다. 다음 예와 같이
source-crs하위 디렉터리에 사용자 지정 CR을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
source-crs하위 디렉터리는kustomization.yaml파일과 동일한 디렉터리에 있어야 합니다.
중요자체 리소스를 사용하려면 사용자 정의 CR 이름이 ZTP 컨테이너에 제공된 기본 소스 CR과 다른지 확인합니다.
source-crs/custom-crs및source-crs/elasticsearch디렉터리에 추가한 콘텐츠에 대한 참조를 포함하도록 필요한PolicyGenTemplateCR을 업데이트합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git에서
PolicyGenTemplate변경 사항을 커밋한 다음 GitOps ZTP Argo CD 정책 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다. 변경된
PolicyGenTemplate을 포함하도록ClusterGroupUpgradeCR을 업데이트하고cgu-test.yaml로 저장합니다. 다음 예제는 생성된cgu-test.yaml파일을 보여줍니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 업데이트된
ClusterGroupUpgradeCR을 적용합니다.oc apply -f cgu-test.yaml
$ oc apply -f cgu-test.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 업데이트가 성공했는지 확인합니다.
oc get cgu -A
$ oc get cgu -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policies
NAMESPACE NAME AGE STATE DETAILS ztp-clusters custom-source-cr 6s InProgress Remediating non-compliant policies ztp-install cluster1 19h Completed All clusters are compliant with all the managed policiesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9.4. PolicyGenTemplate CR에 대한 정책 준수 평가 타임아웃 구성 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터가 적용된 정책을 준수하는지 여부를 모니터링 및 보고하려면 hub 클러스터에 설치된 RHACM(Red Hat Advanced Cluster Management)을 사용합니다. RHACM은 정책 템플릿을 사용하여 사전 정의된 정책 컨트롤러 및 정책을 적용합니다. 정책 컨트롤러는 Kubernetes CRD(사용자 정의 리소스 정의) 인스턴스입니다.
기본 정책 평가 간격은 PolicyGenTemplate CR(사용자 정의 리소스)으로 덮어쓸 수 있습니다. RHACM이 적용된 클러스터 정책을 다시 평가하기 전에 ConfigurationPolicy CR의 상태가 정책 준수 또는 비준수 상태에 있는 기간을 정의하는 기간 설정을 구성합니다.
zero touch provisioning (ZTP) 정책 생성기는 사전 정의된 정책 평가 간격을 사용하여 ConfigurationPolicy CR 정책을 생성합니다. 비호환 상태의 기본값은 10초입니다. 준수 상태의 기본값은 10분입니다. 평가 간격을 비활성화하려면 값을 never 로 설정합니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.
절차
PolicyGenTemplateCR에서 모든 정책에 대한 평가 간격을 구성하려면spec필드에evaluationInterval을 추가한 다음 적절한준수및비준수값을 설정합니다. 예를 들면 다음과 같습니다.spec: evaluationInterval: compliant: 30m noncompliant: 20sspec: evaluationInterval: compliant: 30m noncompliant: 20sCopy to Clipboard Copied! Toggle word wrap Toggle overflow PolicyGenTemplateCR에서spec.sourceFiles오브젝트에 대한 평가 간격을 구성하려면evaluationInterval을sourceFiles필드에 추가합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
Git 리포지토리에서
PolicyGenTemplateCR 파일을 커밋하고 변경 사항을 내보냅니다.
검증
관리형 스포크 클러스터 정책이 예상 간격으로 모니터링되는지 확인합니다.
-
관리형 클러스터에서
cluster-admin권한이 있는 사용자로 로그인합니다. open-cluster-management-agent-addon네임스페이스에서 실행 중인 pod를 가져옵니다. 다음 명령을 실행합니다.oc get pods -n open-cluster-management-agent-addon
$ oc get pods -n open-cluster-management-agent-addonCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10d
NAME READY STATUS RESTARTS AGE config-policy-controller-858b894c68-v4xdb 1/1 Running 22 (5d8h ago) 10dCopy to Clipboard Copied! Toggle word wrap Toggle overflow config-policy-controllerPod에 대한 로그의 예상 간격으로 적용된 정책이 평가되고 있는지 확인합니다.oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb
$ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdbCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-config-policy-config"} 2022-05-10T15:10:25.280Z info configuration-policy-controller controllers/configurationpolicy_controller.go:166 Skipping the policy evaluation due to the policy not reaching the evaluation interval {"policy": "compute-1-common-compute-1-catalog-policy-config"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9.5. 검증기를 사용하여 ZTP 클러스터 배포가 완료되었음을 알릴 수 있습니다. 링크 복사링크가 클립보드에 복사되었습니다!
유효성 검사기를 생성하면 배포된 클러스터의 설치 및 구성이 완료될 때 null touch 프로비저닝(ZTP)이 완료되면 신호를 알리는 정책을 알릴 수 있습니다. 이 정책은 단일 노드 OpenShift 클러스터, 3 노드 클러스터 및 표준 클러스터의 배포에 사용할 수 있습니다.
절차
소스 파일
validatorCRs/informDuValidator.yaml을 포함하는 독립 실행형PolicyGenTemplate사용자 정의 리소스(CR)를 생성합니다. 각 클러스터 유형에 대해 하나의 독립 실행형PolicyGenTemplateCR만 있으면 됩니다. 예를 들어, 이 CR은 단일 노드 OpenShift 클러스터에 대한 검증기를 적용합니다.예제 single-node 클러스터 검증기에서는 정책 CR을 알립니다 (group-du-sno-validator-ranGen.yaml).
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PolicyGenTemplates개체의 이름입니다. 이 이름은 요청된네임스페이스에서생성된placementBinding,placementRule및정책의 일부로 사용됩니다.- 2
- 이 값은
PolicyGenTemplates그룹에 사용된네임스페이스와 일치해야 합니다. - 3
bindingRules에 정의된group-du-*레이블은SiteConfig파일에 있어야 합니다.- 4
bindingExcludedRules에 정의된 레이블은 'ztp-done:'이어야 합니다.ztp-done레이블은 토폴로지 Aware Lifecycle Manager와 조정하는 데 사용됩니다.- 5
MCP는 소스 파일validatorCRs/informDuValidator.yaml에 사용되는MachineConfigPool오브젝트를 정의합니다. 단일 노드 및 표준 클러스터 배포의 경우 3노드 클러스터 배포 및작업자의마스터여야 합니다.- 6
- 선택 사항: 기본값은
inform입니다. - 7
- 이 값은 생성된 RHACM 정책의 이름으로 사용됩니다. 단일 노드 예제에 대해 생성된 검증기 정책은
group-du-sno-validator-du-policy입니다.
-
Git 리포지토리에서
PolicyGenTemplateCR 파일을 커밋하고 변경 사항을 내보냅니다.
19.9.6. PolicyGenTemplate CR을 사용하여 PTP 이벤트 구성 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP 파이프라인을 사용하여 HTTP 또는 AMQP 전송을 사용하는 PTP 이벤트를 구성할 수 있습니다.
HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS(Extended Life Cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.
19.9.6.1. HTTP 전송을 사용하는 PTP 이벤트 구성 링크 복사링크가 클립보드에 복사되었습니다!
ZTP(ZTP) 파이프라인으로 배포하는 관리형 클러스터에서 HTTP 전송을 사용하는 PTP 이벤트를 구성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.
절차
요구 사항에 따라
group-du-3node-ranGen.yaml,group-du-sno-ranGen.yaml또는group-du-standard-ranGen.yaml파일에 다음PolicyGen 변경 사항을 적용합니다..sourceFiles에서 전송 호스트를 구성하는PtpOperatorConfigCR 파일을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고OpenShift Container Platform 4.12 이상에서는 PTP 이벤트와 함께 HTTP 전송을 사용할 때
PtpOperatorConfig리소스에서transportHost필드를 설정할 필요가 없습니다.PTP 클럭 유형 및 인터페이스에
linuxptp및phc2sys를 구성합니다. 예를 들어.sourceFiles에 다음 스탠자를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 요구 사항에 따라
PtpConfigMaster.yaml,PtpConfigSlave.yaml또는PtpConfigSlaveCvl.yaml중 하나일 수 있습니다.PtpConfigSlaveCvl.yaml은 Intel E810 Columbiaville NIC에 대해linuxptp서비스를 구성합니다.group-du-sno-ranGen.yaml또는group-du-3node-ranGen.yaml을 기반으로 하는 구성의 경우PtpConfigSlave.yaml을 사용합니다. - 2
- 장치별 인터페이스 이름입니다.
- 3
- PTP 빠른 이벤트를 활성화하려면
.spec.sourceFiles.spec.profile의--summary_interval -4값을ptp4lOpts에 추가해야 합니다. - 4
- 필수
phc2sysOpts값.-m은stdout에 메시지를 출력합니다.linuxptp-daemonDaemonSet은 로그를 구문 분석하고 Prometheus 지표를 생성합니다. - 5
- 선택 사항:
ptpClockThreshold가 없으면 기본값이ptpClockThreshold필드에 사용됩니다. 스탠자는 기본ptpClockThreshold값을 표시합니다.ptpClockThreshold값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다.holdOverTimeout은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가FREERUN로 변경되기 전 시간(초)입니다.maxOffsetThreshold및minOffsetThreshold설정은CLOCK_REALTIME(phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다.ptp4l또는phc2sys오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가FREERUN로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가LOCKED로 설정됩니다.
- 다른 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
- 사이트 구성 리포지토리의 변경 사항을 내보내 GitOps ZTP를 사용하여 PTP 빠른 이벤트를 새 사이트에 배포합니다.
19.9.6.2. AMQP 전송을 사용하는 PTP 이벤트 구성 링크 복사링크가 클립보드에 복사되었습니다!
ZTP(ZTP) 파이프라인으로 배포하는 관리 클러스터에서 AMQP 전송을 사용하는 PTP 이벤트를 구성할 수 있습니다.
HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS(Extended Life Cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.
절차
common-ranGen.yaml파일의.spec.sourceFiles에 다음 YAML을 추가하여 AMQP Operator를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 요구 사항에 따라
group-du-3node-ranGen.yaml,group-du-sno-ranGen.yaml또는group-du-standard-ranGen.yaml파일에 다음PolicyGen 변경 사항을 적용합니다..sourceFiles.sourceFiles에서 AMQ 전송 호스트를config-policy로 구성하는PtpOperatorConfigCR 파일을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow PTP 클럭 유형 및 인터페이스에
linuxptp및phc2sys를 구성합니다. 예를 들어.sourceFiles에 다음 스탠자를 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 요구 사항에 따라
PtpConfigMaster.yaml,PtpConfigSlave.yaml또는PtpConfigSlaveCvl.yaml하나가 될 수 있습니다.PtpConfigSlaveCvl.yaml은 Intel E810 Columbiaville NIC에 대해linuxptp서비스를 구성합니다.group-du-sno-ranGen.yaml또는group-du-3node-ranGen.yaml을 기반으로 하는 구성의 경우PtpConfigSlave.yaml을 사용합니다. - 2
- 장치별 인터페이스 이름입니다.
- 3
- PTP 빠른 이벤트를 활성화하려면
.spec.sourceFiles.spec.profile의--summary_interval -4값을ptp4lOpts에 추가해야 합니다. - 4
- 필수
phc2sysOpts값.-m은stdout에 메시지를 출력합니다.linuxptp-daemonDaemonSet은 로그를 구문 분석하고 Prometheus 지표를 생성합니다. - 5
- 선택 사항:
ptpClockThreshold가 없으면 기본값이ptpClockThreshold필드에 사용됩니다. 스탠자는 기본ptpClockThreshold값을 표시합니다.ptpClockThreshold값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다.holdOverTimeout은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가FREERUN로 변경되기 전 시간(초)입니다.maxOffsetThreshold및minOffsetThreshold설정은CLOCK_REALTIME(phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다.ptp4l또는phc2sys오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가FREERUN로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가LOCKED로 설정됩니다.
특정 사이트 YAML 파일에 다음
PolicyGenTemplate변경 사항을 적용합니다(예:example-sno-site.yaml)..sourceFiles.sourceFiles에서 AMQ 라우터를config-policy에 구성하는InterconnectCR 파일을 추가합니다.- fileName: AmqInstance.yaml policyName: "config-policy"
- fileName: AmqInstance.yaml policyName: "config-policy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- 다른 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
- 사이트 구성 리포지토리의 변경 사항을 내보내 GitOps ZTP를 사용하여 PTP 빠른 이벤트를 새 사이트에 배포합니다.
19.9.7. PolicyGenTemplate CR을 사용하여 베어 메탈 이벤트 구성 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP 파이프라인을 사용하여 HTTP 또는 AMQP 전송을 사용하는 베어 메탈 이벤트를 구성할 수 있습니다.
HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS(Extended Life Cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.
19.9.7.1. HTTP 전송을 사용하는 베어 메탈 이벤트 구성 링크 복사링크가 클립보드에 복사되었습니다!
ZTP(ZTP) 파이프라인으로 배포하는 관리형 클러스터에서 HTTP 전송을 사용하는 베어 메탈 이벤트를 구성할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.
절차
common-ranGen.yaml파일의spec.sourceFiles에 다음 YAML을 추가하여 Bare Metal Event Relay Operator를 구성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 그룹 구성 파일의
spec.sourceFiles(예:group-du-sno-ranGen.yaml파일에서 spec.sourceFiles)에HardwareEventCR을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 각 BMC(Baseboard Management Controller)에는 단일
HardwareEventCR만 필요합니다.
참고OpenShift Container Platform 4.12 이상에서는 베어 메탈 이벤트와 함께 HTTP 전송을 사용할 때
HardwareEventCR(사용자 정의 리소스)에서transportHost필드를 설정할 필요가 없습니다.- 다른 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
- 변경 사항을 사이트 구성 리포지토리로 내보내 GitOps ZTP가 있는 새 사이트에 베어 메탈 이벤트를 배포합니다.
다음 명령을 실행하여 Redfish 보안을 생성합니다.
oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \ --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \ --from-literal=hostaddr="<bmc_host_ip_addr>"
$ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \ --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \ --from-literal=hostaddr="<bmc_host_ip_addr>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9.7.2. AMQP 전송을 사용하는 베어 메탈 이벤트 구성 링크 복사링크가 클립보드에 복사되었습니다!
ZTP(ZTP) 파이프라인으로 배포하는 관리 클러스터에서 AMQP 전송을 사용하는 베어 메탈 이벤트를 구성할 수 있습니다.
HTTP 전송은 PTP 및 베어 메탈 이벤트의 기본 전송입니다. 가능한 경우 PTP 및 베어 메탈 이벤트에 AMQP 대신 HTTP 전송을 사용합니다. AMQ Interconnect는 2024년 6월 30일부터 EOL입니다. AMQ Interconnect의 ELS(Extended Life Cycle Support)는 2029년 11월 29일에 종료됩니다. 자세한 내용은 Red Hat AMQ Interconnect 지원 상태를 참조하십시오.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.
절차
AMQ Interconnect Operator 및 Bare Metal Event Relay Operator를 구성하려면
common-ranGen.yaml파일의spec.sourceFiles에 다음 YAML을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 사이트 구성 파일의
.spec.sourceFiles에InterconnectCR을 추가합니다(예:example-sno-site.yaml파일).- fileName: AmqInstance.yaml policyName: "config-policy"
- fileName: AmqInstance.yaml policyName: "config-policy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 특정 그룹 구성 파일의
spec.sourceFiles(예:group-du-sno-ranGen.yaml파일에서 spec.sourceFiles)에HardwareEventCR을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
transportHostURL은 기존 AMQ Interconnect CR이름과네임스페이스로 구성됩니다. 예를 들어transportHost: "amqp://amq-router.amq-router.svc.cluster.local"에서 AMQ Interconnect이름은둘 다amq-router로 설정됩니다.
참고각 BMC(Baseboard Management Controller)에는 단일
HardwareEvent리소스만 필요합니다.-
Git에서
PolicyGenTemplate변경 사항을 커밋한 다음 사이트 구성 리포지토리로 변경 사항을 내보내 GitOps ZTP를 사용하여 베어 메탈 이벤트 모니터링을 새 사이트에 배포합니다. 다음 명령을 실행하여 Redfish 보안을 생성합니다.
oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \ --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \ --from-literal=hostaddr="<bmc_host_ip_addr>"
$ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \ --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \ --from-literal=hostaddr="<bmc_host_ip_addr>"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9.8. 이미지 로컬 캐싱을 위해 이미지 레지스트리 Operator 구성 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform은 로컬 레지스트리를 사용하여 이미지 캐싱을 관리합니다. 엣지 컴퓨팅 사용 사례에서 클러스터는 종종 중앙 집중식 이미지 레지스트리와 통신할 때 대역폭 제한의 영향을 받으며 이로 인해 이미지 다운로드 시간이 길어질 수 있습니다.
초기 배포 중에 긴 다운로드 시간은 피할 수 없습니다. 시간이 지남에 따라 CRI-O가 예기치 않은 종료의 경우 /var/lib/containers/storage 디렉터리를 해제할 위험이 있습니다. 긴 이미지 다운로드 시간을 해결하기 위해 GitOps ZTP를 사용하여 원격 관리 클러스터에 로컬 이미지 레지스트리를 생성할 수 있습니다. 이는 클러스터가 네트워크의 맨 에지에 배포되는 에지 컴퓨팅 시나리오에서 유용합니다.
GitOps ZTP를 사용하여 로컬 이미지 레지스트리를 설정하려면 먼저 원격 관리 클러스터를 설치하는 데 사용하는 site Config CR에 디스크 파티셔닝을 구성해야 합니다. 설치한 후 PolicyGenTemplate CR을 사용하여 로컬 이미지 레지스트리를 구성합니다. 그런 다음 ZTP 파이프라인에서 영구 볼륨(PV) 및 PVC(영구 볼륨 클레임) CR을 생성하고 imageregistry 구성을 패치합니다.
로컬 이미지 레지스트리는 사용자 애플리케이션 이미지에만 사용할 수 있으며 OpenShift Container Platform 또는 Operator Lifecycle Manager Operator 이미지에는 사용할 수 없습니다.
19.9.8.1. siteConfig를 사용하여 디스크 파티션 구성 링크 복사링크가 클립보드에 복사되었습니다!
SiteConfig CR 및 GitOps ZTP(ZTP)를 사용하여 관리 클러스터에 대한 디스크 파티션을 구성합니다. site Config CR의 디스크 파티션 세부 정보가 기본 디스크와 일치해야 합니다.
설치 시 이 절차를 완료해야 합니다.
사전 요구 사항
- Butane을 설치합니다.
절차
다음 예제 YAML 파일을 사용하여
storage.bu파일을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
storage.bu파일을 Ignition 파일로 변환합니다.butane storage.bu
$ butane storage.buCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# # Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - JSON Pretty Print 와 같은 도구를 사용하여 출력을 JSON 형식으로 변환합니다.
SiteConfigCR의.spec.clusters.nodes.ignitionConfigOverride필드에 출력을 복사합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고.spec.clusters.nodes.ignitionConfigOverride필드가 없는 경우 생성합니다.
검증
설치 중 또는 설치 후 hub 클러스터에서
BareMetalHost오브젝트가 다음 명령을 실행하여 주석을 표시하는지 확인합니다.oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]
$ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}""{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-id/wwn-0x6b07b250ebb9d0002a33509f24af1f62\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 설치 후 단일 노드 OpenShift 디스크 상태를 확인합니다.
다음 명령을 실행하여 단일 노드 OpenShift 노드에서 디버그 세션에 들어갑니다.
이 단계는
<node_name>-debug라는 디버그 Pod를 인스턴스화합니다.oc debug node/my-sno-node
$ oc debug node/my-sno-nodeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 디버그 쉘 내에서
/host를 root 디렉터리로 설정합니다.디버그 Pod는 Pod 내의
/host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를/host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.chroot /host
# chroot /hostCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 사용 가능한 모든 블록 장치에 대한 정보를 나열합니다.
lsblk
# lsblkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 파일 시스템 디스크 공간 사용량에 대한 정보를 표시합니다.
df -h
# df -hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9.8.2. PolicyGenTemplate CR을 사용하여 이미지 레지스트리 구성 링크 복사링크가 클립보드에 복사되었습니다!
PolicyGenTemplate (PGT) CR을 사용하여 이미지 레지스트리를 구성하고 imageregistry 구성을 패치하는 데 필요한 CR을 적용합니다.
사전 요구 사항
- 관리 클러스터에서 디스크 파티션을 구성했습니다.
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - GitOps ZeroECDHE Provisioning(ZTP)과 함께 사용할 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.
절차
적절한
PolicyGenTemplateCR에서 스토리지 클래스, 영구 볼륨 클레임, 영구 볼륨 및 이미지 레지스트리 구성을 구성합니다. 예를 들어 개별 사이트를 구성하려면 다음 YAML을example-sno-site.yaml파일에 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요- fileName: ImageRegistryConfig.yaml구성에complianceType: mustonlyhave를 설정하지 마십시오. 이로 인해 레지스트리 Pod 배포가 실패할 수 있습니다.-
Git에서
PolicyGenTemplate변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
검증
다음 단계를 사용하여 관리 클러스터의 로컬 이미지 레지스트리의 오류 문제를 해결합니다.
관리형 클러스터에 로그인하는 동안 레지스트리에 성공적으로 로그인했는지 확인합니다. 다음 명령을 실행합니다.
관리형 클러스터 이름을 내보냅니다.
cluster=<managed_cluster_name>
$ cluster=<managed_cluster_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리형 클러스터
kubeconfig세부 정보를 가져옵니다.oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster$ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow 클러스터
kubeconfig를 다운로드하여 내보냅니다.oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster$ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 관리 클러스터에서 이미지 레지스트리에 대한 액세스를 확인합니다. " registry 액세스"를 참조하십시오.
imageregistry.operator.openshift.io그룹의ConfigCRD에서 오류를 보고하지 않는지 확인합니다. 관리형 클러스터에 로그인하는 동안 다음 명령을 실행합니다.oc get image.config.openshift.io cluster -o yaml
$ oc get image.config.openshift.io cluster -o yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리형 클러스터의
PersistentVolumeClaim이 데이터로 채워졌는지 확인합니다. 관리형 클러스터에 로그인하는 동안 다음 명령을 실행합니다.oc get pv image-registry-sc
$ oc get pv image-registry-scCopy to Clipboard Copied! Toggle word wrap Toggle overflow registry*pod가 실행 중이며openshift-image-registry네임스페이스에 있는지 확인합니다.oc get pods -n openshift-image-registry | grep registry*
$ oc get pods -n openshift-image-registry | grep registry*Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8d
cluster-image-registry-operator-68f5c9c589-42cfg 1/1 Running 0 8d image-registry-5f8987879-6nx6h 1/1 Running 0 8dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 클러스터의 디스크 파티션이 올바른지 확인합니다.
관리형 클러스터에 대한 디버그 쉘을 엽니다.
oc debug node/sno-1.example.com
$ oc debug node/sno-1.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow lsblk를 실행하여 호스트 디스크 파티션을 확인합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/var/imageregistry는 디스크가 올바르게 분할되었음을 나타냅니다.
19.9.9. PolicyGenTemplate CR에서 hub 템플릿 사용 링크 복사링크가 클립보드에 복사되었습니다!
토폴로지 Aware Lifecycle Manager는 GitOps ZTP와 함께 사용되는 구성 정책에서 RHACM(Red Hat Advanced Cluster Management) 허브 클러스터 템플릿 기능을 지원합니다.
Hub-side 클러스터 템플릿을 사용하면 대상 클러스터에 동적으로 사용자 지정할 수 있는 구성 정책을 정의할 수 있습니다. 이렇게 하면 similiar 구성이 있지만 값이 다른 많은 클러스터에 대해 별도의 정책을 생성할 필요가 없습니다.
정책 템플릿은 정책이 정의된 네임스페이스와 동일한 네임스페이스로 제한됩니다. 즉, 정책이 생성된 동일한 네임스페이스에서 hub 템플릿에서 참조되는 오브젝트를 생성해야 합니다.
다음 지원되는 hub 템플릿 기능은 TALM과 함께 GitOps ZTP에서 사용할 수 있습니다.
fromConfigmap은 namedConfigMap리소스에 제공된 데이터 키의 값을 반환합니다.참고ConfigMapCR에 대한 1MiB 크기 제한이 있습니다.ConfigMapCR의 유효 크기는last-applied-configuration주석으로 추가로 제한됩니다.last-applied-configuration제한을 방지하려면 템플릿ConfigMap에 다음 주석을 추가합니다.argocd.argoproj.io/sync-options: Replace=true
argocd.argoproj.io/sync-options: Replace=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
base64enc는 입력 문자열의 base64 인코딩 값을 반환합니다. -
base64dec는 base64로 인코딩된 입력 문자열의 디코딩된 값을 반환합니다. -
indent공백이 추가된 입력 문자열을 반환합니다. -
autoindent는 상위 템플릿에 사용된 간격에 따라 indent 공백이 추가된 입력 문자열을 반환합니다. -
입력 값의 정수 값을 캐스팅하고 반환합니다.
https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6/html-single/governance/index#toInt-function -
toBool은 입력 문자열을 부울 값으로 변환하고 부울을 반환합니다.
GitOps ZTP와 함께 다양한 오픈 소스 커뮤니티 기능 도 사용할 수 있습니다.
19.9.9.1. hub 템플릿 예 링크 복사링크가 클립보드에 복사되었습니다!
다음 코드 예제는 유효한 hub 템플릿입니다. 이러한 각 템플릿은 기본 네임스페이스에 이름이 test-config 인 ConfigMap CR에서 값을 반환합니다.
common-key키를 사용하여 값을 반환합니다.{{hub fromConfigMap "default" "test-config" "common-key" hub}}{{hub fromConfigMap "default" "test-config" "common-key" hub}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow .ManagedClusterName필드 및 문자열-name을 사용하여 문자열을 반환합니다.{{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}{{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow .ManagedClusterName필드의 연결된 값 및 문자열-name에서 부울 값을 캐스팅하고 반환합니다.{{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}{{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow .ManagedClusterName필드의 연결된 값 및 문자열-name에서 정수 값을 캐스팅하고 반환합니다.{{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}{{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.9.9.2. hub 클러스터 템플릿을 사용하여 site PolicyGenTemplate CR에서 호스트 NIC 지정 링크 복사링크가 클립보드에 복사되었습니다!
단일 ConfigMap CR에서 호스트 NIC를 관리하고 hub 클러스터 템플릿을 사용하여 클러스터 호스트에 적용되는 생성된 정책의 사용자 정의 NIC 값을 채울 수 있습니다. PGT(Site PolicyGenTemplate ) CR에 hub 클러스터 템플릿을 사용하면 각 사이트에 대해 여러 개의 단일 사이트 PGT CR을 생성할 필요가 없습니다.
다음 예제에서는 단일 ConfigMap CR을 사용하여 클러스터 호스트 NIC를 관리하고 단일 PolicyGenTemplate 사이트 CR을 사용하여 클러스터에 정책으로 적용하는 방법을 보여줍니다.
fromConfigmap 함수를 사용하는 경우 printf 변수는 템플릿 리소스 데이터 키 필드에만 사용할 수 있습니다. name 및 namespace 필드와 함께 사용할 수 없습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 GitOps ZTP ArgoCD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
절차
호스트 그룹의 NIC를 설명하는
ConfigMap리소스를 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ConfigMap크기가 1MiB보다 큰 경우에만argocd.argoproj.io/sync-options주석이 필요합니다.
참고ConfigMap은 hub 템플릿 대체가 있는 정책과 동일한 네임스페이스에 있어야 합니다.-
Git에서
ConfigMapCR을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다. 템플릿을 사용하여
ConfigMap오브젝트에서 필요한 데이터를 가져오는 사이트 PGT CR을 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git에서 사이트
PolicyGenTemplateCR을 커밋하고 ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.참고참조된
ConfigMapCR에 대한 후속 변경 사항은 적용된 정책과 자동으로 동기화되지 않습니다. 새ConfigMap변경 사항을 수동으로 동기화하여 기존 PolicyGenTemplate CR을 업데이트해야 합니다. "Syncing new ConfigMap changes to existing PolicyGenTemplate CRs"를 참조하십시오.
19.9.9.3. hub 클러스터 템플릿을 사용하여 그룹 PolicyGenTemplate CR에서 VLAN ID 지정 링크 복사링크가 클립보드에 복사되었습니다!
단일 ConfigMap CR에서 관리 클러스터의 VLAN ID를 관리하고 hub 클러스터 템플릿을 사용하여 클러스터에 적용되는 생성된 정책의 VLAN ID를 채울 수 있습니다.
다음 예제에서는 단일 ConfigMap CR에서 VLAN ID를 관리하고 단일 PolicyGenTemplate 그룹 CR을 사용하여 개별 클러스터 정책에서 해당 ID를 적용하는 방법을 보여줍니다.
fromConfigmap 함수를 사용하는 경우 printf 변수는 템플릿 리소스 데이터 키 필드에만 사용할 수 있습니다. name 및 namespace 필드와 함께 사용할 수 없습니다.
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
절차
클러스터 호스트 그룹의 VLAN ID를 설명하는
ConfigMapCR을 생성합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ConfigMap크기가 1MiB보다 큰 경우에만argocd.argoproj.io/sync-options주석이 필요합니다.
참고ConfigMap은 hub 템플릿 대체가 있는 정책과 동일한 네임스페이스에 있어야 합니다.-
Git에서
ConfigMapCR을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다. hub 템플릿을 사용하여
ConfigMap오브젝트에서 필요한 VLAN ID를 가져오는 그룹 PGT CR을 생성합니다. 예를 들어 PGT CR 그룹에 다음 YAML 조각을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git에서
PolicyGenTemplateCR 그룹을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.참고참조된
ConfigMapCR에 대한 후속 변경 사항은 적용된 정책과 자동으로 동기화되지 않습니다. 새ConfigMap변경 사항을 수동으로 동기화하여 기존 PolicyGenTemplate CR을 업데이트해야 합니다. "Syncing new ConfigMap changes to existing PolicyGenTemplate CRs"를 참조하십시오.
19.9.9.4. 기존 PolicyGenTemplate CR에 새 ConfigMap 변경 사항 동기화 링크 복사링크가 클립보드에 복사되었습니다!
사전 요구 사항
-
OpenShift CLI(
oc)가 설치되어 있습니다. -
cluster-admin권한이 있는 사용자로 hub 클러스터에 로그인했습니다. -
hub 클러스터 템플릿을 사용하여
ConfigMapCR에서 정보를 가져오는PolicyGenTemplateCR을 생성했습니다.
절차
-
ConfigMapCR의 콘텐츠를 업데이트하고 hub 클러스터의 변경 사항을 적용합니다. 업데이트된
ConfigMapCR의 콘텐츠를 배포된 정책에 동기화하려면 다음 중 하나를 수행합니다.옵션 1: 기존 정책을 삭제합니다. ArgoCD는
PolicyGenTemplateCR을 사용하여 삭제된 정책을 즉시 다시 생성합니다. 예를 들어 다음 명령을 실행합니다.oc delete policy <policy_name> -n <policy_namespace>
$ oc delete policy <policy_name> -n <policy_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 옵션 2:
ConfigMap을 업데이트할 때마다 다른 값을 가진 정책에 특수 주석policy.open-cluster-management.io/trigger-update를 적용합니다. 예를 들면 다음과 같습니다.oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
$ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고변경 사항을 적용하려면 업데이트된 정책을 적용해야 합니다. 자세한 내용은 reprocessing 에 대한 특수 주석을 참조하십시오.
선택 사항: 정책이 있는 경우 정책이 포함된
ClusterGroupUpdateCR을 삭제합니다. 예를 들면 다음과 같습니다.oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
$ oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트된
ConfigMap변경과 함께 적용할 정책이 포함된 새ClusterGroupUpdateCR을 생성합니다. 예를 들어cgr-example.yaml파일에 다음 YAML을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트된 정책을 적용합니다.
oc apply -f cgr-example.yaml
$ oc apply -f cgr-example.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10. 토폴로지 Aware Lifecycle Manager로 관리형 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
Topology Aware Lifecycle Manager (TALM)를 사용하여 여러 클러스터의 소프트웨어 라이프사이클을 관리할 수 있습니다. TALM은 RHACM(Red Hat Advanced Cluster Management) 정책을 사용하여 대상 클러스터에서 변경 사항을 수행합니다.
19.10.1. 토폴로지 Aware Lifecycle Manager 구성 정보 링크 복사링크가 클립보드에 복사되었습니다!
TALM(토폴로지 라이프사이클 관리자)은 하나 이상의 OpenShift Container Platform 클러스터에 대한 RHACM(Red Hat Advanced Cluster Management) 정책 배포를 관리합니다. 대규모 클러스터 네트워크에서 TALM을 사용하면 제한된 배치에서 클러스터에 대한 정책을 단계적으로 롤아웃할 수 있습니다. 따라서 업데이트할 때 가능한 서비스 중단을 최소화하는 데 도움이 됩니다. TALM을 사용하면 다음 작업을 제어할 수 있습니다.
- 업데이트의 시간
- RHACM 관리 클러스터 수
- 정책을 적용할 관리 클러스터의 하위 집합입니다.
- 클러스터의 업데이트 순서
- 클러스터로 수정 정책 세트
- 클러스터로 수정 정책 순서
- 카나리아 클러스터 할당
단일 노드 OpenShift의 경우 토폴로지 Aware Lifecycle Manager(TALM)는 다음 기능을 제공합니다.
- 업그레이드하기 전에 배포 백업 생성
- 대역폭이 제한된 클러스터의 이미지 사전 캐싱
TALM은 y-streams 및 z-streams에서 OpenShift Container Platform y-stream 및 z-stream 업데이트의 오케스트레이션과 day-two 작업을 지원합니다.
19.10.2. 토폴로지 Aware Lifecycle Manager에서 사용되는 관리형 정책 정보 링크 복사링크가 클립보드에 복사되었습니다!
TALM(토폴로지 라이프사이클 관리자)은 클러스터 업데이트에 RHACM 정책을 사용합니다.
TALM을 사용하면 수정 필드가 알리 도록 설정된 모든 정책 CR의 롤아웃을 관리할 수 있습니다. 지원되는 사용 사례는 다음과 같습니다.
- 정책 CR 수동 사용자 생성
-
PolicyGenTemplateCRD(사용자 정의 리소스 정의)에서 자동으로 생성된 정책
수동 승인을 사용하여 Operator 서브스크립션을 업데이트하는 정책의 경우 TALM은 업데이트된 Operator 설치를 승인하는 추가 기능을 제공합니다.
관리 정책에 대한 자세한 내용은 RHACM 설명서의 정책 개요 를 참조하십시오.
PolicyGenTemplate CRD에 대한 자세한 내용은 "PolicyGenTemplate Resource를 사용하여 관리 클러스터 구성"의 "PolicyGenTemplate CRD 정보" 섹션을 참조하십시오.
19.10.3. 웹 콘솔을 사용하여 토폴로지 Aware Lifecycle Manager 설치 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 웹 콘솔을 사용하여 Topology Aware Lifecycle Manager를 설치할 수 있습니다.
사전 요구 사항
- 최신 버전의 RHACM Operator를 설치합니다.
- 연결이 끊긴 재gitry가 있는 허브 클러스터를 설정합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
- OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub로 이동합니다.
- 사용 가능한 Operator 목록에서 Topology Aware Lifecycle Manager 를 검색한 다음 설치를 클릭합니다.
- 기본 설치 모드 ["All namespaces on the cluster (default)"] 및 Installed Namespace ("openshift-operators")를 선택하여 Operator가 올바르게 설치되었는지 확인합니다.
- 설치를 클릭합니다.
검증
설치에 성공했는지 확인하려면 다음을 수행하십시오.
- Operator → 설치된 Operator 페이지로 이동합니다.
-
Operator가
All Namespaces네임스페이스에 설치되어 있고 해당 상태는Succeeded인지 확인합니다.
Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.
-
Operator → 설치된 Operator 페이지로 이동하여
Status열에 오류 또는 실패가 있는지 점검합니다. -
Workloads → Pod 페이지로 이동하여 문제를 보고하는
cluster-group-upgrades-controller-managerPod의 컨테이너에서 로그를 확인합니다.
19.10.4. CLI를 사용하여 Topology Aware Lifecycle Manager 설치 링크 복사링크가 클립보드에 복사되었습니다!
oc(OpenShift CLI)를 사용하여 TALM(토폴로지 라이프사이클 관리자)을 설치할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc)를 설치합니다. - 최신 버전의 RHACM Operator를 설치합니다.
- 연결이 끊긴 레지스트리가 있는 hub 클러스터를 설정합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
서브스크립션CR을 생성합니다.SubscriptionCR을 정의하고 YAML 파일을 저장합니다(예:talm-subscription.yaml).Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
SubscriptionCR을 생성합니다.oc create -f talm-subscription.yaml
$ oc create -f talm-subscription.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.
oc get csv -n openshift-operators
$ oc get csv -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME DISPLAY VERSION REPLACES PHASE topology-aware-lifecycle-manager.4.12.x Topology Aware Lifecycle Manager 4.12.x Succeeded
NAME DISPLAY VERSION REPLACES PHASE topology-aware-lifecycle-manager.4.12.x Topology Aware Lifecycle Manager 4.12.x SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow TALM이 실행 중인지 확인합니다.
oc get deploy -n openshift-operators
$ oc get deploy -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE openshift-operators cluster-group-upgrades-controller-manager 1/1 1 1 14s
NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE openshift-operators cluster-group-upgrades-controller-manager 1/1 1 1 14sCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.5. ClusterGroupUpgrade CR 정보 링크 복사링크가 클립보드에 복사되었습니다!
TALM(토폴로지 라이프사이클 관리자)은 클러스터 그룹의 ClusterGroupUpgrade CR에서 수정 계획을 빌드합니다. ClusterGroupUpgrade CR에서 다음 사양을 정의할 수 있습니다.
- 그룹의 클러스터
-
ClusterGroupUpgradeCR 차단 - 적용 가능한 관리 정책 목록
- 동시 업데이트 수
- 적용 가능한 카나리아 업데이트
- 업데이트 전과 후에 수행할 작업
- 업데이트 타이밍
ClusterGroupUpgrade CR의 enable 필드를 사용하여 업데이트 시작 시간을 제어할 수 있습니다. 예를 들어 예약된 유지 관리 기간이 4시간이면 enable 필드를 false 로 설정하여 ClusterGroupUpgrade CR을 준비할 수 있습니다.
spec.remediationStrategy.timeout 설정을 다음과 같이 구성하여 타임아웃을 설정할 수 있습니다.
spec
remediationStrategy:
maxConcurrency: 1
timeout: 240
spec
remediationStrategy:
maxConcurrency: 1
timeout: 240
batchTimeoutAction 을 사용하여 클러스터에 대한 업데이트가 실패하는 경우 발생하는 상황을 확인할 수 있습니다. 오류가 발생한 클러스터를 계속 건너뛰고 다른 클러스터를 계속 업그레이드하거나 모든 클러스터에 대한 정책 수정을 중지하도록 중단할 수 있습니다. 제한 시간이 경과하면 TALM은 클러스터에 대한 추가 업데이트가 발생하지 않도록 모든 적용 정책을 제거합니다.
변경 사항을 적용하려면 enabled 필드를 true 로 설정합니다.
자세한 내용은 "관리된 클러스터에 업데이트 정책 적용" 섹션을 참조하십시오.
TALM은 지정된 클러스터에 대한 정책 수정을 통해 작동하므로 ClusterGroupUpgrade CR은 여러 조건에 대해 true 또는 false 상태를 보고할 수 있습니다.
TALM이 클러스터 업데이트를 완료한 후에는 동일한 ClusterGroupUpgrade CR의 제어 하에서 클러스터가 다시 업데이트되지 않습니다. 다음 경우 새 ClusterGroupUpgrade CR을 생성해야 합니다.
- 클러스터를 다시 업데이트해야 하는 경우
-
클러스터가 업데이트 후 알림 정책과 호환되는
비준수로 변경되는 경우
19.10.5.1. 클러스터 선택 링크 복사링크가 클립보드에 복사되었습니다!
TALM은 수정 계획을 빌드하고 다음 필드에 따라 클러스터를 선택합니다.
-
clusterLabelSelector필드는 업데이트하려는 클러스터의 레이블을 지정합니다.k8s.io/apimachinery/pkg/apis/meta/v1의 표준 라벨 선택기 목록으로 구성됩니다. 목록의 각 선택기는 레이블 값 쌍 또는 레이블 표현식을 사용합니다. 각 선택기의 일치는clusterSelector필드 및 cluster 필드의 일치 항목과 함께 최종클러스터목록에 추가됩니다. -
cluster필드는 업데이트할 클러스터 목록을 지정합니다. -
canaries필드는 카나리아 업데이트의 클러스터를 지정합니다. -
maxConcurrency필드는 배치에서 업데이트할 클러스터 수를 지정합니다.
clusterLabelSelector , clusterSelector 필드를 함께 사용하여 결합된 클러스터 목록을 생성할 수 있습니다.
수정 계획은 카나리아 필드에 나열된 클러스터에서 시작됩니다. 각 카나리아 클러스터는 단일 클러스터 배치를 형성합니다.
enabled 필드 를 false로 설정된 샘플 ClusterGroupUpgrade CR
- 1
- 업데이트할 클러스터 목록을 정의합니다.
- 2
enable필드는false로 설정됩니다.- 3
- 수정할 사용자 정의 정책 집합을 나열합니다.
- 4
- 클러스터 업데이트의 세부 사항을 정의합니다.
- 5
- 카나리아 업데이트의 클러스터를 정의합니다.
- 6
- 일괄 처리의 최대 동시 업데이트 수를 정의합니다. 수정 배치 수는 maxConcurrency 값으로 나눈 카나리아 클러스터 수와 카나리아 클러스터를 제외한 클러스터 수입니다. 모든 관리 정책을 이미 준수하는 클러스터는 수정 계획에서 제외됩니다.
- 7
- 클러스터 선택을 위한 매개변수를 표시합니다.
- 8
- 일괄 처리 시간이 초과될 때 발생하는 작업을 제어합니다. 가능한 값은
중단되거나계속됩니다. 지정하지 않는 경우 기본값은continue입니다. - 9
- 업데이트 상태에 대한 정보를 표시합니다.
- 10
ClustersSelected조건은 선택한 모든 클러스터가 유효하다는 것을 보여줍니다.- 11
Validated조건은 선택한 모든 클러스터의 유효성을 검사합니다.
카나리아 클러스터를 업데이트하는 동안 오류가 발생하면 업데이트 프로세스가 중단됩니다.
수정 계획을 성공적으로 생성하면 enable 필드를 true 로 설정하고 TALM이 지정된 관리 정책을 사용하여 비준수 클러스터를 업데이트하기 시작할 수 있습니다.
ClusterGroupUpgrade CR의 enable 필드가 false 로 설정된 경우에만 spec 필드를 변경할 수 있습니다.
19.10.5.2. 검증 링크 복사링크가 클립보드에 복사되었습니다!
TALM은 지정된 모든 관리 정책이 사용 가능하고 올바르며 Validated 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.
true검증이 완료되었습니다.
false정책이 누락되거나 유효하지 않거나 잘못된 플랫폼 이미지가 지정되어 있습니다.
19.10.5.3. 사전 캐싱 링크 복사링크가 클립보드에 복사되었습니다!
클러스터는 컨테이너 이미지 레지스트리에 액세스하기 위해 대역폭이 제한되어 업데이트 완료 전에 타임아웃이 발생할 수 있습니다. 단일 노드 OpenShift 클러스터에서는 사전 캐싱을 사용하여 이러한 문제를 방지할 수 있습니다. preCaching 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성할 때 컨테이너 이미지 사전 캐싱이 시작됩니다.
TALM은 PrecacheSpecValid 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.
true사전 캐싱 사양이 유효하고 일관되게 유지됩니다.
false사전 캐싱 사양이 불완전합니다.
TALM은 PrecachingSucceeded 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.
trueTALM은 사전 캐싱 프로세스를 발표했습니다. 클러스터에 대한 사전 캐싱이 실패하면 해당 클러스터에 대한 업데이트가 실패하지만 다른 모든 클러스터를 진행합니다. 클러스터에 대한 사전 캐싱이 실패한 경우 메시지가 표시됩니다.
false하나 이상의 클러스터에 대한 사전 캐싱이 여전히 진행 중이거나 모든 클러스터에서 실패했습니다.
자세한 내용은 "컨테이너 이미지 사전 캐시 기능 사용" 섹션을 참조하십시오.
19.10.5.4. 백업 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift의 경우 TALM은 업데이트하기 전에 배포 백업을 생성할 수 있습니다. 업데이트에 실패하면 애플리케이션을 다시 프로비저닝하지 않고도 이전 버전을 복구하고 클러스터를 작동 상태로 복원할 수 있습니다. 백업 기능을 사용하려면 먼저 backup 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성합니다. 백업 내용이 최신 상태인지 확인하기 위해 ClusterGroupUpgrade CR의 enable 필드를 true 로 설정할 때까지 백업이 수행되지 않습니다.
TALM은 BackupSucceeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.
true모든 클러스터에 대한 백업이 완료되었거나 백업 실행이 완료되지만 하나 이상의 클러스터에는 실패했습니다. 클러스터에 대한 백업이 실패하면 해당 클러스터에 대한 업데이트가 실패하지만 다른 모든 클러스터를 진행합니다.
false하나 이상의 클러스터에 대한 백업이 여전히 진행 중이거나 모든 클러스터에 대해 실패했습니다.
자세한 내용은 "업그레이드 전에 클러스터 리소스의 백업 생성" 섹션을 참조하십시오.
19.10.5.5. 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
TALM은 수정 계획에 따라 정책을 적용합니다. 후속 배치에 대한 정책은 현재 배치의 모든 클러스터가 모든 관리 정책을 준수하는 직후 시작됩니다. 배치 시간이 초과되면 TALM은 다음 배치로 이동합니다. 배치의 시간 초과 값은 spec.timeout 필드이며 수정 계획의 배치 수로 나뉩니다.
TALM은 Progressing 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.
trueTALM은 비준수 정책을 수정하고 있습니다.
false업데이트가 진행되지 않았습니다. 가능한 이유는 다음과 같습니다.
- 모든 클러스터는 모든 관리 정책을 준수합니다.
- 정책 수정이 너무 오래 걸리는 경우 업데이트 시간이 초과되었습니다.
- 시스템에서 차단 CR이 누락되었거나 아직 완료되지 않았습니다.
-
ClusterGroupUpgradeCR이 활성화되지 않습니다. - 백업이 아직 진행 중입니다.
관리 정책은 ClusterGroupUpgrade CR의 managedPolicies 필드에 나열된 순서대로 적용됩니다. 하나의 관리형 정책이 한 번에 지정된 클러스터에 적용됩니다. 클러스터가 현재 정책을 준수하면 다음 관리 정책이 적용됩니다.
진행 상태의 샘플 ClusterGroupUpgrade CR
- 1
진행필드는 TALM이 정책을 수정하는 과정에 있음을 보여줍니다.
19.10.5.6. 업데이트 상태 링크 복사링크가 클립보드에 복사되었습니다!
TALM은 Succeeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.
true모든 클러스터는 지정된 관리 정책을 준수합니다.
false업데이트 적용에 사용할 수 있는 클러스터가 없거나 다음과 같은 이유 중 하나로 인해 정책 수정이 너무 오래 걸리기 때문에 정책 수정이 실패했습니다.
- 현재 일괄 처리에는 카나리아 업데이트가 포함되어 있으며 일괄 처리의 클러스터가 배치 제한 시간 내의 모든 관리 정책을 준수하지는 않습니다.
-
클러스터는
remediationStrategy필드에 지정된타임아웃값 내의 관리 정책을 준수하지 않았습니다.
Succeeded 상태의 샘플 ClusterGroupUpgrade CR
시간 초과 상태의 샘플 ClusterGroupUpgrade CR
19.10.5.7. ClusterGroupUpgrade CR 차단 링크 복사링크가 클립보드에 복사되었습니다!
여러 ClusterGroupUpgrade CR을 생성하고 애플리케이션 순서를 제어할 수 있습니다.
예를 들어 ClusterGroupUpgrade CR A의 시작을 차단하는 ClusterGroupUpgrade CR C를 생성하는 경우 ClusterGroupUpgrade CR C가 UpgradeComplete 가 될 때까지 ClusterGroupUpgrade CR A를 시작할 수 없습니다.
하나의 ClusterGroupUpgrade CR에는 여러 차단 CR이 있을 수 있습니다. 이 경우 현재 CR에 대한 업그레이드를 시작하기 전에 모든 차단 CR을 완료해야 합니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - hub 클러스터에서 RHACM 정책을 생성합니다.
절차
ClusterGroupUpgradeCR의 내용을cgu-a.yaml,cgu-b.yaml,cgu-c.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 차단 CR을 정의합니다.
cgu-a업데이트는cgu-c가 완료될 때까지 시작할 수 없습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cgu-b업데이트는cgu-a가 완료될 때까지 시작할 수 없습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cgu-c업데이트에는 차단 CR이 없습니다. TALM은enable필드가true로 설정된 경우cgu-c업데이트를 시작합니다.
각 관련 CR에 대해 다음 명령을 실행하여
ClusterGroupUpgradeCR을 생성합니다.oc apply -f <name>.yaml
$ oc apply -f <name>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 각 관련 CR에 대해 다음 명령을 실행하여 업데이트 프로세스를 시작합니다.
oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \ --type merge -p '{"spec":{"enable":true}}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 예제에서는
enable필드가true로 설정된ClusterGroupUpgradeCR을 보여줍니다.CR을 차단하는
cgu-a의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 차단 CR 목록을 표시합니다.
CR을 차단하는
cgu-b의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 차단 CR 목록을 표시합니다.
CR을 차단하는
cgu-c의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
cgu-c업데이트에는 차단 CR이 없습니다.
19.10.6. 관리 클러스터에서 정책 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
TALM(토폴로지 라이프사이클 관리자)은 ClusterGroupUpgrade CR에 지정된 클러스터에 대한 정보 정책 세트를 수정합니다. TALM은 관리형 RHACM 정책의 사본을 적용하여 정책을 수정합니다. 복사된 각 정책에는 해당하는 RHACM 배치 규칙과 RHACM 배치 규칙이 있습니다.
하나씩 TALM은 현재 배치에서 각 클러스터를 적용 가능한 관리 정책과 일치하는 배치 규칙에 추가합니다. 클러스터가 이미 정책을 준수하는 경우 TALM은 규정 준수 클러스터에서 해당 정책 적용을 건너뜁니다. 그런 다음 TALM을 이동하여 비호환 클러스터에 다음 정책을 적용합니다. TALM이 배치에서 업데이트를 완료하면 복사된 정책과 관련된 배치 규칙에서 모든 클러스터가 제거됩니다. 그런 다음 다음 배치의 업데이트가 시작됩니다.
맞춤 클러스터가 RHACM에 규정 준수 상태를 보고하지 않으면 허브 클러스터의 관리 정책이 TALM에 필요한 상태 정보가 누락될 수 있습니다. TALM은 다음과 같은 방법으로 이러한 사례를 처리합니다.
-
정책의
status.compliant필드가 없는 경우 TALM은 정책을 무시하고 로그 항목을 추가합니다. 그런 다음 TALM은 정책의status.status필드를 계속 확인합니다. -
정책의
status.status가 누락되면 TALM에서 오류가 발생합니다. -
정책의
status.status필드에 클러스터의 규정 준수 상태가 누락된 경우 TALM은 클러스터가 해당 정책과 일치하지 않는 것으로 간주합니다.
ClusterGroupUpgrade CR의 batchTimeoutAction 은 클러스터에 대한 업그레이드가 실패하는 경우 발생하는 상황을 결정합니다. 오류가 발생한 클러스터를 계속 건너뛰고 다른 클러스터를 계속 업그레이드하거나 모든 클러스터에 대한 정책 수정을 중지하려면 중단 을 지정할 수 있습니다. 제한 시간이 경과하면 TALM은 클러스터에 대한 추가 업데이트가 발생하지 않도록 모든 적용 정책을 제거합니다.
업그레이드 정책의 예
RHACM 정책에 대한 자세한 내용은 정책 개요 를 참조하십시오.
19.10.6.1. TALM을 사용하여 설치하는 관리형 클러스터에 대한 Operator 서브스크립션 구성 링크 복사링크가 클립보드에 복사되었습니다!
Operator의 Subscription CR(사용자 정의 리소스)에 status.state.AtLatestKnown 필드가 포함된 경우에만 TALM( topology Aware Lifecycle Manager)은 Operator에 대한 설치 계획을 승인할 수 있습니다.
절차
status.state.AtLatestKnown필드를 Operator의SubscriptionCR에 추가합니다.서브스크립션 CR의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
status.state: AtLatestKnown필드는 Operator 카탈로그에서 사용 가능한 최신 Operator 버전에 사용됩니다.
참고레지스트리에서 새 버전의 Operator를 사용할 수 있으면 연결된 정책이 호환되지 않습니다.
-
ClusterGroupUpgradeCR이 있는 관리 클러스터에 변경된서브스크립션정책을 적용합니다.
19.10.6.2. 관리 클러스터에 업데이트 정책 적용 링크 복사링크가 클립보드에 복사되었습니다!
정책을 적용하여 관리 클러스터를 업데이트할 수 있습니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - hub 클러스터에서 RHACM 정책을 생성합니다.
절차
ClusterGroupUpgradeCR의 내용을cgu-1.yaml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ClusterGroupUpgradeCR을 생성합니다.oc create -f cgu-1.yaml
$ oc create -f cgu-1.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 hub 클러스터에
ClusterGroupUpgradeCR이 생성되었는지 확인합니다.oc get cgu --all-namespaces
$ oc get cgu --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME AGE STATE DETAILS default cgu-1 8m55 NotEnabled Not Enabled
NAMESPACE NAME AGE STATE DETAILS default cgu-1 8m55 NotEnabled Not EnabledCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 업데이트 상태를 확인합니다.
oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq$ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ClusterGroupUpgradeCR의spec.enable필드가false로 설정됩니다.
다음 명령을 실행하여 정책의 상태를 확인합니다.
oc get policies -A
$ oc get policies -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 클러스터에 현재 적용된 정책의
spec.remediationAction필드가 적용되도록 설정되어있습니다.ClusterGroupUpgradeCR의정보모드의 관리 정책은 업데이트 중에계속알림 모드로 유지됩니다.
다음 명령을 실행하여
spec.enable필드의 값을true로 변경합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \ --patch '{"spec":{"enable":true}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \ --patch '{"spec":{"enable":true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 업데이트 상태를 다시 확인합니다.
oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq$ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 현재 배치의 업데이트 진행 상황을 반영합니다. 이 명령을 다시 실행하여 진행 상황에 대한 업데이트된 정보를 받습니다.
정책에 Operator 서브스크립션이 포함된 경우 단일 노드 클러스터에서 설치 진행 상황을 직접 확인할 수 있습니다.
다음 명령을 실행하여 설치 진행 상황을 확인할 단일 노드 클러스터의
KUBECONFIG파일을 내보냅니다.export KUBECONFIG=<cluster_kubeconfig_absolute_path>
$ export KUBECONFIG=<cluster_kubeconfig_absolute_path>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 단일 노드 클러스터에 있는 모든 서브스크립션을 확인하고 다음 명령을 실행하여
ClusterGroupUpgradeCR을 통해 설치하려는 정책에서 해당 서브스크립션을 찾습니다.oc get subs -A | grep -i <subscription_name>
$ oc get subs -A | grep -i <subscription_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-logging정책의 출력 예NAMESPACE NAME PACKAGE SOURCE CHANNEL openshift-logging cluster-logging cluster-logging redhat-operators stable
NAMESPACE NAME PACKAGE SOURCE CHANNEL openshift-logging cluster-logging cluster-logging redhat-operators stableCopy to Clipboard Copied! Toggle word wrap Toggle overflow
관리 정책 중 하나에
ClusterVersionCR이 포함된 경우 spoke 클러스터에 대해 다음 명령을 실행하여 현재 배치의 플랫폼 업데이트 상태를 확인합니다.oc get clusterversion
$ oc get clusterversionCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.12.5 True True 43s Working towards 4.4.12.7: 71 of 735 done (9% complete)
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.4.12.5 True True 43s Working towards 4.4.12.7: 71 of 735 done (9% complete)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Operator 서브스크립션을 확인합니다.
oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"$ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 원하는 서브스크립션과 연결된 단일 노드 클러스터에 있는 설치 계획을 확인합니다.
oc get installplan -n <subscription_namespace>
$ oc get installplan -n <subscription_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow cluster-loggingOperator의 출력 예NAMESPACE NAME CSV APPROVAL APPROVED openshift-logging install-6khtw cluster-logging.5.3.3-4 Manual true
NAMESPACE NAME CSV APPROVAL APPROVED openshift-logging install-6khtw cluster-logging.5.3.3-4 Manual true1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 설치 계획의
Approval필드가Manual로 설정되고 TALM에서 설치 계획을 승인한 후승인필드가false에서true로 변경됩니다.
참고TALM이 서브스크립션이 포함된 정책을 수정하면 해당 서브스크립션에 연결된 모든 설치 계획을 자동으로 승인합니다. Operator를 최신 알려진 버전으로 가져오기 위해 여러 설치 계획이 필요한 경우 TALM에서 여러 설치 계획을 승인하고 하나 이상의 중간 버전을 통해 업그레이드하여 최종 버전으로 가져올 수 있습니다.
다음 명령을 실행하여
ClusterGroupUpgrade를 설치하는 정책의 클러스터 서비스 버전에 도달했는지확인합니다.oc get csv -n <operator_namespace>
$ oc get csv -n <operator_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow OpenShift Logging Operator의 출력 예
NAME DISPLAY VERSION REPLACES PHASE cluster-logging.5.4.2 Red Hat OpenShift Logging 5.4.2 Succeeded
NAME DISPLAY VERSION REPLACES PHASE cluster-logging.5.4.2 Red Hat OpenShift Logging 5.4.2 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.7. 업그레이드 전에 클러스터 리소스 백업 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift의 경우 TALM(토폴로지 라이프사이클 관리자)은 업그레이드 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 이전 버전을 복구하고 애플리케이션을 다시 프로비저닝하지 않고도 클러스터를 작업 상태로 복원할 수 있습니다.
백업 기능을 사용하려면 먼저 backup 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성합니다. 백업 내용이 최신 상태인지 확인하기 위해 ClusterGroupUpgrade CR의 enable 필드를 true 로 설정할 때까지 백업이 수행되지 않습니다.
TALM은 BackupSucceeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.
true모든 클러스터에 대한 백업이 완료되었거나 백업 실행이 완료되지만 하나 이상의 클러스터에는 실패했습니다. 클러스터에 대한 백업이 실패하면 해당 클러스터가 업데이트되지 않습니다.
false하나 이상의 클러스터에 대한 백업이 여전히 진행 중이거나 모든 클러스터에 대해 실패했습니다. 스포크 클러스터에서 실행되는 백업 프로세스는 다음과 같은 상태를 가질 수 있습니다.
PreparingToStart첫 번째 조정 절차가 진행 중입니다. TALM은 실패한 업그레이드 시도에서 생성된 모든 맞춤 백업 네임스페이스 및 허브 보기 리소스를 삭제합니다.
Starting백업 사전 요구 사항 및 백업 작업이 생성됩니다.
활성 상태백업이 진행 중입니다.
Succeed백업이 성공했습니다.
BackupTimeout아티팩트 백업이 부분적으로 수행됩니다.
복구할 수 없는Error백업이 0이 아닌 종료 코드로 종료되었습니다.
클러스터 백업에 실패하고 BackupTimeout 또는 UnrecoverableError 상태를 입력하면 클러스터 업데이트가 해당 클러스터를 진행하지 않습니다. 다른 클러스터에 대한 업데이트는 영향을 받지 않으며 계속됩니다.
19.10.7.1. 백업을 사용하여 ClusterGroupUpgrade CR 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 클러스터에서 업그레이드하기 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 TALM(토폴로지 라이프사이클 관리자)에서 생성된 upgrade-recovery.sh 스크립트를 사용하여 시스템을 preupgrade 상태로 되돌릴 수 있습니다. 백업은 다음 항목으로 구성됩니다.
- 클러스터 백업
-
etcd및 정적 Pod 매니페스트의 스냅샷입니다. - 콘텐츠 백업
-
폴더 백업(예:
/etc,/usr/local,/var/lib/kubelet). - 변경된 파일 백업
-
machine-config에서 관리하는 모든 파일이 변경되었습니다. - 배포
-
고정된
ostree배포. - 이미지 (선택 사항)
- 사용 중인 컨테이너 이미지입니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - RHACM(Red Hat Advanced Cluster Management) 설치.
복구 파티션을 만드는 것이 좋습니다. 다음은 50GB의 복구 파티션에 대한 SiteConfig CR(사용자 정의 리소스)의 예입니다.
절차
backup을 사용하여ClusterGroupUpgradeCR의 콘텐츠를 저장하고clustergroupupgrades-group-du.yaml파일에서true로 설정된 필드를활성화합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트를 시작하려면 다음 명령을 실행하여
ClusterGroupUpgradeCR을 적용합니다.oc apply -f clustergroupupgrades-group-du.yaml
$ oc apply -f clustergroupupgrades-group-du.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 허브 클러스터에서 업그레이드 상태를 확인합니다.
oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.7.2. 업그레이드 실패 후 클러스터 복구 링크 복사링크가 클립보드에 복사되었습니다!
클러스터 업그레이드에 실패하면 클러스터에 수동으로 로그인하고 백업을 사용하여 클러스터를 preupgrade 상태로 되돌릴 수 있습니다. 두 단계가 있습니다.
- rollback
- 시도한 업그레이드에 플랫폼 OS 배포 변경이 포함된 경우 복구 스크립트를 실행하기 전에 이전 버전으로 롤백해야 합니다.
롤백은 TALM 및 단일 노드 OpenShift에서의 업그레이드에만 적용됩니다. 이 프로세스는 다른 업그레이드 유형의 롤백에는 적용되지 않습니다.
- 복구
- 복구가 컨테이너를 종료하고 백업 파티션의 파일을 사용하여 컨테이너를 다시 시작하고 클러스터를 복원합니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
- RHACM(Red Hat Advanced Cluster Management) 설치.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - 백업용으로 구성된 업그레이드를 실행합니다.
절차
다음 명령을 실행하여 이전에 생성된
ClusterGroupUpgradeCR(사용자 정의 리소스)을 삭제합니다.oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
$ oc delete cgu/du-upgrade-4918 -n ztp-group-du-snoCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 복구하려는 클러스터에 로그인합니다.
다음 명령을 실행하여 플랫폼 OS 배포의 상태를 확인합니다.
ostree admin status
$ ostree admin statusCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
ostree admin status
[root@lab-test-spoke2-node-0 core]# ostree admin status * rhcos c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9.0 Version: 49.84.202202230006-0 Pinned: yes1 origin refspec: c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 현재 배포가 고정되어 있습니다. 플랫폼 OS 배포 롤백이 필요하지 않습니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 플랫폼 OS 배포의 롤백을 트리거하려면 다음 명령을 실행합니다.
rpm-ostree rollback -r
$ rpm-ostree rollback -rCopy to Clipboard Copied! Toggle word wrap Toggle overflow 복구의 첫 번째 단계는 컨테이너를 종료하고 백업 파티션에서 대상 디렉터리로 파일을 복원합니다. 복구를 시작하려면 다음 명령을 실행합니다.
/var/recovery/upgrade-recovery.sh
$ /var/recovery/upgrade-recovery.shCopy to Clipboard Copied! Toggle word wrap Toggle overflow 메시지가 표시되면 다음 명령을 실행하여 클러스터를 재부팅합니다.
systemctl reboot
$ systemctl rebootCopy to Clipboard Copied! Toggle word wrap Toggle overflow 재부팅 후 다음 명령을 실행하여 복구를 다시 시작하십시오.
/var/recovery/upgrade-recovery.sh --resume
$ /var/recovery/upgrade-recovery.sh --resumeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
복구 유틸리티에 실패하면 --restart 옵션을 사용하여 다시 시도할 수 있습니다.
/var/recovery/upgrade-recovery.sh --restart
$ /var/recovery/upgrade-recovery.sh --restart
검증
복구 상태를 확인하려면 다음 명령을 실행합니다.
oc get clusterversion,nodes,clusteroperator
$ oc get clusterversion,nodes,clusteroperatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.8. 컨테이너 이미지 사전 캐시 기능 사용 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift 클러스터에 컨테이너 이미지 레지스트리에 액세스하기 위해 대역폭이 제한되어 업데이트가 완료되기 전에 타임아웃이 발생할 수 있습니다.
업데이트 시간은 TALM에 의해 설정되지 않습니다. 수동 애플리케이션 또는 외부 자동화로 업데이트를 시작할 때 ClusterGroupUpgrade CR을 적용할 수 있습니다.
ClusterGroupUpgrade CR에서 preCaching 필드가 true 로 설정된 경우 컨테이너 이미지 사전 캐싱이 시작됩니다.
TALM은 PrecacheSpecValid 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.
true사전 캐싱 사양이 유효하고 일관되게 유지됩니다.
false사전 캐싱 사양이 불완전합니다.
TALM은 PrecachingSucceeded 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.
trueTALM은 사전 캐싱 프로세스를 발표했습니다. 클러스터에 대한 사전 캐싱이 실패하면 해당 클러스터에 대한 업데이트가 실패하지만 다른 모든 클러스터를 진행합니다. 클러스터에 대한 사전 캐싱이 실패한 경우 메시지가 표시됩니다.
false하나 이상의 클러스터에 대한 사전 캐싱이 여전히 진행 중이거나 모든 클러스터에서 실패했습니다.
성공적인 사전 캐싱 프로세스 후 정책을 수정할 수 있습니다. enable 필드가 true 로 설정된 경우 수정 작업이 시작됩니다. 클러스터에 사전 캐싱 오류가 있는 경우 해당 클러스터에 대한 업그레이드가 실패합니다. 업그레이드 프로세스는 사전 캐시가 성공한 다른 모든 클러스터에서 계속됩니다.
사전 캐싱 프로세스는 다음 상태에 있을 수 있습니다.
NotStarted이는 모든 클러스터가
ClusterGroupUpgradeCR의 첫 번째 조정 통과 시에 자동으로 할당된 초기 상태입니다. TALM은 이전의 불완전한 업데이트에서 남아 있는 맞춤 클러스터의 사전 캐싱 네임스페이스 및 허브 뷰 리소스를 삭제합니다. 그런 다음 TALM은 스포크 사전 캐싱 네임스페이스에 대한 새로운ManagedClusterView리소스를 생성하여PrecachePreparing상태에서 삭제를 확인합니다.PreparingToStart이전의 불완전한 업데이트에서 나머지 리소스를 정리하는 작업이 진행 중입니다.
Starting사전 캐싱 작업 사전 요구 사항 및 작업이 생성됩니다.
활성 상태작업은 "Active" 상태입니다.
Succeedpre-cache 작업이 성공했습니다.
PrecacheTimeout아티팩트 사전 캐싱은 부분적으로 수행됩니다.
복구할 수 없는Error작업은 0이 아닌 종료 코드로 끝납니다.
19.10.8.1. 사전 캐싱을 사용하여 ClusterGroupUpgrade CR 생성 링크 복사링크가 클립보드에 복사되었습니다!
단일 노드 OpenShift의 경우 사전 캐시 기능을 사용하면 업데이트가 시작되기 전에 필요한 컨테이너 이미지가 spoke 클러스터에 있을 수 있습니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
clustergroupupgrades-group-du.yaml파일에서preCaching필드가true로 설정된 상태에서ClusterGroupUpgradeCR의 콘텐츠를 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
preCaching필드가true로 설정되어 업데이트를 시작하기 전에 TALM이 컨테이너 이미지를 가져올 수 있습니다.
사전 캐싱을 시작하려면 다음 명령을 실행하여
ClusterGroupUpgradeCR을 적용합니다.oc apply -f clustergroupupgrades-group-du.yaml
$ oc apply -f clustergroupupgrades-group-du.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 명령을 실행하여 hub 클러스터에
ClusterGroupUpgradeCR이 있는지 확인합니다.oc get cgu -A
$ oc get cgu -ACopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME AGE STATE DETAILS ztp-group-du-sno du-upgrade-4918 10s InProgress Precaching is required and not done
NAMESPACE NAME AGE STATE DETAILS ztp-group-du-sno du-upgrade-4918 10s InProgress Precaching is required and not done1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- CR이 생성됩니다.
다음 명령을 실행하여 사전 캐싱 작업의 상태를 확인합니다.
oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 확인된 클러스터 목록을 표시합니다.
스포크 클러스터에서 다음 명령을 실행하여 사전 캐싱 작업의 상태를 확인합니다.
oc get jobs,pods -n openshift-talo-pre-cache
$ oc get jobs,pods -n openshift-talo-pre-cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME COMPLETIONS DURATION AGE job.batch/pre-cache 0/1 3m10s 3m10s NAME READY STATUS RESTARTS AGE pod/pre-cache--1-9bmlr 1/1 Running 0 3m10s
NAME COMPLETIONS DURATION AGE job.batch/pre-cache 0/1 3m10s 3m10s NAME READY STATUS RESTARTS AGE pod/pre-cache--1-9bmlr 1/1 Running 0 3m10sCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ClusterGroupUpgradeCR의 상태를 확인합니다.oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'$ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 사전 캐시 작업이 수행됩니다.
19.10.9. 토폴로지 Aware Lifecycle Manager 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
TALM(토폴로지 라이프사이클 관리자)은 RHACM 정책을 해결하는 OpenShift Container Platform Operator입니다. 문제가 발생하면 oc adm must-gather 명령을 사용하여 세부 정보 및 로그를 수집하고 문제를 디버깅하는 단계를 수행합니다.
관련 항목에 대한 자세한 내용은 다음 문서를 참조하십시오.
19.10.9.1. 일반 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
다음 질문을 검토하여 문제의 원인을 확인할 수 있습니다.
적용 중인 구성이 지원됩니까?
- RHACM 및 OpenShift Container Platform 버전이 호환됩니까?
- TALM 및 RHACM 버전이 호환됩니까?
다음 중 문제를 유발하는 구성 요소는 무엇입니까?
ClusterGroupUpgrade 구성이 작동하는지 확인하려면 다음을 수행합니다.
-
spec.enable필드를false로 설정하여ClusterGroupUpgradeCR을 생성합니다. - 상태가 업데이트될 때까지 기다린 후 문제 해결 질문을 진행합니다.
-
모든 항목이 예상대로 표시되면
ClusterGroupUpgradeCR에서spec.enable필드를true로 설정합니다.
ClusterUpgradeGroup CR에서 spec.enable 필드를 true 로 설정한 후 업데이트 절차가 시작되고 CR의 spec 필드를 더 이상 편집할 수 없습니다.
19.10.9.2. ClusterUpgradeGroup CR을 수정할 수 없습니다. 링크 복사링크가 클립보드에 복사되었습니다!
- 문제
-
업데이트를 활성화한 후에는
ClusterUpgradeGroupCR을 편집할 수 없습니다. - 해결
다음 단계를 수행하여 절차를 다시 시작하십시오.
다음 명령을 실행하여 이전
ClusterGroupUpgradeCR을 제거합니다.oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>
$ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 관리 클러스터 및 정책의 기존 문제를 확인하고 수정합니다.
- 모든 클러스터가 관리 클러스터이고 사용 가능한지 확인합니다.
-
모든 정책이 존재하고
spec.remediationAction필드가inform로 설정되어 있는지 확인합니다.
올바른 구성으로 새
ClusterGroupUpgradeCR을 생성합니다.oc apply -f <ClusterGroupUpgradeCR_YAML>
$ oc apply -f <ClusterGroupUpgradeCR_YAML>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.9.3. 관리형 정책 링크 복사링크가 클립보드에 복사되었습니다!
시스템에서 관리 정책 확인
- 문제
- 시스템에 올바른 관리 정책이 있는지 확인하려고 합니다.
- 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]
["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
수정 모드 확인
- 문제
-
관리 정책의
사양을알리기위해remediationAction필드가 설정되어 있는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get policies --all-namespaces
$ oc get policies --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
정책 규정 준수 상태 확인
- 문제
- 정책의 규정 준수 상태를 확인하려고 합니다.
- 해결
다음 명령을 실행합니다.
oc get policies --all-namespaces
$ oc get policies --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21h
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default policy1-common-cluster-version-policy inform NonCompliant 5d21h default policy2-common-nto-sub-policy inform Compliant 5d21h default policy3-common-ptp-sub-policy inform NonCompliant 5d21h default policy4-common-sriov-sub-policy inform NonCompliant 5d21hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.9.4. 클러스터 링크 복사링크가 클립보드에 복사되었습니다!
관리 클러스터가 있는지 확인
- 문제
-
ClusterGroupUpgradeCR의 클러스터가 관리 클러스터인지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get managedclusters
$ oc get managedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.example.com:6443 True Unknown 13d spoke1 true https://api.spoke1.example.com:6443 True True 13d spoke3 true https://api.spoke3.example.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.example.com:6443 True Unknown 13d spoke1 true https://api.spoke1.example.com:6443 True True 13d spoke3 true https://api.spoke3.example.com:6443 True True 27hCopy to Clipboard Copied! Toggle word wrap Toggle overflow 또는 TALM 관리자 로그를 확인합니다.
다음 명령을 실행하여 TALM 관리자의 이름을 가져옵니다.
oc get pod -n openshift-operators
$ oc get pod -n openshift-operatorsCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME READY STATUS RESTARTS AGE cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp 2/2 Running 0 45m
NAME READY STATUS RESTARTS AGE cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp 2/2 Running 0 45mCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 TALM 관리자 로그를 확인합니다.
oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
$ oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItemERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"}1 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItemCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 오류 메시지는 클러스터가 관리 클러스터가 아님을 나타냅니다.
관리 클러스터를 사용할 수 있는지 확인
- 문제
-
ClusterGroupUpgradeCR에 지정된 관리 클러스터를 사용할 수 있는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get managedclusters
$ oc get managedclustersCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.testlab.com:6443 True Unknown 13d spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE local-cluster true https://api.hub.testlab.com:6443 True Unknown 13d spoke1 true https://api.spoke1.testlab.com:6443 True True 13d1 spoke3 true https://api.spoke3.testlab.com:6443 True True 27h2 Copy to Clipboard Copied! Toggle word wrap Toggle overflow
clusterLabelSelector 확인
- 문제
-
ClusterGroupUpgradeCR에 지정된clusterLabelSelector필드가 관리형 클러스터 중 하나 이상과 일치하는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get managedcluster --selector=upgrade=true
$ oc get managedcluster --selector=upgrade=true1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 업데이트하려는 클러스터의 레이블은
upgrade:true입니다.
출력 예
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
카나리아 클러스터가 있는지 확인
- 문제
클러스터 목록에 카나리아 클러스터가 있는지 확인하려고 합니다.
ClusterGroupUpgradeCR의 예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
["spoke1", "spoke3"]
["spoke1", "spoke3"]Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
clusterLabelSelector라벨과 일치하는 클러스터 목록에 카나리아 클러스터가 있는지 확인합니다.oc get managedcluster --selector=upgrade=true
$ oc get managedcluster --selector=upgrade=trueCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27h
NAME HUB ACCEPTED MANAGED CLUSTER URLS JOINED AVAILABLE AGE spoke1 true https://api.spoke1.testlab.com:6443 True True 13d spoke3 true https://api.spoke3.testlab.com:6443 True True 27hCopy to Clipboard Copied! Toggle word wrap Toggle overflow
클러스터는 spec.clusters 에 존재할 수 있으며 spec.clusterLabelSelector 레이블과도 일치할 수 있습니다.
스포크 클러스터에서 사전 캐싱 상태 확인
스포크 클러스터에서 다음 명령을 실행하여 사전 캐싱의 상태를 확인합니다.
oc get jobs,pods -n openshift-talo-pre-cache
$ oc get jobs,pods -n openshift-talo-pre-cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.9.5. 수정 전략 링크 복사링크가 클립보드에 복사되었습니다!
ClusterGroupUpgrade CR에 remediationStrategy가 있는지 확인
- 문제
-
ClusterGroupUpgradeCR에remediationStrategy가 있는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
{"maxConcurrency":2, "timeout":240}{"maxConcurrency":2, "timeout":240}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
ClusterGroupUpgrade CR에 maxConcurrency가 지정되었는지 확인
- 문제
-
maxConcurrency가ClusterGroupUpgradeCR에 지정되어 있는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
2
2Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.10.9.6. 토폴로지 수명 주기 관리자 링크 복사링크가 클립보드에 복사되었습니다!
ClusterGroupUpgrade CR에서 조건 메시지 및 상태 확인
- 문제
-
ClusterGroupUpgradeCR에서status.conditions필드 값을 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
복사된 정책 확인
- 문제
-
status.managedPoliciesForUpgrade의 모든 정책에 해당 정책이status.copiedPolicies에 있는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -oyaml
$ oc get cgu lab-upgrade -oyamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
status.remediationPlan이 계산되었는지 확인
- 문제
-
status.remediationPlan이 계산되었는지 확인하려고 합니다. - 해결
다음 명령을 실행합니다.
oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
[["spoke2", "spoke3"]]
[["spoke2", "spoke3"]]Copy to Clipboard Copied! Toggle word wrap Toggle overflow
TALM 관리자 컨테이너의 오류
- 문제
- TALM의 관리자 컨테이너의 로그를 확인하려고 합니다.
- 해결
다음 명령을 실행합니다.
oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager
$ oc logs -n openshift-operators \ cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c managerCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
ERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItemERROR controller-runtime.manager.controller.clustergroupupgrade Reconciler error {"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"}1 sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItemCopy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 오류를 표시합니다.
ClusterGroupUpgrade CR이 완료된 후 클러스터는 일부 정책을 준수하지 않습니다.
- 문제
TALM이 모든 클러스터에 대해 수정이 필요한지 여부를 결정하는 데 사용하는 정책 준수 상태입니다. 다음과 같은 이유로 인해 발생할 수 있습니다.
- CGU는 정책을 만들거나 업데이트한 후 너무 빨리 실행되었습니다.
-
정책을 수정하면
ClusterGroupUpgradeCR의 후속 정책 준수에 영향을 미칩니다.
- 해결
-
새를 생성하고 동일한 사양을 사용하여
ClusterGroupUpdateCR을 적용합니다.
19.11. 토폴로지 Aware Lifecycle Manager를 사용하여 연결이 끊긴 환경에서 관리형 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
Topology Aware Lifecycle Manager (TALM)를 사용하여 OpenShift Container Platform 관리 클러스터의 소프트웨어 라이프사이클을 관리할 수 있습니다. TALM은 RHACM(Red Hat Advanced Cluster Management) 정책을 사용하여 대상 클러스터에서 변경 사항을 수행합니다.
19.11.1. 연결이 끊긴 환경에서 클러스터 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP 및 Topology Aware Lifecycle Manager(TALM)를 사용하여 배포한 관리형 클러스터 및 Operator를 업그레이드할 수 있습니다.
19.11.1.1. 환경 설정 링크 복사링크가 클립보드에 복사되었습니다!
TALM은 플랫폼과 Operator 업데이트를 모두 수행할 수 있습니다.
TALM을 사용하여 연결이 끊긴 클러스터를 업데이트하기 전에 미러 레지스트리에서 업데이트하려는 플랫폼 이미지 및 Operator 이미지를 모두 미러링해야 합니다. 이미지를 미러링하려면 다음 단계를 완료합니다.
플랫폼 업데이트의 경우 다음 단계를 수행해야 합니다.
원하는 OpenShift Container Platform 이미지 저장소를 미러링합니다. 추가 리소스에 연결된 "OpenShift Container Platform 이미지 저장소 미러링" 절차에 따라 원하는 플랫폼 이미지가 미러링되었는지 확인합니다.
imageContentSources.yaml 파일의 imageContentSources 섹션을 저장합니다.출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 미러링된 플랫폼 이미지의 이미지 서명을 저장합니다. 플랫폼 업데이트의 경우
PolicyGenTemplateCR에 이미지 서명을 추가해야 합니다. 이미지 서명을 가져오려면 다음 단계를 수행합니다.다음 명령을 실행하여 원하는 OpenShift Container Platform 태그를 지정합니다.
OCP_RELEASE_NUMBER=<release_version>
$ OCP_RELEASE_NUMBER=<release_version>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 서버의 아키텍처를 지정합니다.
ARCHITECTURE=<server_architecture>
$ ARCHITECTURE=<server_architecture>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 Quay에서 릴리스 이미지 다이제스트를 가져옵니다.
DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"$ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 다이제스트 알고리즘을 설정합니다.
DIGEST_ALGO="${DIGEST%%:*}"$ DIGEST_ALGO="${DIGEST%%:*}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 다이제스트 서명을 설정합니다.
DIGEST_ENCODED="${DIGEST#*:}"$ DIGEST_ENCODED="${DIGEST#*:}"Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 mirror.openshift.com 웹 사이트에서 이미지 서명을 가져옵니다.
SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)$ SIGNATURE_BASE64=$(curl -s "https://mirror.openshift.com/pub/openshift-v4/signatures/openshift/release/${DIGEST_ALGO}=${DIGEST_ENCODED}/signature-1" | base64 -w0 && echo)Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
체크섬-<OCP_RELEASE_NUMBER>.yaml파일에 이미지 서명을 저장합니다.cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOF$ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} EOFCopy to Clipboard Copied! Toggle word wrap Toggle overflow
업데이트 그래프를 준비합니다. 업데이트 그래프를 준비하는 두 가지 옵션이 있습니다.
OpenShift 업데이트 서비스를 사용합니다.
hub 클러스터에서 그래프를 설정하는 방법에 대한 자세한 내용은 Deploy the operator for OpenShift Update Service 및 Build the graph data init 컨테이너를 참조하십시오.
업스트림 그래프의 로컬 사본을 만듭니다. 연결이 끊긴 환경의
http또는https서버에서 관리 클러스터에 액세스할 수 있는 업데이트 그래프를 호스팅합니다. 업데이트 그래프를 다운로드하려면 다음 명령을 사용하십시오.curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.12 -o ~/upgrade-graph_stable-4.12
$ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.12 -o ~/upgrade-graph_stable-4.12Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 업데이트의 경우 다음 작업을 수행해야 합니다.
- Operator 카탈로그를 미러링합니다. "연결이 끊긴 클러스터와 함께 사용하기 위해 Operator 카탈로그 미러링 절차에 따라 원하는 Operator 이미지가 미러링되었는지 확인합니다.
19.11.1.2. 플랫폼 업데이트 수행 링크 복사링크가 클립보드에 복사되었습니다!
TALM으로 플랫폼 업데이트를 수행할 수 있습니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- ZTP를 최신 버전으로 업데이트합니다.
- ZTP로 하나 이상의 관리 클러스터를 프로비저닝합니다.
- 원하는 이미지 저장소를 미러링합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - hub 클러스터에서 RHACM 정책을 생성합니다.
절차
플랫폼 업데이트에 대한
PolicyGenTemplateCR을 생성합니다.du-upgrade.yaml파일에PolicyGenTemplateCR의 다음 내용을 저장합니다.플랫폼 업데이트의
PolicyGenTemplate예Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
ConfigMapCR에는 업데이트할 릴리스 이미지의 서명이 포함되어 있습니다.- 2
- 원하는 OpenShift Container Platform 릴리스의 이미지 서명을 표시합니다. "환경 설정" 섹션의 절차에 따라 저장한
checksum-${OCP_RELEASE_NUMBER}.yaml파일에서 서명을 가져옵니다. - 3
- 원하는 OpenShift Container Platform 이미지가 포함된 미러 리포지토리를 표시합니다. "환경 설정" 섹션의 절차에 따라 저장할 때 저장한
imageContentSources.yaml파일에서 미러를 가져옵니다. - 4
- 업데이트를 트리거하는
ClusterVersionCR을 표시합니다. 이미지 사전 캐싱에는채널,업스트림및desiredVersion필드가 모두 필요합니다.
PolicyGenTemplateCR은 다음 두 가지 정책을 생성합니다.-
du-upgrade-platform-upgrade-prep정책은 플랫폼 업데이트에 대한 준비 작업을 수행합니다. 원하는 릴리스 이미지 서명을 위해ConfigMapCR을 생성하고 미러링된 릴리스 이미지 저장소의 이미지 콘텐츠 소스를 생성하고, 연결이 끊긴 환경에서 관리되는 클러스터에서 연결할 수 있는 업데이트 채널을 사용하여 클러스터 버전을 업데이트합니다. -
du-upgrade-platform-upgrade정책은 플랫폼 업그레이드를 수행하는 데 사용됩니다.
du-upgrade.yaml파일 콘텐츠를PolicyGenTemplateCR의 ZTP Git 리포지토리에 있는kustomization.yaml파일에 추가하고 변경 사항을 Git 리포지토리로 내보냅니다.argocd는 Git 리포지토리에서 변경 사항을 가져와 hub 클러스터에서 정책을 생성합니다.
다음 명령을 실행하여 생성된 정책을 확인합니다.
oc get policies -A | grep platform-upgrade
$ oc get policies -A | grep platform-upgradeCopy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable필드를false로 설정하여 플랫폼 업데이트의ClusterGroupUpdateCR을 생성합니다.du-upgrade-platform-upgrade-prep 및 du-upgrade-platform-upgrade정책 및 대상 클러스터를 다음 예와 같이cgu-platform-upgrade.yml파일에 사용하여 플랫폼 업데이트ClusterGroupUpdateCR의 콘텐츠를 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 hub 클러스터에
ClusterGroupUpdateCR을 적용합니다.oc apply -f cgu-platform-upgrade.yml
$ oc apply -f cgu-platform-upgrade.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
선택 사항: 플랫폼 업데이트의 이미지를 미리 캐시합니다.
다음 명령을 실행하여
ClusterGroupUpdateCR에서 사전 캐싱을 활성화합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트 프로세스를 모니터링하고 사전 캐싱이 완료될 때까지 기다립니다. hub 클러스터에서 다음 명령을 실행하여 사전 캐싱의 상태를 확인합니다.
oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'$ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
플랫폼 업데이트를 시작합니다.
cgu-platform-upgrade정책을 활성화하고 다음 명령을 실행하여 사전 캐싱을 비활성화합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.
oc get policies --all-namespaces
$ oc get policies --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.11.1.3. Operator 업데이트 수행 링크 복사링크가 클립보드에 복사되었습니다!
TALM을 사용하여 Operator 업데이트를 수행할 수 있습니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- ZTP를 최신 버전으로 업데이트합니다.
- ZTP로 하나 이상의 관리 클러스터를 프로비저닝합니다.
- 번들 이미지에서 참조하는 모든 Operator 이미지, 번들 이미지 및 모든 Operator 이미지를 미러링합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - hub 클러스터에서 RHACM 정책을 생성합니다.
절차
Operator 업데이트에 대한
PolicyGenTemplateCR을 업데이트합니다.파일에서 다음과 같은 추가 내용으로 du-upgradedu-upgrade.yamlPolicyGenTemplateCR을 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 인덱스 이미지 URL에는 원하는 Operator 이미지가 포함되어 있습니다. 인덱스 이미지가 항상 동일한 이미지 이름과 태그로 푸시되면 이 변경이 필요하지 않습니다.
- 2
- OLM(Operator Lifecycle Manager)이
registryPoll.interval필드를 사용하여 새 Operator 버전의 인덱스 이미지를 폴링하는 빈도를 설정합니다. y-stream 및 z-stream Operator 업데이트에 새 인덱스 이미지 태그를 항상 푸시하는 경우 이 변경 사항이 필요하지 않습니다.registryPoll.interval필드는 업데이트를 신속하게 처리하기 위해 더 짧은 간격으로 설정할 수 있지만 간격이 단축되어 계산 부하가 증가합니다. 이 문제를 방지하려면 업데이트가 완료되면registryPoll.interval을 기본값으로 복원할 수 있습니다.
이번 업데이트에서는 원하는 Operator 이미지가 포함된 새 인덱스 이미지로
redhat-operators-disconnected카탈로그 소스를 업데이트하기 위해 하나의 정책인du-upgrade-operator-catsrc-policy를 생성합니다.참고Operator에 이미지 사전 캐싱을 사용하고
redhat-operators-disconnected이외의 다른 카탈로그 소스의 Operator가 있는 경우 다음 작업을 수행해야 합니다.- 다른 카탈로그 소스에 대한 새 인덱스 이미지 또는 레지스트리 폴링 간격 업데이트를 사용하여 별도의 카탈로그 소스 정책을 준비합니다.
- 다른 카탈로그 소스의 원하는 Operator에 대해 별도의 서브스크립션 정책을 준비합니다.
예를 들어, 원하는 SRIOV-FEC Operator는
certified-operators카탈로그 소스에서 사용할 수 있습니다. 카탈로그 소스 및 Operator 서브스크립션을 업데이트하려면 다음 콘텐츠를 추가하여du-upgrade-fec-catsrc-policy및du-upgrade-subscriptions-fec-policy정책 두 가지 정책을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 공통
PolicyGenTemplateCR에서 지정된 서브스크립션 채널을 제거합니다. ZTP 이미지의 기본 서브스크립션 채널은 업데이트에 사용됩니다.참고ZTP 4.12를 통해 적용된 Operator의 기본 채널은
performance-addon-operator를 제외하고안정적입니다. OpenShift Container Platform 4.11부터performance-addon-operator기능이node-tuning-operator로 이동되었습니다. 4.10 릴리스의 경우 PAO의 기본 채널은v4.10입니다. 일반PolicyGenTemplateCR에서 기본 채널을 지정할 수도 있습니다.PolicyGenTemplateCR 업데이트를 ZTP Git 리포지토리에 내보냅니다.argocd는 Git 리포지토리에서 변경 사항을 가져와 hub 클러스터에서 정책을 생성합니다.
다음 명령을 실행하여 생성된 정책을 확인합니다.
oc get policies -A | grep -E "catsrc-policy|subscription"
$ oc get policies -A | grep -E "catsrc-policy|subscription"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 업데이트를 시작하기 전에 필요한 카탈로그 소스 업데이트를 적용합니다.
카탈로그 소스 정책과 대상 관리형 클러스터를 사용하여
operator-upgrade-prep이라는ClusterGroupUpgradeCR의 콘텐츠를cgu-operator-upgrade-prep.yml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 hub 클러스터에 정책을 적용합니다.
oc apply -f cgu-operator-upgrade-prep.yml
$ oc apply -f cgu-operator-upgrade-prep.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.
oc get policies -A | grep -E "catsrc-policy"
$ oc get policies -A | grep -E "catsrc-policy"Copy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable필드를false로 설정하여 Operator 업데이트의ClusterGroupUpgradeCR을 생성합니다.다음 예와 같이
du-upgrade-operator-catsrc-policy정책과 공통PolicyGenTemplate에서 생성된 서브스크립션 정책을 사용하여 Operator 업데이트ClusterGroupUpgradeCR의 콘텐츠를cgu-operator-upgrade.yml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고하나의
ClusterGroupUpgradeCR은ClusterGroupUpgradeCR에 포함된 하나의 카탈로그 소스에서 서브스크립션 정책에 정의된 원하는 Operator의 이미지만 사전 캐시할 수 있습니다. SRIOV-FEC Operator의 예제와 같이 다른 카탈로그 소스의 Operator가 있는 경우, SRIOV-FEC Operator 이미지에 대한du-upgrade-fec-catsrc-policy및du-upgrade-subscriptions-fec-policy정책을 사용하여 다른ClusterGroupUpgradeCR을 생성해야 합니다.다음 명령을 실행하여 hub 클러스터에
ClusterGroupUpgradeCR을 적용합니다.oc apply -f cgu-operator-upgrade.yml
$ oc apply -f cgu-operator-upgrade.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
선택 사항: Operator 업데이트의 이미지를 미리 캐시합니다.
이미지 캐싱을 시작하기 전에 다음 명령을 실행하여 서브스크립션 정책이
NonCompliant인지 확인합니다.oc get policy common-subscriptions-policy -n <policy_namespace>
$ oc get policy common-subscriptions-policy -n <policy_namespace>Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27d
NAME REMEDIATION ACTION COMPLIANCE STATE AGE common-subscriptions-policy inform NonCompliant 27dCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
ClusterGroupUpgradeCR에서 사전 캐싱을 활성화합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스를 모니터링하고 사전 캐싱이 완료될 때까지 기다립니다. 관리 클러스터에서 다음 명령을 실행하여 사전 캐싱의 상태를 확인합니다.
oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'$ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 업데이트를 시작하기 전에 사전 캐싱이 완료되었는지 확인합니다.
oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq$ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
Operator 업데이트를 시작합니다.
cgu-operator-upgradeClusterGroupUpgradeCR을 활성화하고 다음 명령을 실행하여 Operator 업데이트를 시작하도록 사전 캐싱을 비활성화합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.
oc get policies --all-namespaces
$ oc get policies --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.11.1.3.1. 최신 정책 준수 상태로 인해 누락된 Operator 업데이트 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
일부 시나리오에서는 TALM( Topology Aware Lifecycle Manager)에서 최신 정책 준수 상태로 인해 Operator 업데이트가 누락될 수 있습니다.
카탈로그 소스 업데이트 후 OLM(Operator Lifecycle Manager)에서 서브스크립션 상태를 업데이트하는 데 시간이 걸립니다. TALM에서 수정이 필요한지 여부를 결정하는 동안 서브스크립션 정책의 상태가 계속 준수로 표시될 수 있습니다. 결과적으로 서브스크립션 정책에 지정된 Operator가 업그레이드되지 않습니다.
이 시나리오를 방지하려면 PolicyGenTemplate 에 다른 카탈로그 소스 구성을 추가하고 업데이트가 필요한 Operator의 서브스크립션에 이 구성을 지정합니다.
절차
PolicyGenTemplate리소스에 카탈로그 소스 구성을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트가 필요한 Operator의 새 구성을 가리키도록
Subscription리소스를 업데이트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
PolicyGenTemplate리소스에 정의된 추가 카탈로그 소스 구성의 이름을 입력합니다.
19.11.1.4. 플랫폼 및 Operator 업데이트 함께 수행 링크 복사링크가 클립보드에 복사되었습니다!
플랫폼과 Operator 업데이트를 동시에 수행할 수 있습니다.
사전 요구 사항
- Topology Aware Lifecycle Manager (TALM)를 설치합니다.
- ZTP를 최신 버전으로 업데이트합니다.
- ZTP로 하나 이상의 관리 클러스터를 프로비저닝합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다. - hub 클러스터에서 RHACM 정책을 생성합니다.
절차
-
"플랫폼 업데이트 수행" 및 "Operator 업데이트 수행" 섹션에 설명된 단계에 따라 업데이트에 대한
PolicyGenTemplateCR을 생성합니다. 플랫폼 및 Operator 업데이트에 대한 prep 작업을 적용합니다.
플랫폼 업데이트 준비 작업, 카탈로그 소스 업데이트 및 대상 클러스터에 대한 정책을 사용하여
ClusterGroupUpgradeCR의 콘텐츠를cgu-platform-operator-upgrade-prep.yml파일에 저장합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
cgu-platform-operator-upgrade-prep.yml파일을 hub 클러스터에 적용합니다.oc apply -f cgu-platform-operator-upgrade-prep.yml
$ oc apply -f cgu-platform-operator-upgrade-prep.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.
oc get policies --all-namespaces
$ oc get policies --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow
spec.enable필드를false로 설정하여 플랫폼의ClusterGroupUpdateCR 및 Operator 업데이트를 생성합니다.다음 예와 같이 플랫폼 및 Operator 업데이트
ClusterGroupUpdateCR을 정책 및 대상 클러스터를cgu-platform-operator-upgrade.yml파일에 저장합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여
cgu-platform-operator-upgrade.yml파일을 hub 클러스터에 적용합니다.oc apply -f cgu-platform-operator-upgrade.yml
$ oc apply -f cgu-platform-operator-upgrade.ymlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
선택사항: 플랫폼 및 Operator 업데이트의 이미지를 사전 캐시합니다.
다음 명령을 실행하여
ClusterGroupUpgradeCR에서 사전 캐싱을 활성화합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"preCaching": true}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 업데이트 프로세스를 모니터링하고 사전 캐싱이 완료될 때까지 기다립니다. 관리 클러스터에서 다음 명령을 실행하여 사전 캐싱의 상태를 확인합니다.
oc get jobs,pods -n openshift-talm-pre-cache
$ oc get jobs,pods -n openshift-talm-pre-cacheCopy to Clipboard Copied! Toggle word wrap Toggle overflow 다음 명령을 실행하여 업데이트를 시작하기 전에 사전 캐싱이 완료되었는지 확인합니다.
oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'$ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow
플랫폼 및 Operator 업데이트를 시작합니다.
다음 명령을 실행하여 플랫폼 및 Operator 업데이트를 시작하려면
cgu-du-upgradeClusterGroupUpgradeCR을 활성화합니다.oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \ --patch '{"spec":{"enable":true, "preCaching": false}}' --type=mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.
oc get policies --all-namespaces
$ oc get policies --all-namespacesCopy to Clipboard Copied! Toggle word wrap Toggle overflow 참고spec.enable: true로 설정을 구성하여 플랫폼 및 Operator 업데이트의 CR을 처음부터 생성할 수 있습니다. 이 경우 사전 캐싱이 완료된 직후 업데이트가 시작되고 CR을 수동으로 활성화할 필요가 없습니다.사전 캐싱 및 업데이트 모두 정책, 배치 바인딩, 배치 규칙, 관리 클러스터 작업 및 관리형 클러스터 뷰와 같은 추가 리소스를 만들어 절차를 완료합니다.
afterCompletion.deleteObjects필드를true로 설정하면 업데이트가 완료된 후 이러한 모든 리소스가 삭제됩니다.
19.11.1.5. 배포된 클러스터에서 Performance Addon Operator 서브스크립션 제거 링크 복사링크가 클립보드에 복사되었습니다!
이전 버전의 OpenShift Container Platform에서 Performance Addon Operator는 애플리케이션에 대한 짧은 대기 시간 성능 튜닝을 제공합니다. OpenShift Container Platform 4.11 이상에서는 이러한 기능이 Node Tuning Operator의 일부입니다.
OpenShift Container Platform 4.11 이상을 실행하는 클러스터에 Performance Addon Operator를 설치하지 마십시오. OpenShift Container Platform 4.11 이상으로 업그레이드하는 경우 Node Tuning Operator가 Performance Addon Operator를 자동으로 제거합니다.
Operator 재설치를 방지하기 위해 Performance Addon Operator 서브스크립션을 생성하는 정책을 제거해야 합니다.
참조 DU 프로파일에는 PolicyGenTemplate CR common-ranGen.yaml 에 Performance Addon Operator가 포함되어 있습니다. 배포된 관리형 클러스터에서 서브스크립션을 제거하려면 common-ranGen.yaml 을 업데이트해야 합니다.
OpenShift Container Platform 4.11 이상에 Performance Addon Operator 4.10.3-5 이상을 설치하는 경우 Performance Addon Operator는 Node Tuning Operator 기능을 방해하지 않도록 클러스터 버전을 감지하고 자동으로 hibernates를 수행합니다. 그러나 최상의 성능을 얻으려면 OpenShift Container Platform 4.11 클러스터에서 Performance Addon Operator를 제거하십시오.
사전 요구 사항
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD의 소스 리포지토리로 정의해야 합니다.
- OpenShift Container Platform 4.11 이상으로 업데이트합니다.
-
cluster-admin권한이 있는 사용자로 로그인합니다.
절차
common-ranGen.yaml파일에서 Performance Addon Operator 네임스페이스, Operator group 및 서브스크립션에 대한complianceType을mustnothave로 변경합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
사용자 지정 사이트 리포지토리와 변경 사항을 병합하고 ArgoCD 애플리케이션이 hub 클러스터로 변경 사항을 동기화할 때까지 기다립니다.
common-subscriptions-policy정책의 상태가Non-Compliant로 변경됩니다. - 토폴로지 Aware Lifecycle Manager를 사용하여 대상 클러스터에 변경 사항을 적용합니다. 구성 변경 사항을 배포하는 방법에 대한 자세한 내용은 "ECDHE 리소스" 섹션을 참조하십시오.
프로세스를 모니터링합니다. 대상 클러스터의
common-subscriptions-policy정책 상태가Compliant인 경우 Performance Addon Operator가 클러스터에서 제거되었습니다. 다음 명령을 실행하여common-subscriptions-policy의 상태를 가져옵니다.oc get policy -n ztp-common common-subscriptions-policy
$ oc get policy -n ztp-common common-subscriptions-policyCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
common-ranGen.yaml파일의.spec.sourceFiles에서 Performance Addon Operator 네임스페이스, Operator group 및 서브스크립션 CR을 삭제합니다. - 사용자 지정 사이트 리포지토리와 변경 사항을 병합하고 ArgoCD 애플리케이션이 hub 클러스터로 변경 사항을 동기화할 때까지 기다립니다. 정책은 그대로 유지됩니다.
19.11.2. ZTP용 자동 생성된 ClusterGroupUpgrade CR 정보 링크 복사링크가 클립보드에 복사되었습니다!
TALM에는 hub 클러스터에서 ManagedCluster CR의 Ready 상태를 모니터링하고 ZTP에 대한 ClusterGroupUpgrade CR을 생성하는 ManagedClusterForCGU 라는 컨트롤러가 있습니다.
"ztp-done" 레이블이 적용되지 않은 Ready 상태의 관리형 클러스터의 경우 ManagedClusterForCGU 컨트롤러는 ZTP 프로세스 중에 생성된 관련 RHACM 정책과 함께 ztp-install 네임스페이스에 ClusterGroupUpgrade CR을 자동으로 생성합니다. 그런 다음 TALM은 구성 CR을 관리 클러스터로 푸시하기 위해 자동 생성된 ClusterGroupUpgrade CR에 나열된 구성 정책 세트를 수정합니다.
클러스터가 Ready 상태가 될 때 관리형 클러스터에 바인딩 정책이 없는 경우 ClusterGroupUpgrade CR이 생성되지 않습니다.
ZTP의 자동 생성 ClusterGroupUpgrade CR의 예
19.12. GitOps ZTP 업데이트 링크 복사링크가 클립보드에 복사되었습니다!
hub 클러스터, RHACM(Red Hat Advanced Cluster Management) 및 관리형 OpenShift Container Platform 클러스터와 독립적으로 Gitops zero touch provisioning(ZTP) 인프라를 업데이트할 수 있습니다.
새 버전이 사용 가능하게 되면 Red Hat OpenShift GitOps Operator를 업데이트할 수 있습니다. GitOps ZTP 플러그인을 업데이트할 때 참조 구성에서 업데이트된 파일을 검토하고 변경 사항이 요구 사항을 충족하는지 확인합니다.
19.12.1. GitOps ZTP 업데이트 프로세스 개요 링크 복사링크가 클립보드에 복사되었습니다!
이전 버전의 GitOps ZTP 인프라를 실행하는 완전 운영 허브 클러스터에 대해 GitOps 제로 전화 프로비저닝(ZTP)을 업데이트할 수 있습니다. 업데이트 프로세스에서는 관리형 클러스터에 영향을 미치지 않습니다.
권장 콘텐츠를 포함한 정책 설정 변경으로 인해 관리 클러스터에 롤아웃되고 조정되어야 하는 업데이트된 정책이 생성됩니다.
높은 수준에서 GitOps ZTP 인프라를 업데이트하는 전략은 다음과 같습니다.
-
기존 클러스터에
ztp-done레이블을 지정합니다. - ArgoCD 애플리케이션을 중지합니다.
- 새 GitOps ZTP 툴을 설치합니다.
- Git 리포지토리의 필수 콘텐츠 및 선택적 변경 사항을 업데이트합니다.
- 애플리케이션 구성을 업데이트하고 다시 시작합니다.
19.12.2. 업그레이드 준비 링크 복사링크가 클립보드에 복사되었습니다!
다음 절차에 따라 GitOps zero touch provisioning (ZTP) 업그레이드를 수행할 수 있습니다.
절차
- GitOps ZTP와 함께 사용하기 위해 Red Hat OpenShift GitOps를 구성하는 데 사용되는 CR(사용자 정의 리소스)이 있는 GitOps ZTP 컨테이너의 최신 버전을 가져옵니다.
다음 명령을 사용하여
argocd/deployment디렉터리를 추출합니다.mkdir -p ./update
$ mkdir -p ./updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./update
$ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12 extract /home/ztp --tar | tar x -C ./updateCopy to Clipboard Copied! Toggle word wrap Toggle overflow /update디렉터리에는 다음 하위 디렉터리가 있습니다.-
update/extra-manifest: siteConfigCR이 추가 매니페스트configMap을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다. -
update/source-crs:PolicyGenTemplateCR에서 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다. -
update/argocd/deployment: 이 절차의 다음 단계에서 사용할 hub 클러스터에 적용할 패치 및 YAML 파일이 포함되어 있습니다. -
update/argocd/example: 권장 구성을 나타내는siteConfig및PolicyGenTemplate파일 예제가 포함되어 있습니다.
-
애플리케이션 이름과 Git 리포지토리의 URL, 분기 및 경로를 반영하도록 cluster-app.yaml 및
policies-app.yaml파일을 업데이트합니다.업그레이드에 더 이상 사용되지 않는 정책이 생성되는 변경 사항이 포함된 경우 업그레이드를 수행하기 전에 더 이상 사용되지 않는 정책을 제거해야 합니다.
함대 사이트 CR을 관리하는
/update폴더의 구성 및 배포 소스 CR과 Git 리포지토리 간 변경 사항을 구분합니다. 필요한 변경 사항을 적용하고 사이트 리포지토리에 내보냅니다.중요GitOps ZTP를 최신 버전으로 업데이트할 때
update/argocd/deployment디렉터리의 변경 사항을 사이트 리포지토리에 적용해야 합니다. 이전 버전의argocd/deployment/파일을 사용하지 마십시오.
19.12.3. 기존 클러스터에 레이블 지정 링크 복사링크가 클립보드에 복사되었습니다!
툴 업데이트로 기존 클러스터가 변경되지 않도록 하려면 기존 관리형 클러스터에 ztp-done 라벨을 지정합니다.
이 절차는 TALM ( Topology Topology Aware Lifecycle Manager)을 사용하여 프로비저닝되지 않은 클러스터를 업데이트하는 경우에만 적용됩니다. TALM으로 프로비저닝하는 클러스터는 자동으로 ztp-done 으로 레이블이 지정됩니다.
절차
local-cluster!=true와 같이 제로 대화 프로비저닝(ZTP)으로 배포된 관리형 클러스터를 나열하는 라벨 선택기를 찾습니다.oc get managedcluster -l 'local-cluster!=true'
$ oc get managedcluster -l 'local-cluster!=true'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 결과 목록에 ZTP와 함께 배포된 모든 관리 클러스터가 포함되어 있는지 확인한 다음 해당 선택기를 사용하여
ztp-done라벨을 추가합니다.oc label managedcluster -l 'local-cluster!=true' ztp-done=
$ oc label managedcluster -l 'local-cluster!=true' ztp-done=Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.12.4. 기존 GitOps ZTP 애플리케이션 중지 링크 복사링크가 클립보드에 복사되었습니다!
기존 애플리케이션을 제거하면 새 버전의 툴을 사용할 수 있을 때까지 Git 리포지토리의 기존 콘텐츠에 대한 변경 사항이 롤아웃되지 않습니다.
배포 디렉터리의 애플리케이션 파일을 사용합니다. 애플리케이션에 사용자 지정 이름을 사용한 경우 먼저 해당 파일의 이름을 업데이트합니다.
절차
클러스터애플리케이션에서cascaded 삭제 작업을 수행하여 생성된 모든 리소스를 그대로 둡니다.oc delete -f update/argocd/deployment/clusters-app.yaml
$ oc delete -f update/argocd/deployment/clusters-app.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow policies애플리케이션에서 cascaded delete를 수행하여 이전 정책을 모두 제거합니다.oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge$ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type mergeCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc delete -f update/argocd/deployment/policies-app.yaml
$ oc delete -f update/argocd/deployment/policies-app.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.12.5. Git 리포지토리에 대한 필요한 변경 사항 링크 복사링크가 클립보드에 복사되었습니다!
이전 버전의 GitOps ZTP에서 v4.10 이상으로 ztp-site-generate 컨테이너를 업그레이드할 때 Git 리포지토리의 콘텐츠에 대한 추가 요구 사항이 있습니다. 이러한 변경 사항을 반영하려면 리포지토리의 기존 콘텐츠를 업데이트해야 합니다.
PolicyGenTemplate파일을 필요한 대로 변경합니다.모든
PolicyGenTemplate파일은ztp접두사가붙은 네임스페이스에 생성해야 합니다. 이렇게 하면 GitOps zero touch provisioning (ZTP) 애플리케이션이 GitOps ZTP(Red Hat Advanced Cluster Management)가 내부적으로 정책을 관리하는 방식과 충돌하지 않고 GitOps ZTP에서 생성한 정책 CR을 관리할 수 있습니다.kustomization.yaml파일을 리포지토리에 추가합니다.모든
SiteConfig및PolicyGenTemplateCR은 해당 디렉터리 트리의kustomization.yaml파일에 포함되어야 합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 참고생성기섹션에 나열된 파일에는SiteConfig또는PolicyGenTemplateCR만 포함되어야 합니다. 기존 YAML 파일에 다른 CR(예:네임스페이스)이 포함된 경우 이러한 기타 CR을 별도의 파일로 가져와resources섹션에 나열해야 합니다.PolicyGenTemplatekustomization 파일에는resources섹션의생성기섹션 및네임스페이스CR에 모든PolicyGenTemplateYAML 파일이 포함되어야 합니다. 예를 들면 다음과 같습니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow SiteConfigkustomization 파일에는생성기섹션 및 리소스의 다른 모든 CR에 모든SiteConfigYAML 파일이 포함되어야 합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow pre-sync.yaml및post-sync.yaml파일을 제거합니다.OpenShift Container Platform 4.10 이상에서는
pre-sync.yaml및post-sync.yaml파일이 더 이상 필요하지 않습니다.update/deployment/kustomization.yamlCR은 hub 클러스터에서 정책 배포를 관리합니다.참고site
Config및PolicyGenTemplateleaves에pre-sync.yaml및post-sync.yaml파일 세트가 있습니다.권장 변경 사항 검토 및 통합
각 릴리스에는 배포된 클러스터에 적용된 구성에 권장되는 추가 변경 사항이 포함되어 있을 수 있습니다. 일반적으로 이러한 변경으로 인해 OpenShift 플랫폼, 추가 기능 또는 플랫폼의 개선된 튜닝이 더 낮아집니다.
네트워크의 클러스터 유형에 적용할 수 있는
SiteConfig및PolicyGenTemplateCR을 검토합니다. 이러한 예는 GitOps ZTP 컨테이너에서 추출된argocd/example디렉터리에서 찾을 수 있습니다.
19.12.6. 새 GitOps ZTP 애플리케이션 설치 링크 복사링크가 클립보드에 복사되었습니다!
추출된 argocd/deployment 디렉터리를 사용하고 애플리케이션이 사이트 Git 리포지토리를 가리키는 후 배포 디렉터리의 전체 콘텐츠를 적용합니다. 디렉터리의 전체 콘텐츠를 적용하면 애플리케이션에 필요한 모든 리소스가 올바르게 구성됩니다.
절차
이전에
update/argocd/deployment/디렉터리에 추출한 패치 파일을 사용하여 hub 클러스터에 ArgoCD 인스턴스를 패치하려면 다음 명령을 입력합니다.oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file update/argocd/deployment/argocd-openshift-gitops-patch.json
$ oc patch argocd openshift-gitops \ -n openshift-gitops --type=merge \ --patch-file update/argocd/deployment/argocd-openshift-gitops-patch.jsonCopy to Clipboard Copied! Toggle word wrap Toggle overflow argocd/deployment디렉터리의 콘텐츠를 적용하려면 다음 명령을 입력합니다.oc apply -k update/argocd/deployment
$ oc apply -k update/argocd/deploymentCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.12.7. GitOps ZTP 구성 변경 사항 롤아웃 링크 복사링크가 클립보드에 복사되었습니다!
권장 변경 사항을 구현하여 업그레이드에 구성 변경이 포함된 경우 업그레이드 프로세스에서는 hub 클러스터에서 정책 CR 세트가 Non-Compliant 상태가 됩니다. ZTP GitOps v4.10 이상 ztp-site-generate 컨테이너를 사용하면 이러한 정책은 모드를 알리 도록 설정되며 사용자의 추가 단계없이 관리되는 클러스터로 푸시되지 않습니다. 이렇게 하면 유지 관리 기간 동안 변경 사항이 수행되는 경우와 동시에 업데이트되는 클러스터 수의 측면에서 클러스터 중단 변경을 관리할 수 있습니다.
변경 사항을 롤아웃하려면 TALM 문서에 설명된 대로 하나 이상의 ClusterGroupUpgrade CR을 생성합니다. CR에는 관리 클러스터로 내보내고자 하는 비준수 정책 목록과 업데이트에 포함되어야 하는 클러스터의 목록 또는 선택기가 포함되어야 합니다.
19.13. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터 확장 링크 복사링크가 클립보드에 복사되었습니다!
GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터를 확장할 수 있습니다. 단일 노드 OpenShift 클러스터에 작업자 노드를 추가하면 원래 단일 노드 OpenShift 클러스터는 컨트롤 플레인 노드 역할을 유지합니다. 작업자 노드를 추가해도 기존 단일 노드 OpenShift 클러스터에 대한 다운타임이 필요하지 않습니다.
단일 노드 OpenShift 클러스터에 추가할 수 있는 작업자 노드 수에 대한 제한은 없지만 추가 작업자 노드의 컨트롤 플레인 노드에서 예약된 CPU 할당을 다시 평가해야 합니다.
작업자 노드에 워크로드 파티셔닝이 필요한 경우 노드를 설치하기 전에 hub 클러스터에 관리형 클러스터 정책을 배포하고 수정해야 합니다. 이렇게 하면 GitOps ZTP 워크플로우에서 MachineConfig 를 작업자 노드에 적용하기 전에 워크로드 파티셔닝 머신 구성 풀과 연결되고 작업자 머신 구성 풀과 연결됩니다.
MachineConfig 오브젝트가 작업자
먼저 정책을 수정한 다음 작업자 노드를 설치하는 것이 좋습니다. 작업자 노드를 설치한 후 워크로드 파티션 매니페스트를 생성하는 경우 노드를 수동으로 드레이닝하고 데몬 세트에서 관리하는 모든 Pod를 삭제해야 합니다. 관리 데몬 세트에서 새 Pod를 생성하면 새 Pod에 워크로드 파티셔닝 프로세스가 수행됩니다.
GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드를 추가하는 것은 기술 프리뷰 기능입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
19.13.1. 작업자 노드에 프로필 적용 링크 복사링크가 클립보드에 복사되었습니다!
DU 프로필을 사용하여 추가 작업자 노드를 구성할 수 있습니다.
ZTP GitOps 공통, 그룹 및 사이트별 PolicyGenTemplate 리소스를 사용하여 작업자 노드 클러스터에 RAN 분산 장치(DU) 프로필을 적용할 수 있습니다. ArgoCD 정책 애플리케이션에 연결된 GitOps ZTP 파이프라인에는 ztp-site-generate 컨테이너를 추출할 때 out/argocd/example/policygentemplates 폴더에 있는 다음 CR이 포함되어 있습니다.
-
common-ranGen.yaml -
group-du-sno-ranGen.yaml -
example-sno-site.yaml -
ns.yaml -
kustomization.yaml
작업자 노드에서 DU 프로필을 구성하는 것은 업그레이드로 간주됩니다. 업그레이드 흐름을 시작하려면 기존 정책을 업데이트하거나 추가 정책을 생성해야 합니다. 그런 다음 클러스터 그룹의 정책을 조정하려면 ClusterGroupUpgrade CR을 생성해야 합니다.
19.13.2. (선택 사항) PTP 및 SR-IOV 데몬 선택기 호환성 강화 링크 복사링크가 클립보드에 복사되었습니다!
DU 프로필이 GitOps ZTP 플러그인 버전 4.11 또는 이전 버전을 사용하여 배포된 경우 PTP 및 SR-IOV Operator가 마스터 로 레이블이 지정된 노드에만 데몬을 배치하도록 구성할 수 있습니다. 이 구성으로 PTP 및 SR-IOV 데몬이 작업자 노드에서 작동하지 않습니다. PTP 및 SR-IOV 데몬 노드 선택기가 시스템에 잘못 구성된 경우 작업자 DU 프로필 구성을 진행하기 전에 데몬을 변경해야 합니다.
절차
설명된 클러스터 중 하나에서 PTP Operator의 데몬 노드 선택기 설정을 확인합니다.
oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq$ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow PTP Operator 출력 예
{"daemonNodeSelector":{"node-role.kubernetes.io/master":""}}{"daemonNodeSelector":{"node-role.kubernetes.io/master":""}}1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 노드 선택기가
master로 설정된 경우, 스포크는 변경이 필요한 ZTP 플러그인 버전으로 배포되었습니다.
설명된 클러스터 중 하나에서 SR-IOV Operator의 데몬 노드 선택기 설정을 확인합니다.
oc get sriovoperatorconfig/default -n \ openshift-sriov-network-operator -ojsonpath='{.spec}' | jq$ oc get sriovoperatorconfig/default -n \ openshift-sriov-network-operator -ojsonpath='{.spec}' | jqCopy to Clipboard Copied! Toggle word wrap Toggle overflow SR-IOV Operator의 출력 예
{"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true}{"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true}1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- 노드 선택기가
master로 설정된 경우, 스포크는 변경이 필요한 ZTP 플러그인 버전으로 배포되었습니다.
그룹 정책에서 다음
complianceType및spec항목을 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 중요daemonNodeSelector필드를 변경하면 임시 PTP 동기화 손실 및 SR-IOV 연결이 끊어집니다.- Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
19.13.3. PTP 및 SR-IOV 노드 선택기 호환성 링크 복사링크가 클립보드에 복사되었습니다!
PTP 구성 리소스 및 SR-IOV 네트워크 노드 정책은 node-role.kubernetes.io/master: "" 를 노드 선택기로 사용합니다. 추가 작업자 노드에 컨트롤 플레인 노드와 동일한 NIC 구성이 있는 경우 컨트롤 플레인 노드를 구성하는 데 사용되는 정책을 작업자 노드에 재사용할 수 있습니다. 그러나 "node-role.kubernetes.io/worker" 레이블과 같이 노드 유형을 둘 다 선택하도록 노드 선택기를 변경해야 합니다.
19.13.4. PolicyGenTemplate CR을 사용하여 작업자 노드에 작업자 노드 정책 적용 링크 복사링크가 클립보드에 복사되었습니다!
작업자 노드에 대한 정책을 생성할 수 있습니다.
절차
다음 정책 템플릿을 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 일반
MachineConfigCR은 작업자 노드에서 워크로드 파티셔닝을 구성하는 데 사용됩니다.crio및kubelet구성 파일의 콘텐츠를 생성할 수 있습니다.-
ArgoCD 정책 애플리케이션에서 모니터링하는 Git 리포지토리에 생성된
정책템플릿을 추가합니다. -
kustomization.yaml파일에 정책을 추가합니다. - Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
새로운 정책을 스포크 클러스터에 수정하려면 TALM 사용자 정의 리소스를 생성합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.13.5. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드 추가 링크 복사링크가 클립보드에 복사되었습니다!
기존 단일 노드 OpenShift 클러스터에 하나 이상의 작업자 노드를 추가하여 클러스터에서 사용 가능한 CPU 리소스를 늘릴 수 있습니다.
사전 요구 사항
- OpenShift Container Platform 4.11 이상 베어 메탈 허브 클러스터에서 RHACM 2.6 이상을 설치하고 구성
- 허브 클러스터에 Topology Aware Lifecycle Manager 설치
- hub 클러스터에 Red Hat OpenShift GitOps 설치
-
GitOps ZTP
ztp-site-generate컨테이너 이미지 버전 4.12 이상을 사용합니다. - GitOps ZTP를 사용하여 관리형 단일 노드 OpenShift 클러스터 배포
- RHACM 문서에 설명된 대로 중앙 인프라 관리 구성
-
내부 API 엔드포인트
api-int.<cluster_name>.<base_domain>을 확인하도록 클러스터에 DNS 서비스를 구성
절차
example-sno.yamlsiteConfig매니페스트를 사용하여 클러스터를 배포한 경우 새 작업자 노드를spec.clusters['example-sno'].nodes목록에 추가합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow site
Config파일의spec.nodes섹션에 있는bmcCredentialsName필드에서 참조하는 대로 새 호스트의 BMC 인증 시크릿을 생성합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
ArgoCD
클러스터애플리케이션이 동기화되면 ZTP 플러그인에서 생성된 hub 클러스터에 두 개의 새 매니페스트가 표시됩니다.-
BareMetalHost NMStateConfig중요worker 노드에 대해
cpuset필드를 구성해서는 안 됩니다. 노드 설치가 완료된 후 작업자 노드의 워크로드 파티션은 관리 정책을 통해 추가됩니다.
-
검증
여러 가지 방법으로 설치 프로세스를 모니터링할 수 있습니다.
다음 명령을 실행하여 사전 프로비저닝된 이미지가 생성되었는지 확인합니다.
oc get ppimg -n example-sno
$ oc get ppimg -n example-snoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAMESPACE NAME READY REASON example-sno example-sno True ImageCreated example-sno example-node2 True ImageCreated
NAMESPACE NAME READY REASON example-sno example-sno True ImageCreated example-sno example-node2 True ImageCreatedCopy to Clipboard Copied! Toggle word wrap Toggle overflow 베어 메탈 호스트의 상태를 확인합니다.
oc get bmh -n example-sno
$ oc get bmh -n example-snoCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME STATE CONSUMER ONLINE ERROR AGE example-sno provisioned true 69m example-node2 provisioning true 4m50s
NAME STATE CONSUMER ONLINE ERROR AGE example-sno provisioned true 69m example-node2 provisioning true 4m50s1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
provisioning상태는 설치 미디어에서 부팅 중인 노드가 진행 중임을 나타냅니다.
설치 프로세스를 지속적으로 모니터링합니다.
다음 명령을 실행하여 에이전트 설치 프로세스를 확인합니다.
oc get agent -n example-sno --watch
$ oc get agent -n example-sno --watchCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 작업자 노드 설치가 완료되면 작업자 노드 인증서가 자동으로 승인됩니다. 이 시점에서 작업자는
ManagedClusterInfo상태에 나타납니다. 다음 명령을 실행하여 상태를 확인합니다.oc get managedclusterinfo/example-sno -n example-sno -o \ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'$ oc get managedclusterinfo/example-sno -n example-sno -o \ jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
example-sno [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""} example-node2 [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/worker":""}example-sno [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/master":"","node-role.kubernetes.io/worker":""} example-node2 [{"status":"True","type":"Ready"}] {"node-role.kubernetes.io/worker":""}Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.14. 단일 노드 OpenShift 배포의 이미지 사전 캐싱 링크 복사링크가 클립보드에 복사되었습니다!
GitOps zero touch provisioning(ZTP) 솔루션을 사용하여 다수의 클러스터를 배포하는 데 제한된 대역폭이 있는 환경에서 OpenShift Container Platform을 부트스트랩하고 설치하는 데 필요한 모든 이미지를 다운로드하지 않으려고 합니다. 원격 단일 노드 OpenShift 사이트의 대역폭이 제한된 경우 배포 시간이 길어질 수 있습니다. construction-precaching-cli 도구를 사용하면 ZTP 프로비저닝을 위해 원격 사이트로 전송하기 전에 사전 단계를 수행할 수 있습니다.
construction-precaching-cli 도구는 다음을 수행합니다.
- 부팅하는 데 최소한의 ISO에 필요한 RHCOS rootfs 이미지를 다운로드합니다.
-
데이터로레이블이 지정된 설치 디스크에서 파티션을 생성합니다. - xfs로 디스크를 포맷합니다.
- 디스크 끝에 GUID 파티션 테이블(GPT) 데이터 파티션을 만듭니다. 여기서 파티션 크기는 도구에서 구성할 수 있습니다.
- OpenShift Container Platform을 설치하는 데 필요한 컨테이너 이미지를 복사합니다.
- ZTP에 필요한 컨테이너 이미지를 복사하여 OpenShift Container Platform을 설치합니다.
- 선택사항: 2일 차 Operator를 파티션에 복사합니다.
division-precaching-cli 툴은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
19.14.1. construction-precaching-cli 툴 받기 링크 복사링크가 클립보드에 복사되었습니다!
factory-precaching-cli 툴 Go 바이너리는 Telco RAN 툴 컨테이너 이미지에서 공개적으로 사용할 수 있습니다. 컨테이너 이미지의 bootstrap-precaching-cli 툴 Go 바이너리는 podman 을 사용하여 RHCOS 라이브 이미지를 실행하는 서버에서 실행됩니다. 연결이 끊긴 환경에서 작업 중이거나 프라이빗 레지스트리가 있는 경우 이미지를 서버에 다운로드할 수 있도록 이미지를 복사해야 합니다.
절차
다음 명령을 실행하여 builder-precaching-cli 툴 이미지를 가져옵니다.
podman pull quay.io/openshift-kni/telco-ran-tools:latest
# podman pull quay.io/openshift-kni/telco-ran-tools:latestCopy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
도구를 사용할 수 있는지 확인하려면 현재 버전의 Operating-precaching-cli 툴 Go 바이너리를 쿼리합니다.
podman run quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli -v
# podman run quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli -vCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
factory-precaching-cli version 20221018.120852+main.feecf17
factory-precaching-cli version 20221018.120852+main.feecf17Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.14.2. 라이브 운영 체제 이미지에서 부팅 링크 복사링크가 클립보드에 복사되었습니다!
하나의 디스크만 사용할 수 있고 외부 디스크 드라이브를 서버에 연결할 수 없는 부팅 서버를 함께 사용할 수 있습니다.
디스크가 RHCOS 이미지로 작성될 때 RHCOS를 사용하지 않아야 합니다.
서버 하드웨어에 따라 다음 방법 중 하나를 사용하여 빈 서버에 RHCOS 라이브 ISO를 마운트할 수 있습니다.
- Dell 서버에서 Dell RACADM 툴 사용.
- HP 서버에서 HPONCFG 툴 사용.
- Redfish BMC API 사용.
마운트 절차를 자동화하는 것이 좋습니다. 절차를 자동화하려면 필요한 이미지를 가져와서 로컬 HTTP 서버에서 호스팅해야 합니다.
사전 요구 사항
- 호스트의 전원을 높였습니다.
- 호스트에 대한 네트워크 연결이 있어야 합니다.
이 예제 절차에서는 Redfish BMC API를 사용하여 RHCOS 라이브 ISO를 마운트합니다.
RHCOS 라이브 ISO를 마운트합니다.
가상 미디어 상태를 확인합니다.
curl --globoff -H "Content-Type: application/json" -H \ "Accept: application/json" -k -X GET --user ${username_password} \ https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1 | python -m json.tool$ curl --globoff -H "Content-Type: application/json" -H \ "Accept: application/json" -k -X GET --user ${username_password} \ https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1 | python -m json.toolCopy to Clipboard Copied! Toggle word wrap Toggle overflow ISO 파일을 가상 미디어로 마운트합니다.
curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Image": "http://[$HTTPd_IP]/RHCOS-live.iso"}' -X POST https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1/Actions/VirtualMedia.InsertMedia$ curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Image": "http://[$HTTPd_IP]/RHCOS-live.iso"}' -X POST https://$BMC_ADDRESS/redfish/v1/Managers/Self/VirtualMedia/1/Actions/VirtualMedia.InsertMediaCopy to Clipboard Copied! Toggle word wrap Toggle overflow 가상 미디어에서 부팅하도록 부팅 순서를 설정합니다.
curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Boot":{ "BootSourceOverrideEnabled": "Once", "BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI"}}' -X PATCH https://$BMC_ADDRESS/redfish/v1/Systems/Self$ curl --globoff -L -w "%{http_code} %{url_effective}\\n" -ku ${username_password} -H "Content-Type: application/json" -H "Accept: application/json" -d '{"Boot":{ "BootSourceOverrideEnabled": "Once", "BootSourceOverrideTarget": "Cd", "BootSourceOverrideMode": "UEFI"}}' -X PATCH https://$BMC_ADDRESS/redfish/v1/Systems/SelfCopy to Clipboard Copied! Toggle word wrap Toggle overflow
- 서버가 가상 미디어에서 부팅되고 있는지 확인합니다.
19.14.3. 디스크 파티션 설정 링크 복사링크가 클립보드에 복사되었습니다!
전체 사전 캐싱 프로세스를 실행하려면 라이브 ISO에서 부팅하고 컨테이너 이미지에서 loading-precaching-cli 툴을 사용하여 필요한 모든 아티팩트를 파티션하고 캐시해야 합니다.
운영 체제(RHCOS)가 프로비저닝 중 장치에 기록될 때 디스크를 사용하지 않아야 하므로 라이브 ISO 또는 RHCOS 라이브 ISO가 필요합니다. 이 절차를 통해 단일 디스크 서버를 활성화할 수도 있습니다.
사전 요구 사항
- 분할되지 않은 디스크가 있습니다.
-
quay.io/openshift-kni/telco-ran-tools:latest이미지에 액세스할 수 있습니다. - OpenShift Container Platform을 설치하고 필요한 이미지를 사전 캐시할 수 있는 충분한 스토리지가 있습니다.
절차
디스크가 지워졌는지 확인합니다.
lsblk
# lsblkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 93.8G 0 loop /run/ephemeral loop1 7:1 0 897.3M 1 loop /sysroot sr0 11:0 1 999M 0 rom /run/media/iso nvme0n1 259:1 0 1.5T 0 disk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 93.8G 0 loop /run/ephemeral loop1 7:1 0 897.3M 1 loop /sysroot sr0 11:0 1 999M 0 rom /run/media/iso nvme0n1 259:1 0 1.5T 0 diskCopy to Clipboard Copied! Toggle word wrap Toggle overflow 장치에서 모든 파일 시스템, RAID 또는 파티션 테이블 서명이 만료됩니다.
wipefs -a /dev/nvme0n1
# wipefs -a /dev/nvme0n1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
/dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 8 bytes were erased at offset 0x1749a955e00 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa
/dev/nvme0n1: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 8 bytes were erased at offset 0x1749a955e00 (gpt): 45 46 49 20 50 41 52 54 /dev/nvme0n1: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aaCopy to Clipboard Copied! Toggle word wrap Toggle overflow
아티팩트 사전 캐싱을 위해 장치의 파티션 번호 1을 사용하므로 디스크가 비어 있지 않은 경우 툴이 실패합니다.
19.14.3.1. 파티션 생성 링크 복사링크가 클립보드에 복사되었습니다!
장치가 준비되면 단일 파티션과 GPT 파티션 테이블을 만듭니다. 파티션에 자동으로 데이터 레이블이 지정되고 장치 끝에 생성됩니다. 그렇지 않으면 coreos-installer 에 의해 파티션이 재정의됩니다.
coreos-installer 는 장치 끝에 파티션을 생성하고 데이터로 레이블이 지정되어야 합니다. RHCOS 이미지를 디스크에 쓸 때 파티션을 저장하려면 두 가지 요구 사항이 모두 필요합니다.
사전 요구 사항
-
컨테이너는 호스트 장치
포맷으로인해 권한으로 실행되어야 합니다. -
컨테이너 내부에서 프로세스를 실행할 수 있도록
/dev폴더를 마운트해야 합니다.
절차
다음 예에서 2일 Operator의 DU 프로필을 사전 캐싱할 수 있기 때문에 파티션 크기는 250GiB입니다.
권한으로 컨테이너를 실행하고 디스크를 분할합니다.
podman run -v /dev:/dev --privileged \ --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli partition \ -d /dev/nvme0n1 \ -s 250
# podman run -v /dev:/dev --privileged \ --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli partition \1 -d /dev/nvme0n1 \2 -s 2503 Copy to Clipboard Copied! Toggle word wrap Toggle overflow 스토리지 정보를 확인합니다.
lsblk
# lsblkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
다음 요구 사항이 충족되었는지 확인해야 합니다.
- 장치에 GPT 파티션 테이블이 있습니다.
- 파티션은 장치의 최신 섹터를 사용합니다.
-
파티션의 레이블이
data로 올바르게 지정됩니다.
디스크 상태를 쿼리하여 디스크가 예상대로 분할되었는지 확인합니다.
gdisk -l /dev/nvme0n1
# gdisk -l /dev/nvme0n1
출력 예
19.14.3.2. 파티션 마운트 링크 복사링크가 클립보드에 복사되었습니다!
디스크가 올바르게 분할되었는지 확인한 후 장치를 /mnt 에 마운트할 수 있습니다.
ZTP 준비 중에 해당 마운트 지점이 사용되므로 장치를 /mnt 에 마운트하는 것이 좋습니다.
파티션이
xfs로 포맷되었는지 확인합니다.lsblk -f /dev/nvme0n1
# lsblk -f /dev/nvme0n1Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 └─nvme0n1p1 xfs 1bee8ea4-d6cf-4339-b690-a76594794071
NAME FSTYPE LABEL UUID MOUNTPOINT nvme0n1 └─nvme0n1p1 xfs 1bee8ea4-d6cf-4339-b690-a76594794071Copy to Clipboard Copied! Toggle word wrap Toggle overflow 파티션을 마운트합니다.
mount /dev/nvme0n1p1 /mnt/
# mount /dev/nvme0n1p1 /mnt/Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
파티션이 마운트되었는지 확인합니다.
lsblk
# lsblkCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- RHCOS의
/mnt폴더는/var/mnt에 대한 링크이므로 마운트 지점은/var/mnt입니다.
19.14.4. 이미지 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
division-precaching-cli 도구를 사용하면 다음과 같은 이미지를 분할된 서버로 다운로드할 수 있습니다.
- OpenShift Container Platform 이미지
- 5G RAN 사이트의 DU(Distributed Unit) 프로필에 포함된 Operator 이미지
- 연결이 끊긴 레지스트리의 Operator 이미지
사용 가능한 Operator 이미지 목록은 OpenShift Container Platform 릴리스마다 다를 수 있습니다.
19.14.4.1. 병렬 작업자로 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
division-precaching-cli 툴은 병렬 작업자를 사용하여 여러 이미지를 동시에 다운로드합니다. --parallel 또는 -p 옵션을 사용하여 작업자 수를 구성할 수 있습니다. 기본값은 서버 사용 가능한 CPU의 80%로 설정됩니다.
로그인 쉘은 CPU의 하위 집합으로 제한될 수 있으므로 컨테이너에서 사용 가능한 CPU가 줄어듭니다. 이 제한을 제거하려면 명령 앞에 0xffffffff의 작업 보다 우선합니다. 예를 들면 다음과 같습니다.
taskset 0xffffffff podman run --rm quay.io/openshift-kni/telco-ran-tools:latest factory-precaching-cli download --help
# taskset 0xffffffff podman run --rm quay.io/openshift-kni/telco-ran-tools:latest factory-precaching-cli download --help
19.14.4.2. OpenShift Container Platform 이미지 다운로드 준비 링크 복사링크가 클립보드에 복사되었습니다!
OpenShift Container Platform 컨테이너 이미지를 다운로드하려면 다중 클러스터 엔진 버전을 알아야 합니다. --du-profile 플래그를 사용하는 경우 단일 노드 OpenShift를 프로비저닝할 hub 클러스터에서 실행되는 RHACM(Red Hat Advanced Cluster Management) 버전도 지정해야 합니다.
사전 요구 사항
- RHACM 및 다중 클러스터 엔진 Operator가 설치되어 있어야 합니다.
- 스토리지 장치를 분할했습니다.
- 분할된 장치에 이미지에 충분한 공간이 있습니다.
- 베어 메탈 서버를 인터넷에 연결하셨습니다.
- 유효한 풀 시크릿이 있습니다.
절차
hub 클러스터에서 다음 명령을 실행하여 RHACM 버전과 다중 클러스터 엔진 버전을 확인합니다.
oc get csv -A | grep -i advanced-cluster-management
$ oc get csv -A | grep -i advanced-cluster-managementCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
open-cluster-management advanced-cluster-management.v2.6.3 Advanced Cluster Management for Kubernetes 2.6.3 advanced-cluster-management.v2.6.3 Succeeded
open-cluster-management advanced-cluster-management.v2.6.3 Advanced Cluster Management for Kubernetes 2.6.3 advanced-cluster-management.v2.6.3 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow oc get csv -A | grep -i multicluster-engine
$ oc get csv -A | grep -i multicluster-engineCopy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
multicluster-engine cluster-group-upgrades-operator.v0.0.3 cluster-group-upgrades-operator 0.0.3 Pending multicluster-engine multicluster-engine.v2.1.4 multicluster engine for Kubernetes 2.1.4 multicluster-engine.v2.0.3 Succeeded multicluster-engine openshift-gitops-operator.v1.5.7 Red Hat OpenShift GitOps 1.5.7 openshift-gitops-operator.v1.5.6-0.1664915551.p Succeeded multicluster-engine openshift-pipelines-operator-rh.v1.6.4 Red Hat OpenShift Pipelines 1.6.4 openshift-pipelines-operator-rh.v1.6.3 Succeeded
multicluster-engine cluster-group-upgrades-operator.v0.0.3 cluster-group-upgrades-operator 0.0.3 Pending multicluster-engine multicluster-engine.v2.1.4 multicluster engine for Kubernetes 2.1.4 multicluster-engine.v2.0.3 Succeeded multicluster-engine openshift-gitops-operator.v1.5.7 Red Hat OpenShift GitOps 1.5.7 openshift-gitops-operator.v1.5.6-0.1664915551.p Succeeded multicluster-engine openshift-pipelines-operator-rh.v1.6.4 Red Hat OpenShift Pipelines 1.6.4 openshift-pipelines-operator-rh.v1.6.3 SucceededCopy to Clipboard Copied! Toggle word wrap Toggle overflow 컨테이너 레지스트리에 액세스하려면 설치할 서버에 유효한 풀 시크릿을 복사합니다.
.docker폴더를 생성합니다.mkdir /root/.docker
$ mkdir /root/.dockerCopy to Clipboard Copied! Toggle word wrap Toggle overflow config.json파일에 유효한 가져오기를 이전에 생성한.docker/폴더에 복사합니다.cp config.json /root/.docker/config.json
$ cp config.json /root/.docker/config.json1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/root/.docker/config.json은podman이 레지스트리의 로그인 자격 증명을 확인하는 기본 경로입니다.
다른 레지스트리를 사용하여 필요한 아티팩트를 가져오는 경우 적절한 풀 시크릿을 복사해야 합니다. 로컬 레지스트리가 TLS를 사용하는 경우 레지스트리의 인증서도 포함해야 합니다.
19.14.4.3. OpenShift Container Platform 이미지 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
seamless-precaching-cli 툴을 사용하면 특정 OpenShift Container Platform 릴리스를 프로비저닝하는 데 필요한 모든 컨테이너 이미지를 사전 캐시할 수 있습니다.
절차
다음 명령을 실행하여 릴리스를 사전 캐시합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
검증
모든 이미지가 서버의 대상 폴더에 압축되어 있는지 확인합니다.
ls -l /mnt
$ ls -l /mnt1 Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
/mnt폴더의 이미지를 사전 캐시하는 것이 좋습니다.
출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.14.4.4. Operator 이미지 다운로드 링크 복사링크가 클립보드에 복사되었습니다!
5G DU(Radio Access Network) DC(Distributed Unit) 클러스터 구성에서 사용되는 Day-2 Operator를 사전 캐시할 수도 있습니다. Day-2 Operator는 설치된 OpenShift Container Platform 버전에 따라 다릅니다.
--acm-version 및 --mce-version 플래그를 사용하여 RHACM 허브 및 다중 클러스터 엔진 Operator 버전을 포함해야 합니다. 따라서 factory-precaching-cli 툴이 RHACM 및 다중 클러스터 엔진 Operator에 적합한 컨테이너 이미지를 사전 캐시할 수 있습니다.
절차
Operator 이미지를 미리 캐시합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 출력 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
19.14.4.5. 연결이 끊긴 환경에서 사용자 정의 이미지 사전 캐싱 링크 복사링크가 클립보드에 복사되었습니다!
--generate-imageset 인수는 ImageSetConfiguration CR(사용자 정의 리소스)이 생성된 후 production-precaching-cli 툴을 중지합니다. 이렇게 하면 이미지를 다운로드하기 전에 ImageSetConfiguration CR을 사용자 지정할 수 있습니다. CR을 사용자 지정한 후 --skip-imageset 인수를 사용하여 ImageSetConfiguration CR에 지정한 이미지를 다운로드할 수 있습니다.
다음과 같은 방법으로 ImageSetConfiguration CR을 사용자 지정할 수 있습니다.
- Operator 및 추가 이미지 추가
- Operator 및 추가 이미지 제거
- Operator 및 카탈로그 소스를 로컬 또는 연결이 끊긴 레지스트리로 변경
절차
이미지를 미리 캐시합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- loading-precaching-cli 툴의 다운로드 기능을 지정합니다.
- 2
- OpenShift Container Platform 릴리스 버전을 정의합니다.
- 3
- RHACM 버전을 정의합니다.
- 4
- 다중 클러스터 엔진 버전을 정의합니다.
- 5
- 디스크의 이미지를 다운로드하려는 폴더를 정의합니다.
- 6
- 선택 사항: 추가 이미지를 저장할 리포지토리를 정의합니다. 이러한 이미지는 다운로드되어 디스크에 사전 캐시됩니다.
- 7
- DU 구성에 포함된 Operator 사전 캐싱을 지정합니다.
- 8
--generate-imageset인수는 CR을 사용자 지정할 수 있는ImageSetConfigurationCR만 생성합니다.
출력 예
Generated /mnt/imageset.yaml
Generated /mnt/imageset.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ImageSetConfiguration CR의 예
Copy to Clipboard Copied! Toggle word wrap Toggle overflow CR에서 카탈로그 리소스를 사용자 지정합니다.
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 로컬 또는 연결이 끊긴 레지스트리를 사용하여 이미지를 다운로드하는 경우 먼저 콘텐츠를 가져오려는 레지스트리의 인증서를 추가해야 합니다.
오류를 방지하려면 레지스트리 인증서를 서버에 복사합니다.
cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
# cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 그런 다음 인증서 신뢰 저장소를 업데이트합니다.
update-ca-trust
# update-ca-trustCopy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트
/etc/pki폴더를 production-cli 이미지에 마운트합니다.Copy to Clipboard Copied! Toggle word wrap Toggle overflow - 1
- loading-precaching-cli 툴의 다운로드 기능을 지정합니다.
- 2
- OpenShift Container Platform 릴리스 버전을 정의합니다.
- 3
- RHACM 버전을 정의합니다.
- 4
- 다중 클러스터 엔진 버전을 정의합니다.
- 5
- 디스크의 이미지를 다운로드하려는 폴더를 정의합니다.
- 6
- 선택 사항: 추가 이미지를 저장할 리포지토리를 정의합니다. 이러한 이미지는 다운로드되어 디스크에 사전 캐시됩니다.
- 7
- DU 구성에 포함된 Operator 사전 캐싱을 지정합니다.
- 8
--skip-imageset인수를 사용하면 사용자 지정된ImageSetConfigurationCR에서 지정한 이미지를 다운로드할 수 있습니다.
새
imageSetConfigurationCR을 생성하지 않고 이미지를 다운로드합니다.podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli download -r 4.12.0 \ --acm-version 2.6.3 --mce-version 2.1.4 -f /mnt \ --img quay.io/custom/repository \ --du-profile -s \ --skip-imageset
# podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli download -r 4.12.0 \ --acm-version 2.6.3 --mce-version 2.1.4 -f /mnt \ --img quay.io/custom/repository \ --du-profile -s \ --skip-imagesetCopy to Clipboard Copied! Toggle word wrap Toggle overflow
19.14.5. ZTP의 사전 캐싱 이미지 링크 복사링크가 클립보드에 복사되었습니다!
site Config 매니페스트는 OpenShift 클러스터를 설치 및 구성하는 방법을 정의합니다. ZTP 프로비저닝 워크플로에서 loading-precaching-cli 툴에는 site Config 매니페스트의 다음과 같은 추가 필드가 필요합니다.
-
clusters.ignitionConfigOverride -
nodes.installerArgs -
nodes.ignitionConfigOverride
추가 필드가 있는 siteConfig 예
19.14.5.1. cluster.ignitionConfigOverride 필드 이해 링크 복사링크가 클립보드에 복사되었습니다!
cluster .ignitionConfigOverride 필드는 ZTP 검색 단계에서 Ignition 형식의 설정을 추가합니다. 구성에는 가상 미디어에 마운트된 ISO에 systemd 서비스가 포함됩니다. 이렇게 하면 스크립트가 검색 RHCOS 라이브 ISO의 일부이며, Assisted Installer(AI) 이미지를 로드하는 데 사용할 수 있습니다.
systemd서비스-
systemd서비스는var-mnt.mount및precache-images.services입니다.precache-images.service는var-mnt.mount단위로/var/mnt에 마운트할 디스크 파티션에 따라 다릅니다. 서비스는extract-ai.sh라는 스크립트를 호출합니다. extract-ai.sh-
extract-ai.sh스크립트는 디스크 파티션에서 로컬 컨테이너 스토리지로 필요한 이미지를 추출하고 로드합니다. 스크립트가 완료되면 이미지를 로컬에서 사용할 수 있습니다. agent-fix-bz1964591-
agent-fix-bz1964591스크립트는 AI 문제에 대한 해결 방법입니다. AI가 이미지를 제거하지 못하도록agent.service가 레지스트리에서 이미지를 다시 가져오도록 하려면agent-fix-bz1964591스크립트에서 요청된 컨테이너 이미지가 존재하는지 확인합니다.
19.14.5.2. nodes.installerArgs 필드 이해 링크 복사링크가 클립보드에 복사되었습니다!
nodes.installerArgs 필드를 사용하면 coreos-installer 유틸리티에서 RHCOS 라이브 ISO를 디스크에 쓰는 방법을 구성할 수 있습니다. OpenShift Container Platform 설치 단계에서 데이터 파티션에 저장된 아티팩트가 필요하므로 데이터로 레이블이 지정된 디스크 파티션을 저장하도록 지정해야 합니다.
추가 매개변수는 라이브 RHCOS를 디스크에 쓰는 coreos-installer 유틸리티로 직접 전달됩니다. 다음 재부팅 시 운영 체제는 디스크에서 시작됩니다.
coreos-installer 유틸리티에 여러 옵션을 전달할 수 있습니다.
19.14.5.3. nodes.ignitionConfigOverride 필드 이해 링크 복사링크가 클립보드에 복사되었습니다!
cluster .ignitionConfigOverride 와 유사하게 nodes.ignitionConfigOverride 필드를 사용하면 coreos-installer 유틸리티에 Ignition 형식의 구성을 추가할 수 있지만 OpenShift Container Platform 설치 단계에서 RHCOS가 디스크에 작성되면 ZTP 검색 ISO에 포함된 추가 구성을 더 이상 사용할 수 없습니다. 검색 단계에서 추가 구성이 라이브 OS의 메모리에 저장됩니다.
이 단계에서 추출 및 로드된 컨테이너 이미지 수는 검색 단계보다 많습니다. OpenShift Container Platform 릴리스 및 Day-2 Operator 설치 여부에 따라 설치 시간이 다를 수 있습니다.
설치 단계에서 var-mnt.mount 및 precache-ocp.services systemd 서비스가 사용됩니다.
precache-ocp.serviceprecache-ocp.service는var-mnt.mount단위로/var/mnt에 마운트할 디스크 파티션에 따라 다릅니다.precache-ocp.service서비스는extract-ocp.sh이라는 스크립트를 호출합니다.중요OpenShift Container Platform 설치 전에 모든 이미지를 추출하려면
machine-config-daemon-pull.service및nodeip-configuration.service서비스를 실행하기 전에precache-ocp.service를 실행해야 합니다.extract-ocp.sh-
extract-ocp.sh스크립트는 디스크 파티션에서 로컬 컨테이너 스토리지로 필요한 이미지를 추출하고 로드합니다. 스크립트가 완료되면 이미지를 로컬에서 사용할 수 있습니다.
site Config 및 선택적 PolicyGenTemplates 사용자 정의 리소스(CR)를 Git 리포지토리에 업로드할 때 Argo CD가 모니터링되는 Git 리포지토리에, hub 클러스터와 CR을 동기화하여 ZTP 워크플로를 시작할 수 있습니다.
19.14.6. 문제 해결 링크 복사링크가 클립보드에 복사되었습니다!
19.14.6.1. 렌더링된 카탈로그가 잘못됨 링크 복사링크가 클립보드에 복사되었습니다!
로컬 또는 연결이 끊긴 레지스트리를 사용하여 이미지를 다운로드하면 렌더링된 카탈로그가 유효하지 않은 것으로 표시될 수 있습니다. 즉, 콘텐츠를 가져올 새 레지스트리의 인증서가 누락되어 있습니다.
history-precaching-cli 툴 이미지는 UBI RHEL 이미지를 기반으로 빌드됩니다. 인증서 경로와 위치는 RHCOS에서 동일합니다.
오류 예
절차
레지스트리 인증서를 서버에 복사합니다.
cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
# cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.Copy to Clipboard Copied! Toggle word wrap Toggle overflow 인증서 신뢰 저장소를 업데이트합니다.
update-ca-trust
# update-ca-trustCopy to Clipboard Copied! Toggle word wrap Toggle overflow 호스트
/etc/pki폴더를 production-cli 이미지에 마운트합니다.podman run -v /mnt:/mnt -v /root/.docker:/root/.docker -v /etc/pki:/etc/pki --privileged -it --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli download -r 4.11.5 --acm-version 2.5.4 \ --mce-version 2.0.4 -f /mnt \--img quay.io/custom/repository
# podman run -v /mnt:/mnt -v /root/.docker:/root/.docker -v /etc/pki:/etc/pki --privileged -it --rm quay.io/openshift-kni/telco-ran-tools:latest -- \ factory-precaching-cli download -r 4.11.5 --acm-version 2.5.4 \ --mce-version 2.0.4 -f /mnt \--img quay.io/custom/repository --du-profile -s --skip-imagesetCopy 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.