확장 및 성능


OpenShift Container Platform 4.14

프로덕션 환경에서 OpenShift Container Platform 클러스터 스케일링 및 성능 튜닝

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform 환경의 클러스터를 스케일링하고 성능을 최적화하는 방법을 설명합니다.

1장. OpenShift Container Platform 확장성 및 성능 개요

OpenShift Container Platform은 클러스터의 성능 및 규모를 최적화하는 데 도움이 되는 모범 사례와 툴을 제공합니다. 다음 문서에서는 권장 성능 및 확장성 사례, 참조 설계 사양, 최적화 및 짧은 대기 시간 튜닝에 대한 정보를 제공합니다.

Red Hat 지원에 문의하려면 지원 받기를 참조하십시오.

참고

일부 성능 및 확장성 Operator에는 OpenShift Container Platform 릴리스 사이클과 독립적인 릴리스 사이클이 있습니다. 자세한 내용은 Openshift Operator 를 참조하십시오.

컨트롤 플레인 권장 사례

인프라 관련 권장 사례

etcd 관련 권장 사례

Telco 참조 설계 사양

Telco RAN DU 사양

계획, 최적화 및 측정

오브젝트 최대값에 따른 환경 계획

IBM Z 및 IBM LinuxONE에 대한 권장 사례

Node Tuning Operator 사용

CPU 관리자 및 토폴로지 관리자 사용

NUMA 인식 워크로드 예약

스토리지, 라우팅, 네트워킹 및 CPU 사용량 최적화

베어 메탈 호스트 및 이벤트 관리

대규모 페이지란 무엇이며 앱에서 사용하는 방법

클러스터 안정성 및 파티셔닝 워크로드를 개선하기 위한 짧은 대기 시간 튜닝

작업자 대기 시간 프로필을 사용하여 대기 시간이 많은 환경에서 클러스터 안정성 개선

워크로드 파티셔닝

Node Observability Operator 사용

3장. 참조 설계 사양

3.1. Telco core 및 RAN DU 참조 설계 사양

Telco 코어 참조 설계 사양(RDS)은 컨트롤 플레인 및 일부 중앙 집중식 데이터 플레인 기능을 포함하여 대규모 통신 애플리케이션을 지원할 수 있는 상용 하드웨어에서 실행되는 OpenShift Container Platform 4.14 클러스터를 설명합니다.

Telco RAN RDS는 RAN(Radio Access Network)에서 5G 워크로드를 호스팅하기 위해 상용 하드웨어에서 실행되는 클러스터의 구성을 설명합니다.

3.1.1. 통신 5G 배포를 위한 참조 설계 사양

Red Hat 및 인증된 파트너는 OpenShift Container Platform 4.14 클러스터에서 telco 애플리케이션을 실행하는 데 필요한 네트워킹 및 운영 기능에 대한 깊은 기술 전문 지식 및 지원을 제공합니다.

Red Hat의 통신 파트너는 엔터프라이즈 5G 솔루션을 위해 대규모로 복제할 수 있는 잘 통합되고 테스트되고 안정적인 환경이 필요합니다. Telco 코어 및 RAN DU 참조 설계 사양(RDS)은 특정 OpenShift Container Platform 버전을 기반으로 하는 권장 솔루션 아키텍처를 간략하게 설명합니다. 각 RDS는 telco 코어 및 RAN DU 모델을 사용하기 위한 테스트되고 검증된 플랫폼 구성을 설명합니다. RDS는 통신 5G 코어 및 RAN DU에 대한 중요한 KPI 세트를 정의하여 애플리케이션을 실행할 때 최적의 환경을 보장합니다. RDS는 높은 심각도의 에스컬레이션을 최소화하고 애플리케이션 안정성을 향상시킵니다.

5G 사용 사례는 계속 증가하고 있으며 워크로드는 지속적으로 변하고 있습니다. Red Hat은 telco 코어 및 RAN DU RDS를 통해 고객 및 파트너 피드백을 기반으로 진화하는 요구 사항을 지원하기 위해 최선을 다하고 있습니다.

3.1.2. 참조 설계 범위

Telco core 및 telco RAN 참조 설계 사양(RDS)은 권장, 테스트 및 지원되는 구성을 캡처하여 Telco core 및 telco RAN 프로필을 실행하는 클러스터에 대해 안정적이고 반복 가능한 성능을 제공합니다.

각 RDS에는 클러스터가 개별 프로필을 실행할 수 있도록 설계 및 검증되는 릴리스된 기능 및 지원되는 구성이 포함되어 있습니다. 이 구성은 기능 및 KPI 대상을 충족하는 기본 OpenShift Container Platform 설치를 제공합니다. 각 RDS는 개별 구성에 대해 예상되는 변형도 설명합니다. 각 RDS의 검증에는 긴 기간과 대규모 테스트가 포함되어 있습니다.

참고

검증된 참조 구성은 OpenShift Container Platform의 각 주요 Y-stream 릴리스에 대해 업데이트됩니다. Z-stream 패치 릴리스는 참조 구성에 대해 주기적으로 다시 테스트됩니다.

3.1.3. 참조 설계의 편차

검증된 Telco 코어 및 telco RAN DU 참조 설계 사양(RDS)을 벗어나면 변경되는 특정 구성 요소 또는 기능 이외의 중요한 영향을 미칠 수 있습니다. 편차는 전체 솔루션의 맥락에서 분석 및 엔지니어링이 필요합니다.

중요

RDS의 모든 편차는 명확한 작업 추적 정보로 분석 및 문서화되어야 합니다. 실사실은 파트너로부터 참조 설계에 맞춰 편차를 가져오는 방법을 이해할 것으로 예상됩니다. 이를 위해서는 파트너사가 Red Hat과 협력하여 플랫폼에서 최상의 결과를 얻을 수 있도록 활용 사례를 제공하기 위해 추가 리소스를 제공해야 할 수 있습니다. 이는 솔루션의 지원 가능성과 Red Hat 및 파트너 간의 조정을 보장하는 데 매우 중요합니다.

RDS의 편차는 다음과 같은 결과 중 일부 또는 모두를 가질 수 있습니다.

  • 문제를 해결하는 데 시간이 더 걸릴 수 있습니다.
  • 프로젝트 서비스 수준 계약(SLA), 프로젝트 기한, 최종 공급자 성능 요구 사항이 누락될 위험이 있습니다.
  • 승인되지 않은 편차는 행정 수준에서 에스컬레이션이 필요할 수 있습니다.

    참고

    Red Hat은 파트너 참여 우선 순위에 따라 편차 요청의 우선 순위를 지정합니다.

3.2. Telco RAN DU 참조 설계 사양

3.2.1. Telco RAN DU 4.14 참조 설계 개요

Telco RAN distributed unit (DU) 4.14 참조 설계는 상용 하드웨어에서 실행되는 OpenShift Container Platform 4.14 클러스터를 구성하여 Telco RAN DU 워크로드를 호스팅합니다. Telco RAN DU 프로필을 실행하는 클러스터에 대해 안정적이고 반복 가능한 성능을 얻기 위해 권장, 테스트 및 지원되는 구성을 캡처합니다.

3.2.1.1. telco RAN DU를 위한 OpenShift Container Platform 4.14 기능

OpenShift Container Platform 4.14에 포함되어 있고 telco RAN DU DU 참조 설계 사양(RDS)에 의해 활용되는 다음 기능이 추가되거나 업데이트되었습니다.

표 3.1. telco RAN DU RDS를 위한 OpenShift Container Platform 4.14 기능
기능설명

관리 클러스터 버전과의 GitOps ZTP 독립성

GitOps ZTP를 사용하여 hub 클러스터에서 실행 중인 버전과 비교하여 다른 버전의 OpenShift Container Platform을 실행하는 클러스터를 관리할 수 있습니다. 배포된 클러스터에 OpenShift Container Platform 버전이 혼합되어 있을 수도 있습니다.

GitOps ZTP의 참조 CR과 함께 사용자 정의 CR 사용

이제 ztp-site-generate 컨테이너에 제공된 참조 구성 CR과 함께 사용자 정의 CR을 사용할 수 있습니다.

GitOps ZTP를 사용하여 SiteConfig CR에서 사용자 정의 노드 레이블 사용

이제 SiteConfig CR의 nodeLabels 필드를 사용하여 관리 클러스터에서 노드에 대한 사용자 지정 역할을 생성할 수 있습니다.

Intel Westport Channel e810 NIC as PTP Grandmaster clock (기술 프리뷰)

Intel Westport Channel E810-XXVDA4T를 GNSS 소싱된 마스터 클록으로 사용할 수 있습니다. NIC는 E810 하드웨어 플러그인을 사용하여 PTP Operator에 의해 자동으로 구성됩니다.

PTP Operator 하드웨어 특정 기능 플러그인 (기술 프리뷰)

PTP Operator에서 새로운 E810 NIC 하드웨어 플러그인을 사용할 수 있습니다. E810 플러그인을 사용하여 NIC를 직접 구성할 수 있습니다.

PTP 이벤트 및 메트릭

PtpConfig 참조 구성 CR이 업데이트되었습니다.

사용자 지정 이미지 Precaching user-specified images

토폴로지 Aware Lifecycle Manager를 사용하여 단일 노드 OpenShift 클러스터에서 애플리케이션을 업그레이드하기 전에 애플리케이션 워크로드 이미지를 사전 캐시할 수 있습니다.

OpenShift 기능을 사용하여 단일 노드 OpenShift DU 풋프린트 감소

클러스터를 설치하기 전에 선택적 구성 요소를 활성화하거나 비활성화하려면 클러스터 기능을 사용합니다. OpenShift Container Platform 4.14에서는 다음과 같은 선택적 기능을 사용할 수 있습니다. image-registry,baremetal,marketplace,openshift-samples,Console,Insights,Storage,CSISnapshot,NodeTuning,MachineAPI. 참조 구성에는 RAN DU에 필요한 기능만 포함됩니다.

DU 프로필에서 기본 로그 수집기로 vectord 설정

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 로깅 및 로그 전달이 필요합니다.

3.2.1.2. 배포 아키텍처 개요

중앙 집중식 관리형 RHACM 허브 클러스터에서 관리되는 클러스터에 telco RAN DU 4.14 참조 구성을 배포합니다. 참조 설계 사양(RDS)에는 관리 클러스터 및 허브 클러스터 구성 요소가 포함되어 있습니다.

그림 3.1. Telco RAN DU 배포 아키텍처 개요

두 개의 별도의 네트워크 간 에지 배포 프로세스를 보여주는 다이어그램

3.2.2. Ttelco RAN DU 사용 모델 개요

다음 정보를 사용하여 허브 클러스터 및 관리형 단일 노드 OpenShift 클러스터에 대한 통신 RAN DU 워크로드, 클러스터 리소스 및 하드웨어 사양을 계획합니다.

3.2.2.1. Telco RAN DU 애플리케이션 워크로드

DU 작업자 노드에는 최대 성능을 위해 조정된 펌웨어가 있는 3세대 Xeon(Ice Lake) 2.20 Cryostat 또는 더 나은 CPU가 있어야 합니다.

5G RAN DU 사용자 애플리케이션 및 워크로드는 다음과 같은 모범 사례 및 애플리케이션 제한을 준수해야 합니다.

  • CNF 모범 사례 가이드의 최신 버전을 준수하는 클라우드 네이티브 네트워크 기능(CNF )을 개발합니다.
  • 고성능 네트워킹을 위해 SR-IOV를 사용합니다.
  • exec 프로브를 사용하여 다른 적절한 옵션을 사용할 수 없는 경우에만 사용

    • CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오. 다른 프로브 구현(예: httpGet 또는 tcpSocket )을 사용합니다.
    • exec 프로브를 사용해야 하는 경우 exec 프로브 빈도 및 수량을 제한합니다. 최대 exec 프로브 수는 10초 미만으로 유지해야 하며 빈도를 10초 미만으로 설정하지 않아야 합니다.
참고

시작 프로브에는 지속적인 상태 작업 중에 최소한의 리소스가 필요합니다. exec 프로브의 제한은 주로 liveness 및 readiness 프로브에 적용됩니다.

3.2.2.2. Telco RAN DU 대표 참조 애플리케이션 워크로드 특성

대표적인 참조 애플리케이션 워크로드에는 다음과 같은 특징이 있습니다.

  • 관리 및 제어 기능을 포함하여 vRAN 애플리케이션에 대한 최대 15개의 Pod 및 30개의 컨테이너가 있습니다.
  • Pod당 최대 2개의 ConfigMap 및 4개의 Secret CR 사용
  • 10초 미만의 빈도로 최대 10 exec 프로브 사용
  • kube-apiserver 에서의 증분 애플리케이션 로드는 클러스터 플랫폼 사용의 10% 미만입니다.

    참고

    플랫폼 지표에서 CPU 로드를 추출할 수 있습니다. 예를 들면 다음과 같습니다.

    query=avg_over_time(pod:container_cpu_usage:sum{namespace="openshift-kube-apiserver"}[30m])
  • 애플리케이션 로그는 플랫폼 로그 수집기에 의해 수집되지 않습니다.
  • 기본 CNI의 집계 트래픽은 1MBps 미만입니다.
3.2.2.3. Telco RAN 작업자 노드 클러스터 리소스 사용률

애플리케이션 워크로드 및 OpenShift Container Platform Pod를 포함하여 시스템에서 실행 중인 최대 Pod 수는 120입니다.

리소스 사용률

OpenShift Container Platform 리소스 사용률은 다음과 같은 애플리케이션 워크로드 특성을 포함한 다양한 요인에 따라 다릅니다.

  • Pod 수
  • 프로브 유형 및 빈도
  • 커널 네트워킹을 통한 기본 CNI 또는 보조 CNI의 메시징 속도
  • API 액세스 속도
  • 로깅 속도
  • 스토리지 IOPS

클러스터 리소스 요구 사항은 다음 조건에 따라 적용할 수 있습니다.

  • 클러스터는 설명된 대표 애플리케이션 워크로드를 실행하고 있습니다.
  • 클러스터는 "Telco RAN DU 작업자 노드 클러스터 리소스 사용률"에 설명된 제약 조건으로 관리됩니다.
  • RAN DU 사용 모델 구성에서 선택 사항으로 명시된 구성 요소는 적용되지 않습니다.
중요

리소스 사용률에 미치는 영향 및 Telco RAN DU 참조 디자인 범위를 벗어난 구성에 대한 KPI 대상을 충족하기 위해 추가 분석을 수행해야 합니다. 요구 사항에 따라 클러스터에서 추가 리소스를 할당해야 할 수 있습니다.

3.2.2.4. hub 클러스터 관리 특성

RHACM(Red Hat Advanced Cluster Management)은 권장되는 클러스터 관리 솔루션입니다. hub 클러스터에서 다음 제한으로 구성합니다.

  • 규정 준수 평가 간격을 10분 이상 사용하여 최대 5개의 RHACM 정책을 구성합니다.
  • 정책에서 최대 10개의 관리형 클러스터 템플릿을 사용합니다. 가능한 경우 hub-side template을 사용하십시오.
  • policy-controllerobservability-controller 애드온을 제외한 모든 RHACM 애드온을 비활성화합니다. Observability 를 기본 구성으로 설정합니다.

    중요

    선택적 구성 요소 또는 추가 기능을 구성하면 리소스 사용량이 추가되고 전체 시스템 성능이 저하될 수 있습니다.

    자세한 내용은 참조 설계 배포 구성 요소를 참조하십시오.

표 3.2. 참조 애플리케이션 로드 아래의 OpenShift 플랫폼 리소스 사용률
지표제한참고

CPU 사용량

4000 mc 미만 - 2 코어 (4 하이퍼스레드)

플랫폼 CPU는 예약된 각 코어의 두 하이퍼스레드를 포함하여 예약된 코어에 고정되어 있습니다. 시스템은 주기적인 시스템 작업 및 급증을 허용하도록 안정적인 상태에서 3개의 CPU (3000mc)를 사용하도록 설계되었습니다.

사용된 메모리

16G 미만

 
3.2.2.5. Telco RAN DU RDS 구성 요소

다음 섹션에서는 telco RAN DU 워크로드를 실행하기 위해 클러스터를 구성하고 배포하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.

그림 3.2. Telco RAN DU 참조 구성 요소

telco RAN DU 구성 요소 스택을 설명하는 다이어그램입니다.
참고

telco RAN DU 프로필에 포함되지 않은 구성 요소가 워크로드 애플리케이션에 할당된 CPU 리소스에 영향을 미치지 않도록 합니다.

중요

트리 부족 드라이버는 지원되지 않습니다.

추가 리소스

3.2.3. Telco RAN DU 4.14 참조 구성 요소

다음 섹션에서는 RAN DU 워크로드를 실행하기 위해 클러스터를 구성하고 배포하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.

3.2.3.1. 호스트 펌웨어 튜닝
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

시스템 수준 성능 구성. 권장 설정은 짧은 대기 시간과 고성능은 호스트 펌웨어 구성 을 참조하십시오.

Ironic 검사가 활성화되면 hub 클러스터의 클러스터별 BareMetalHost CR에서 펌웨어 설정 값을 사용할 수 있습니다. 클러스터를 설치하는 데 사용하는 SiteConfig CR의 spec.clusters.nodes 필드에 라벨을 사용하여 Ironic 검사를 활성화합니다. 예를 들면 다음과 같습니다.

nodes:
  - hostName: "example-node1.example.com"
    ironicInspect: "enabled"
참고

Ttelco RAN DU 참조 SiteConfig 는 기본적으로 ironicInspect 필드를 활성화하지 않습니다.

제한 및 요구사항
  • 하이퍼 스레딩을 활성화해야 합니다.
엔지니어링 고려 사항
  • 최대 성능을 위해 모든 설정 조정

    참고

    필요에 따라 성능 저하를 위해 펌웨어 선택을 조정할 수 있습니다.

3.2.3.2. Node Tuning Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

성능 프로파일을 생성하여 클러스터 성능을 조정합니다. 성능 프로필을 사용하여 구성하는 설정은 다음과 같습니다.

  • 실시간 또는 비실시간 커널 선택.
  • 예약된 또는 분리된 cpuset 에 코어 할당. 관리 워크로드 파티션에 할당된 OpenShift Container Platform 프로세스는 예약된 세트에 고정됩니다.
  • kubelet 기능 활성화(CPU 관리자, 토폴로지 관리자, 메모리 관리자).
  • 대규모 페이지 구성.
  • 추가 커널 인수 설정.
  • 코어당 전원 튜닝 및 최대 CPU 빈도 설정.
제한 및 요구사항

Node Tuning Operator는 PerformanceProfile CR을 사용하여 클러스터를 구성합니다. RAN DU 프로파일 PerformanceProfile CR에서 다음 설정을 구성해야 합니다.

  • 예약 및 분리된 코어를 선택하고 Intel 3rd Generation Xeon (Ice Lake) 2.20 Cryostat CPU에서 최소 4개의 하이퍼스레드(각주 2개 코어)를 할당하거나 최대 성능을 위해 펌웨어를 튜닝했는지 확인합니다.
  • 포함된 각 코어에 대해 두 개의 하이퍼스레드 형제를 모두 포함하도록 예약된 cpuset 을 설정합니다. 예약되지 않은 코어는 워크로드 예약에 할당 가능한 CPU로 사용할 수 있습니다. 하이퍼스레드 형제가 예약된 코어와 분리된 코어 간에 분할되지 않도록 합니다.
  • 예약 및 분리된 CPU로 설정된 내용에 따라 모든 코어에 모든 스레드를 포함하도록 예약 및 분리된 CPU를 구성합니다.
  • 예약된 CPU 세트에 포함할 각 NUMA 노드의 코어 0을 설정합니다.
  • 대규모 페이지 크기를 1G로 설정합니다.
참고

관리 파티션에 워크로드를 추가해서는 안 됩니다. OpenShift 관리 플랫폼의 일부인 포드만 관리 파티션에 주석을 달아야 합니다.

엔지니어링 고려 사항
  • RT 커널을 사용하여 성능 요구 사항을 충족해야 합니다.

    참고

    필요한 경우 RT가 아닌 커널을 사용할 수 있습니다.

  • 구성하는 대규모 페이지 수는 애플리케이션 워크로드 요구 사항에 따라 다릅니다. 이 매개변수의 변형은 예상되고 허용됩니다.
  • 선택한 하드웨어 및 시스템에서 사용 중인 추가 구성 요소를 기반으로 예약 및 격리된 CPU 세트 구성에서 변동이 예상됩니다. 변형은 지정된 제한을 충족해야 합니다.
  • IRQ 선호도 지원이 없는 하드웨어는 분리된 CPU에 영향을 미칩니다. 보장된 전체 CPU QoS가 있는 Pod가 할당된 CPU를 완전히 사용하도록 하려면 서버의 모든 하드웨어가 IRQ 선호도를 지원해야 합니다. 자세한 내용은 IRQ 선호도 설정 지원 정보를 참조하십시오.
참고

OpenShift Container Platform 4.14에서 클러스터에 구성된 모든 PerformanceProfile CR로 인해 Node Tuning Operator가 cgroup v1을 사용하도록 모든 클러스터 노드를 자동으로 설정합니다.

cgroup에 대한 자세한 내용은 Linux cgroup 구성을 참조하십시오.

3.2.3.3. PTP Operator
이번 릴리스의 새로운 기능
  • Intel E810-XXV-4T Westport Channel NIC를 사용한 PTP 할 마스터 클럭 (T-GM) GPS 타이밍 - 최소 펌웨어 버전 4.30 (기술 프리뷰)
  • OpenShift Container Platform 4.14 (기술 프리뷰)의 PTP 이벤트 및 메트릭 (T-GM)이 새로운 기능
설명

클러스터 노드에 대한 PTP 타이밍 지원을 구성합니다. DU 노드는 다음 모드에서 실행할 수 있습니다.

  • T-GM 또는 경계 클럭 (T-BC)에 동기화 된 일반 클럭으로
  • 이중 경계 클럭으로, NIC당 하나씩 (고가용성은 지원되지 않음)
  • E810 Westport 채널 NIC를 지원하는 마스터 클록으로 (기술 프리뷰)
  • 무선 장치(RU)의 경계 클록으로 선택 가능

선택 사항: 애플리케이션이 실행 중인 노드에서 발생하는 PTP 이벤트에 애플리케이션을 구독합니다. HTTP를 통해 애플리케이션을 이벤트에 서브스크립션합니다.

제한 및 요구사항
  • 듀얼 NIC 구성에서 고가용성은 지원되지 않습니다.
  • T-GM으로 구성된 Westport 채널 NIC는 현재 스노우 드라이버 버전에서 DPLL을 지원하지 않습니다.
  • GPS 오프셋은 보고되지 않습니다. 기본 오프셋을 5 미만으로 사용합니다.
  • DPLL 오프셋이 보고되지 않습니다. 기본 오프셋을 5 미만으로 사용합니다.
엔지니어링 고려 사항
  • 일반 클럭, 경계 클럭 또는 마스터 클록에 대한 구성이 제공됩니다.
  • PTP 빠른 이벤트 알림은 ConfigMap CR을 사용하여 PTP 이벤트 서브스크립션을 저장
  • GPS 타이밍과 최소 펌웨어 버전 4.40인 PTP 할 마스터 클록에 대해 Intel E810-XXV-4T Westport Channel NIC를 사용하십시오.
3.2.3.4. SR-IOV Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
SR-IOV Operator는 SR-IOV CNI 및 장치 플러그인을 프로비저닝하고 구성합니다. netdevice (커널 VF) 및 DPDK( V fio) 장치가 모두 지원됩니다.
엔지니어링 고려 사항
  • 구성 및 SriovNetwork NodePolicy CR(사용자 정의 리소스) 수에 대한 고객 변동이 예상됩니다.
  • IOMMU 커널 명령줄 설정은 설치 시 MachineConfig CR에 적용됩니다. 이렇게 하면 SriovOperator CR에서 노드를 추가할 때 노드가 재부팅되지 않습니다.
3.2.3.5. 로깅
이번 릴리스의 새로운 기능
  • 이제 vector가 권장되는 로그 수집기입니다.
설명
로깅을 사용하여 원격 분석을 위해 far edge 노드에서 로그를 수집합니다.
엔지니어링 고려 사항
  • 예를 들어, 인프라 및 감사 로그 이외의 로그를 처리하려면 추가 로깅 속도를 기반으로 하는 추가 CPU 및 네트워크 대역폭이 필요합니다.
  • OpenShift Container Platform 4.14부터 벡터는 참조 로그 수집기입니다.

    참고

    RAN 사용 모델에서 fluentd 사용은 더 이상 사용되지 않습니다.

3.2.3.6. SRIOV-FEC Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
SRIOV-FEC Operator는 FEC 액셀러레이터 하드웨어를 지원하는 선택적 타사 Certified Operator입니다.
제한 및 요구사항
  • FEC Operator v2.7.0부터 다음을 수행합니다.

    • SecureBoot 지원
    • PFvfio 드라이버를 사용하려면 Pod에 삽입되는 vfio-token 을 사용해야 합니다. VF 토큰은 EAL 매개변수 --vfio-vf-token 을 사용하여 DPDK에 전달할 수 있습니다.
엔지니어링 고려 사항
  • SRIOV-FEC Operator는 분리된 CPU 세트의 CPU 코어를 사용합니다.
  • 예를 들어 검증 정책을 확장하여 FEC 준비 상태를 사전 점검의 일부로 검증할 수 있습니다.
3.2.3.7. Local Storage Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
Local Storage Operator를 사용하여 애플리케이션에서 PVC 리소스로 사용할 수 있는 영구 볼륨을 생성할 수 있습니다. 생성하는 PV 리소스의 수 및 유형은 요구 사항에 따라 다릅니다.
엔지니어링 고려 사항
  • PV 를 생성하기 전에 PV CR에 대한 백업 스토리지를 생성합니다. 파티션, 로컬 볼륨, LVM 볼륨 또는 전체 디스크일 수 있습니다.
  • 디스크 및 파티션을 올바르게 할당하도록 각 장치에 액세스하는 데 사용되는 하드웨어 경로에서 LocalVolume CR의 장치 목록을 참조하십시오. 논리 이름(예: /dev/sda)은 노드를 재부팅해도 일관성이 보장되지 않습니다.

    자세한 내용은 장치 식별자에 대한 RHEL 9 설명서 를 참조하십시오.

3.2.3.8. LVMS Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
이번 릴리스의 새로운 기능
  • 간소화된 LVMS deviceSelector 논리
  • ext4PV 리소스가 포함된 LVM 스토리지
참고

LVMS Operator는 선택적 구성 요소입니다.

설명

LVMS Operator는 블록 및 파일 스토리지에 대한 동적 프로비저닝을 제공합니다. LVMS Operator는 애플리케이션에서 PVC 리소스로 사용할 수 있는 로컬 장치에서 논리 볼륨을 생성합니다. 볼륨 확장 및 스냅샷도 가능합니다.

다음 예제 구성은 설치 디스크 를 제외한 노드에서 사용 가능한 모든 디스크를 활용하는 Cryostat1 볼륨 그룹을 생성합니다.

StorageLVMCluster.yaml

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: storage-lvmcluster
  namespace: openshift-storage
  annotations:
    ran.openshift.io/ztp-deploy-wave: "10"
spec: {}
  storage:
    deviceClasses:
    - name: vg1
      thinPoolConfig:
        name: thin-pool-1
        sizePercent: 90
        overprovisionRatio: 10

제한 및 요구사항
  • 단일 노드 OpenShift 클러스터에서 영구 스토리지는 둘 다 아닌 LVMS 또는 로컬 스토리지에서 제공해야 합니다.
엔지니어링 고려 사항
  • LVMS Operator는 DU 사용 사례에 대한 참조 스토리지 솔루션이 아닙니다. 애플리케이션 워크로드에 LVMS Operator가 필요한 경우 애플리케이션 코어에 대해 리소스 사용을 고려합니다.
  • 스토리지 요구 사항에 충분한 디스크 또는 파티션을 사용할 수 있는지 확인합니다.
3.2.3.9. 워크로드 파티셔닝
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

워크로드 파티셔닝은 DU 프로파일의 일부인 OpenShift 플랫폼과 Day 2 Operator Pod를 예약된 cpuset 에 고정하고 노드 회계에서 예약된 CPU를 제거합니다. 이렇게 하면 사용자 워크로드에서 예약되지 않은 모든 CPU 코어를 사용할 수 있습니다.

OpenShift Container Platform 4.14에서 워크로드 파티셔닝을 활성화하고 구성하는 방법입니다.

4.14 이상
  • 설치 매개변수를 설정하여 파티션을 구성합니다.

    cpuPartitioningMode: AllNodes
  • PerformanceProfile CR에 예약된 CPU 세트를 사용하여 관리 파티션 코어 구성
4.13 및 이전 버전
  • 설치 시 적용된 추가 MachineConfiguration CR을 사용하여 파티션 구성
제한 및 요구사항
  • Pod 를 관리 파티션에 적용할 수 있도록 네임스페이스 및 Pod CR에 주석을 달 수 있어야 합니다.
  • CPU 제한이 있는 Pod는 파티션에 할당할 수 없습니다. 변경으로 Pod QoS를 변경할 수 있기 때문입니다.
  • 관리 파티션에 할당할 수 있는 최소 CPU 수에 대한 자세한 내용은 Node Tuning Operator 를 참조하십시오.
엔지니어링 고려 사항
  • 워크로드 파티셔닝은 모든 관리 Pod를 예약된 코어에 고정합니다. 워크로드 시작, 노드 재부팅 또는 기타 시스템 이벤트가 발생할 때 발생하는 CPU 사용 급증을 고려하여 예약된 세트에 코어 수를 할당해야 합니다.
3.2.3.10. 클러스터 튜닝
이번 릴리스의 새로운 기능
  • 클러스터 기능 기능을 사용하여 Image Registry Operator를 제거할 수 있습니다.

    참고

    클러스터를 설치하는 데 사용하는 SiteConfig CR의 spec.clusters.installConfigOverrides 필드를 사용하여 클러스터 기능을 구성합니다.

설명

이제 클러스터 기능에 MachineAPI 구성 요소가 포함되어 있으며 제외하면 클러스터에서 다음 Operator 및 해당 리소스를 비활성화합니다.

  • openshift/cluster-autoscaler-operator
  • openshift/cluster-control-plane-machine-set-operator
  • openshift/machine-api-operator
제한 및 요구사항
  • 설치 관리자가 프로비저닝한 설치 방법에서는 클러스터 기능을 사용할 수 없습니다.
  • 모든 플랫폼 튜닝 구성을 적용해야 합니다. 다음 표에는 필요한 플랫폼 튜닝 구성이 나열되어 있습니다.

    표 3.3. 클러스터 기능 구성
    기능설명

    선택적 클러스터 기능 제거

    단일 노드 OpenShift 클러스터에서만 선택적 클러스터 Operator를 비활성화하여 OpenShift Container Platform 풋프린트를 줄입니다.

    • Marketplace 및 Node Tuning Operator를 제외한 모든 선택적 Operator를 제거합니다.

    클러스터 모니터링 구성

    다음을 수행하여 공간 절약을 위해 모니터링 스택을 구성합니다.

    • 로컬 alertmanager 및 Telemeter 구성 요소를 비활성화 합니다.
    • RHACM 관찰 기능을 사용하는 경우 경고를 허브 클러스터에 전달하려면 적절한 additionalAlertManagerConfigs CR로 CR을 보강해야 합니다.
    • Prometheus 보존 기간을 24시간으로 줄입니다.

      참고

      RHACM 허브 클러스터는 관리되는 클러스터 메트릭을 집계합니다.

    네트워킹 진단 비활성화

    필요하지 않으므로 단일 노드 OpenShift에 대한 네트워킹 진단을 비활성화합니다.

    단일 Operator Hub 카탈로그 소스 구성

    RAN DU 배포에 필요한 Operator만 포함하는 단일 카탈로그 소스를 사용하도록 클러스터를 구성합니다. 각 카탈로그 소스는 클러스터에서 CPU 사용을 늘립니다. 단일 CatalogSource 를 사용하면 플랫폼 CPU 예산에 적합합니다.

3.2.3.11. 머신 구성
이번 릴리스의 새로운 기능
  • 노드 복구 후 rcu_normal 설정
제한 및 요구사항
  • CRI-O wipe disable MachineConfig 는 디스크의 이미지가 정의된 유지 관리 창에서 예약된 유지 관리 중이 아닌 정적이라고 가정합니다. 이미지가 정적임을 확인하려면 Pod imagePullPolicy 필드를 Always 로 설정하지 마십시오.

    표 3.4. 머신 구성 옵션
    기능설명

    컨테이너 런타임

    모든 노드 역할에 대해 컨테이너 런타임을 crun 으로 설정합니다.

    kubelet 구성 및 컨테이너 마운트 숨기기

    kubelet 하우스키핑 및 제거 모니터링의 빈도를 줄여 CPU 사용량을 줄입니다. kubelet 및 CRI-O에 표시되는 컨테이너 마운트 네임스페이스를 생성하여 시스템 마운트 검사 리소스 사용량을 줄입니다.

    SCTP

    선택적 구성(기본적으로 활성화)은 SCTP를 활성화합니다. SCTP는 RAN 애플리케이션에 필요하지만 RHCOS에서 기본적으로 비활성화되어 있습니다.

    kdump

    선택적 설정(기본적으로 사용)을 사용하면 커널 패닉이 발생할 때 kdump에서 디버그 정보를 캡처할 수 있습니다.

    CRI-O wipe disable

    클린 종료 후 CRI-O 이미지 캐시 자동 제거 기능을 비활성화합니다.

    SR-IOV 관련 커널 인수

    커널 명령줄에 추가 SR-IOV 관련 인수가 포함됩니다.

    RCU 일반 systemd 서비스

    시스템이 완전히 시작된 후 rcu_normal 를 설정합니다.

    일회성 시간 동기화

    컨트롤 플레인 또는 작업자 노드에 대한 일회성 시스템 시간 동기화 작업을 실행합니다.

3.2.3.12. 참조 설계 배포 구성 요소

다음 섹션에서는 RHACM(Red Hat Advanced Cluster Management)을 사용하여 허브 클러스터를 구성하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.

3.2.3.12.1. Red Hat Advanced Cluster Management(RHACM)
이번 릴리스의 새로운 기능
  • 추가 노드 레이블은 설치 중에 구성할 수 있습니다.
설명

RHACM은 배포된 클러스터에 대한 MCE(Multi Cluster Engine) 설치 및 지속적인 라이프사이클 관리 기능을 제공합니다. Policy CR을 사용하여 구성 및 업그레이드를 선언적으로 지정하고 토폴로지 Aware Lifecycle Manager에서 관리하는 대로 RHACM 정책 컨트롤러를 사용하여 클러스터에 정책을 적용합니다.

  • ZTP(ZTP)는 RHACM의 MCE 기능을 사용합니다.
  • 구성, 업그레이드 및 클러스터 상태는 RHACM 정책 컨트롤러로 관리됩니다.
제한 및 요구사항
  • 단일 허브 클러스터는 5 Policy CR이 각 클러스터에 바인딩된 최대 3500개의 배포된 단일 노드 OpenShift 클러스터를 지원합니다.
엔지니어링 고려 사항
  • 클러스터별 구성: 관리 클러스터에는 일반적으로 개별 클러스터에 고유한 몇 가지 구성 값이 있습니다. 이러한 구성은 클러스터 이름을 기반으로 ConfigMap CR에서 가져온 값을 사용하여 RHACM 정책 허브 쪽 템플릿을 사용하여 관리해야 합니다.
  • 관리 클러스터에 CPU 리소스를 저장하려면 클러스터의 GitOps ZTP 설치 후 정적 구성을 적용하는 정책을 관리 클러스터에서 바인딩해야 합니다. 자세한 내용은 영구 볼륨 릴리스를 참조하십시오.
3.2.3.12.2. 토폴로지 인식 라이프사이클 관리자(TALM)
이번 릴리스의 새로운 기능
  • 사용자 지정 추가 이미지에 대한 사전 캐싱 지원 추가
설명
관리형 업데이트

TALM은 변경 사항(클러스터 및 Operator 업그레이드, 구성 등)이 네트워크에 롤아웃되는 방식을 관리하기 위해 hub 클러스터에서만 실행되는 Operator입니다. TALM은 다음을 수행합니다.

  • Policy CR을 사용하여 사용자 구성 가능한 일괄 처리의 클러스터에 점진적으로 업데이트를 적용합니다.
  • 클러스터별로 ztp-done 레이블 또는 기타 사용자 구성 가능 라벨 추가
단일 노드 OpenShift 클러스터 사전 연결

TALM은 업그레이드를 시작하기 전에 OpenShift Container Platform, OLM Operator 및 추가 사용자 이미지의 선택적 사전 처리를 단일 노드 OpenShift 클러스터에 지원합니다.

  • PreCachingConfig 사용자 정의 리소스를 사용하여 선택적 사전 캐싱 구성을 지정할 수 있습니다. 예를 들면 다음과 같습니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: PreCachingConfig
    metadata:
      name: example-config
      namespace: example-ns
    spec:
      additionalImages:
        - quay.io/foobar/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e
        - quay.io/foobar/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adf
        - quay.io/foobar/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfs
      spaceRequired: 45 GiB 1
      overrides:
        preCacheImage: quay.io/test_images/pre-cache:latest
        platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e
      operatorsIndexes:
        - registry.example.com:5000/custom-redhat-operators:1.0.0
      operatorsPackagesAndChannels:
        - local-storage-operator: stable
        - ptp-operator: stable
        - sriov-network-operator: stable
      excludePrecachePatterns: 2
        - aws
        - vsphere
    1 1
    구성 가능한 space-required 매개변수를 사용하면 스토리지 공간 전후의 유효성을 검사할 수 있습니다.
    2
    구성 가능한 필터링을 사용하면 사용되지 않는 이미지를 제외할 수 있습니다.
단일 노드 OpenShift의 백업 및 복원
TALM은 로컬 디스크의 전용 파티션으로 클러스터 운영 체제 및 구성의 스냅샷을 작성할 수 있습니다. 클러스터를 백업 상태로 반환하는 복원 스크립트가 제공됩니다.
제한 및 요구사항
  • TALM은 400개의 배치로 동시 클러스터 배포를 지원
  • 사전 캐싱 및 백업 기능은 단일 노드 OpenShift 클러스터에만 사용할 수 있습니다.
엔지니어링 고려 사항
  • PreCachingConfig CR은 선택 사항이며 플랫폼 관련 (OpenShift 및 OLM Operator) 이미지를 사전 캐시하려는 경우 생성할 필요가 없습니다. PreCachingConfig CR은 ClusterGroupUpgrade CR에서 참조하기 전에 적용해야 합니다.
  • TALM 백업 및 복원 기능을 사용하도록 선택한 경우 설치 중에 복구 파티션을 만듭니다.
3.2.3.12.3. GitOps 및 GitOps ZTP 플러그인
이번 릴리스의 새로운 기능
  • GitOps ZTP 배포를 위해 Git에 사용자 제공 CR을 포함하는 GA 지원
  • GitOps ZTP가 배포된 클러스터 버전과 독립
설명

GitOps 및 GitOps ZTP 플러그인은 클러스터 배포 및 구성을 관리하기 위한 GitOps 기반 인프라를 제공합니다. 클러스터 정의 및 구성은 Git에서 선언적 상태로 유지됩니다. ZTP 플러그인은 site Config CR에서 설치 CR을 생성하고 PolicyGenTemplate CR을 기반으로 정책의 구성 CR을 자동으로 래핑할 수 있도록 지원합니다.

해당 하위 디렉터리에 kustomization.yaml 파일이 포함된 /source-crs 하위 디렉터리의 기준 참조 구성 CR을 사용하여 관리형 클러스터에서 여러 버전의 OpenShift Container Platform을 배포하고 관리할 수 있습니다. PolicyGenTemplate CR에 지정된 사전 정의된 CR과 함께 사용하는 이 하위 디렉터리에 사용자 제공 CR을 추가합니다. 이를 통해 특정 요구 사항에 맞게 구성을 조정하고 관리 클러스터와 허브 클러스터 간에 GitOps ZTP 버전 독립성을 제공할 수 있습니다.

자세한 내용은 다음을 참조하십시오.

제한
  • ArgoCD 애플리케이션당 300개의 site Config CR. 여러 애플리케이션을 사용하여 단일 허브 클러스터에서 지원하는 최대 클러스터 수를 달성할 수 있습니다.
  • Git의 /source-crs 폴더의 콘텐츠는 GitOps ZTP 플러그인 컨테이너에 제공된 콘텐츠를 덮어씁니다. Git이 검색 경로에서 우선합니다.
  • PolicyGenTemplate 을 생성기로 포함하는 kustomization.yaml 파일과 동일한 디렉터리에 /source-crs 폴더를 추가합니다.

    참고

    이 컨텍스트에서 /source-crs 디렉터리의 대체 위치는 지원되지 않습니다.

엔지니어링 고려 사항
  • 콘텐츠를 업데이트할 때 파일의 혼동 또는 의도하지 않은 덮어쓰기를 방지하려면 /source-crs 폴더 및 Git의 추가 매니페스트에서 사용자 제공 CR에 대해 고유하고 구분 가능한 이름을 사용합니다.
  • SiteConfig CR을 사용하면 여러 추가 경로가 허용됩니다. 동일한 이름의 파일이 여러 디렉토리 경로에 있는 경우 마지막으로 발견된 파일이 우선합니다. 이를 통해 전체 버전별 0 매니페스트(extra-manifests) 세트를 Git에 배치하고 site Config 에서 참조할 수 있습니다. 이 기능을 사용하면 여러 OpenShift Container Platform 버전을 관리 클러스터에 동시에 배포할 수 있습니다.
  • SiteConfig CR의 extraManifestPath 필드는 OpenShift Container Platform 4.15 이상에서 더 이상 사용되지 않습니다. 대신 새로운 extraManifests.searchPaths 필드를 사용합니다.
3.2.3.12.4. 에이전트 기반 설치 프로그램
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

에이전트 기반 설치 관리자(ABI)는 중앙 집중식 인프라 없이 설치 기능을 제공합니다. 설치 프로그램은 서버에 마운트하는 ISO 이미지를 생성합니다. 서버를 부팅하면 OpenShift Container Platform을 설치하고 추가 매니페스트를 제공했습니다.

참고

ABI를 사용하여 허브 클러스터 없이 OpenShift Container Platform 클러스터를 설치할 수도 있습니다. 이러한 방식으로 ABI를 사용할 때 이미지 레지스트리가 계속 필요합니다.

에이전트 기반 설치 관리자(ABI)는 선택적 구성 요소입니다.

제한 및 요구사항
  • 설치 시 제한된 추가 매니페스트 세트를 제공할 수 있습니다.
  • RAN DU 사용 사례에 필요한 MachineConfiguration CR을 포함해야 합니다.
엔지니어링 고려 사항
  • ABI는 기본 OpenShift Container Platform 설치를 제공합니다.
  • 설치 후 Day 2 Operator 및 RAN DU 사용 사례 구성을 설치합니다.
3.2.3.13. 추가 구성 요소
3.2.3.13.1. Bare Metal Event Relay

Bare Metal Event Relay는 관리형 spoke 클러스터에서 독점적으로 실행되는 선택적 Operator입니다. Redfish 하드웨어 이벤트를 클러스터 애플리케이션으로 릴레이합니다.

참고

베어 메탈 이벤트 릴레이는 RAN DU에 포함되지 않으며 모델 참조 구성에 포함되어 있으며 선택적 기능입니다. Bare Metal Event Relay를 사용하려면 애플리케이션 CPU 예산에서 추가 CPU 리소스를 할당합니다.

3.2.4. Ttelco RAN distributed unit (DU) 참조 구성 CR

다음 CR(사용자 정의 리소스)을 사용하여 telco RAN DU 프로필을 사용하여 OpenShift Container Platform 클러스터를 구성하고 배포합니다. 일부 CR은 요구 사항에 따라 선택 사항입니다. 변경할 수 있는 CR 필드에는 YAML 주석을 사용하여 CR에 주석이 추가됩니다.

참고

ztp-site-generate 컨테이너 이미지에서 RAN DU CR의 전체 세트를 추출할 수 있습니다. 자세한 내용은 GitOps ZTP 사이트 구성 리포지토리 준비를 참조하십시오.

3.2.4.1. 2일차 Operator 참조 CR
표 3.5. 2일차 Operator CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

클러스터 로깅

ClusterLogForwarder.yaml

없음

없음

클러스터 로깅

ClusterLogging.yaml

없음

없음

클러스터 로깅

ClusterLogNS.yaml

없음

없음

클러스터 로깅

ClusterLogOperGroup.yaml

없음

없음

클러스터 로깅

ClusterLogSubscription.yaml

없음

없음

Local Storage Operator

StorageClass.yaml

없음

Local Storage Operator

StorageLV.yaml

없음

Local Storage Operator

StorageNS.yaml

없음

Local Storage Operator

StorageOperGroup.yaml

없음

Local Storage Operator

StorageSubscription.yaml

없음

Node Tuning Operator

PerformanceProfile.yaml

없음

없음

Node Tuning Operator

TunedPerformancePatch.yaml

없음

없음

PTP 빠른 이벤트 알림

PtpOperatorConfigForEvent.yaml

없음

PTP Operator

PtpConfigBoundary.yaml

없음

없음

PTP Operator

PtpConfigGmWpc.yaml

없음

PTP Operator

PtpConfigSlave.yaml

없음

없음

PTP Operator

PtpSubscription.yaml

없음

없음

PTP Operator

PtpSubscriptionNS.yaml

없음

없음

PTP Operator

PtpSubscriptionOperGroup.yaml

없음

없음

SR-IOV FEC Operator

AcceleratorsNS.yaml

없음

SR-IOV FEC Operator

AcceleratorsOperGroup.yaml

없음

SR-IOV FEC Operator

AcceleratorsSubscription.yaml

없음

SR-IOV FEC Operator

SriovFecClusterConfig.yaml

없음

SR-IOV Operator

SriovNetwork.yaml

없음

없음

SR-IOV Operator

SriovNetworkNodePolicy.yaml

없음

없음

SR-IOV Operator

SriovOperatorConfig.yaml

없음

없음

SR-IOV Operator

SriovSubscription.yaml

없음

없음

SR-IOV Operator

SriovSubscriptionNS.yaml

없음

없음

SR-IOV Operator

SriovSubscriptionOperGroup.yaml

없음

없음

3.2.4.2. 클러스터 튜닝 참조 CR
표 3.6. 클러스터 튜닝 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

클러스터 기능

example-sno.yaml

없음

없음

네트워크 진단 비활성화

DisableSnoNetworkDiag.yaml

없음

없음

모니터링 구성

ReduceMonitoringFootprint.yaml

없음

없음

OperatorHub

DefaultCatsrc.yaml

없음

없음

OperatorHub

DisconnectedICSP.yaml

없음

없음

OperatorHub

OperatorHub.yaml

없음

없음

3.2.4.3. 머신 구성 참조 CR
표 3.7. 머신 구성 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

컨테이너 런타임(crun)

enable-crun-master.yaml

없음

없음

컨테이너 런타임(crun)

enable-crun-worker.yaml

없음

없음

CRI-O wipe 비활성화

99-crio-disable-wipe-master.yaml

없음

없음

CRI-O wipe 비활성화

99-crio-disable-wipe-worker.yaml

없음

없음

kdump 활성화

05-kdump-config-master.yaml

없음

kdump 활성화

05-kdump-config-worker.yaml

없음

kdump 활성화

06-kdump-master.yaml

없음

없음

kdump 활성화

06-kdump-worker.yaml

없음

없음

kubelet 구성 및 컨테이너 마운트 숨기기

01-container-mount-ns-and-kubelet-conf-master.yaml

없음

없음

kubelet 구성 및 컨테이너 마운트 숨기기

01-container-mount-ns-and-kubelet-conf-worker.yaml

없음

없음

일회성 시간 동기화

99-sync-time-once-master.yaml

없음

일회성 시간 동기화

99-sync-time-once-worker.yaml

없음

SCTP

03-sctp-machine-config-master.yaml

없음

없음

SCTP

03-sctp-machine-config-worker.yaml

없음

없음

SR-IOV 관련 커널 인수

07-sriov-related-kernel-args-master.yaml

없음

3.2.4.4. YAML 참조

다음은 telco RAN DU 4.14 참조 구성을 구성하는 모든 CR(사용자 정의 리소스)에 대한 전체 참조입니다.

3.2.4.4.1. 2일차 Operator 참조 YAML

ClusterLogForwarder.yaml

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  outputs: $outputs
  pipelines: $pipelines

ClusterLogging.yaml

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  managementState: "Managed"
  collection:
    logs:
      type: "vector"

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  targetNamespaces:
    - openshift-logging

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

StorageClass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations: {}
  name: example-storage-class
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete

StorageLV.yaml

apiVersion: "local.storage.openshift.io/v1"
kind: "LocalVolume"
metadata:
  name: "local-disks"
  namespace: "openshift-local-storage"
  annotations: {}
spec:
  logLevel: Normal
  managementState: Managed
  storageClassDevices:
    # The list of storage classes and associated devicePaths need to be specified like this example:
    - storageClassName: "example-storage-class"
      volumeMode: Filesystem
      fsType: xfs
      # The below must be adjusted to the hardware.
      # For stability and reliability, it's recommended to use persistent
      # naming conventions for devicePaths, such as /dev/disk/by-path.
      devicePaths:
        - /dev/disk/by-path/pci-0000:05:00.0-nvme-1
#---
## How to verify
## 1. Create a PVC
# apiVersion: v1
# kind: PersistentVolumeClaim
# metadata:
#   name: local-pvc-name
# spec:
#   accessModes:
#   - ReadWriteOnce
#   volumeMode: Filesystem
#   resources:
#     requests:
#       storage: 100Gi
#   storageClassName: example-storage-class
#---
## 2. Create a pod that mounts it
# apiVersion: v1
# kind: Pod
# metadata:
#   labels:
#     run: busybox
#   name: busybox
# spec:
#   containers:
#   - image: quay.io/quay/busybox:latest
#     name: busybox
#     resources: {}
#     command: ["/bin/sh", "-c", "sleep infinity"]
#     volumeMounts:
#     - name: local-pvc
#       mountPath: /data
#   volumes:
#   - name: local-pvc
#     persistentVolumeClaim:
#       claimName: local-pvc-name
#   dnsPolicy: ClusterFirst
#   restartPolicy: Always
## 3. Run the pod on the cluster and verify the size and access of the `/data` mount

StorageNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-local-storage
  annotations:
    workload.openshift.io/allowed: management

StorageOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-local-storage
  namespace: openshift-local-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-local-storage

StorageSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: local-storage-operator
  namespace: openshift-local-storage
  annotations: {}
spec:
  channel: "stable"
  name: local-storage-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

PerformanceProfile.yaml

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

TunedPerformancePatch.yaml

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations: {}
spec:
  profile:
    - name: performance-patch
      # Please note:
      # - The 'include' line must match the associated PerformanceProfile name, following below pattern
      #   include=openshift-node-performance-${PerformanceProfile.metadata.name}
      # - When using the standard (non-realtime) kernel, remove the kernel.timer_migration override from
      #   the [sysctl] section and remove the entire section if it is empty.
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-openshift-node-performance-profile
        [sysctl]
        kernel.timer_migration=1
        [scheduler]
        group.ice-ptp=0:f:10:*:ice-ptp.*
        group.ice-gnss=0:f:10:*:ice-gnss.*
        [service]
        service.stalld=start,enable
        service.chronyd=stop,disable
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: "$mcp"
      priority: 19
      profile: performance-patch

PtpOperatorConfigForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
  annotations: {}
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/$mcp: ""
  ptpEventConfig:
    enableEventPublisher: true
    transportHost: "http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"

PtpConfigBoundary.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary"
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        # The interface name is hardware-specific
        [$iface_slave]
        masterOnly 0
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 135
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "boundary"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigGmWpc.yaml

# The grandmaster profile is provided for testing only
# It is not installed on production clusters
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "grandmaster"
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: -r -u 0 -m -O -37 -N 8 -R 16 -s $iface_master -n 24
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      plugins:
        e810:
          enableDefaultConfig: false
          settings:
            LocalMaxHoldoverOffSet: 1500
            LocalHoldoverTimeout: 14400
            MaxInSpecOffset: 100
          pins: $e810_pins
          #  "$iface_master":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "0 1"
          ublxCmds:
            - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
                - "-P"
                - "29.20"
                - "-z"
                - "CFG-HW-ANT_CFG_VOLTCTRL,1"
              reportOutput: false
            - args: #ubxtool -P 29.20 -e GPS
                - "-P"
                - "29.20"
                - "-e"
                - "GPS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d Galileo
                - "-P"
                - "29.20"
                - "-d"
                - "Galileo"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d GLONASS
                - "-P"
                - "29.20"
                - "-d"
                - "GLONASS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d BeiDou
                - "-P"
                - "29.20"
                - "-d"
                - "BeiDou"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d SBAS
                - "-P"
                - "29.20"
                - "-d"
                - "SBAS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000
                - "-P"
                - "29.20"
                - "-t"
                - "-w"
                - "5"
                - "-v"
                - "1"
                - "-e"
                - "SURVEYIN,600,50000"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p MON-HW
                - "-P"
                - "29.20"
                - "-p"
                - "MON-HW"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,300
                - "-P"
                - "29.20"
                - "-p"
                - "CFG-MSG,1,38,300"
              reportOutput: true
      ts2phcOpts: " "
      ts2phcConf: |
        [nmea]
        ts2phc.master 1
        [global]
        use_syslog  0
        verbose 1
        logging_level 7
        ts2phc.pulsewidth 100000000
        #GNSS module s /dev/ttyGNSS* -al use _0
        #cat /dev/ttyGNSS_1700_0 to find available serial port
        #example value of gnss_serialport is /dev/ttyGNSS_1700_0
        ts2phc.nmea_serialport $gnss_serialport
        leapfile  /usr/share/zoneinfo/leap-seconds.list
        [$iface_master]
        ts2phc.extts_polarity rising
        ts2phc.extts_correction 0
      ptp4lConf: |
        [$iface_master]
        masterOnly 1
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 6
        clockAccuracy 0x27
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval 0
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval -4
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        clock_servo pi
        sanity_freq_limit  200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0x20
  recommend:
    - profile: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpConfigSlave.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: slave
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "slave"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "slave"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

PtpSubscription.yaml

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
  annotations: {}
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

PtpSubscriptionNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

PtpSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
  annotations: {}
spec:
  targetNamespaces:
    - openshift-ptp

AcceleratorsNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: vran-acceleration-operators
  annotations: {}

AcceleratorsOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: vran-operators
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  targetNamespaces:
    - vran-acceleration-operators

AcceleratorsSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-fec-subscription
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  channel: stable
  name: sriov-fec
  source: certified-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

SriovFecClusterConfig.yaml

apiVersion: sriovfec.intel.com/v2
kind: SriovFecClusterConfig
metadata:
  name: config
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  drainSkip: $drainSkip # true if SNO, false by default
  priority: 1
  nodeSelector:
    node-role.kubernetes.io/master: ""
  acceleratorSelector:
    pciAddress: $pciAddress
  physicalFunction:
    pfDriver: "vfio-pci"
    vfDriver: "vfio-pci"
    vfAmount: 16
    bbDevConfig: $bbDevConfig
#Recommended configuration for Intel ACC100 (Mount Bryce) FPGA here: https://github.com/smart-edge-open/openshift-operator/blob/main/spec/openshift-sriov-fec-operator.md#sample-cr-for-wireless-fec-acc100
#Recommended configuration for Intel N3000 FPGA here: https://github.com/smart-edge-open/openshift-operator/blob/main/spec/openshift-sriov-fec-operator.md#sample-cr-for-wireless-fec-n3000

SriovNetwork.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: ""
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  #  resourceName: ""
  networkNamespace: openshift-sriov-network-operator
#  vlan: ""
#  spoofChk: ""
#  ipam: ""
#  linkState: ""
#  maxTxRate: ""
#  minTxRate: ""
#  vlanQoS: ""
#  trust: ""
#  capabilities: ""

SriovNetworkNodePolicy.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: $name
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  # The attributes for Mellanox/Intel based NICs as below.
  #     deviceType: netdevice/vfio-pci
  #     isRdma: true/false
  deviceType: $deviceType
  isRdma: $isRdma
  nicSelector:
    # The exact physical function name must match the hardware used
    pfNames: [$pfNames]
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numVfs: $numVfs
  priority: $priority
  resourceName: $resourceName

SriovOperatorConfig.yaml

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  configDaemonNodeSelector:
    "node-role.kubernetes.io/$mcp": ""
  # Injector and OperatorWebhook pods can be disabled (set to "false") below
  # to reduce the number of management pods. It is recommended to start with the
  # webhook and injector pods enabled, and only disable them after verifying the
  # correctness of user manifests.
  #   If the injector is disabled, containers using sr-iov resources must explicitly assign
  #   them in the  "requests"/"limits" section of the container spec, for example:
  #    containers:
  #    - name: my-sriov-workload-container
  #      resources:
  #        limits:
  #          openshift.io/<resource_name>:  "1"
  #        requests:
  #          openshift.io/<resource_name>:  "1"
  enableInjector: true
  enableOperatorWebhook: true
  logLevel: 0

SriovSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

SriovSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management

SriovSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

3.2.4.4.2. 클러스터 튜닝 참조 YAML

example-sno.yaml

# example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
---
apiVersion: ran.openshift.io/v1
kind: 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..."
  clusters:
  - clusterName: "example-sno"
    networkType: "OVNKubernetes"
    # installConfigOverrides is a generic way of passing install-config
    # parameters through the siteConfig.  The 'capabilities' field configures
    # the composable openshift feature.  In this 'capabilities' setting, we
    # remove all but the marketplace component from the optional set of
    # components.
    # Notes:
    # - OperatorLifecycleManager is needed for 4.15 and later
    # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
    installConfigOverrides: |
      {
        "capabilities": {
          "baselineCapabilitySet": "None",
          "additionalEnabledCapabilities": [
            "NodeTuning",
            "OperatorLifecycleManager"
          ]
        }
      }
    # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
    # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
    # extraManifestPath: sno-extra-manifest
    clusterLabels:
      # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
      du-profile: "latest"
      # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
      # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
      common: true
      # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
      group-du-sno: ""
      # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
      # Normally this should match or contain the cluster name so it only applies to a single cluster
      sites : "example-sno"
    clusterNetwork:
      - cidr: 1001:1::/48
        hostPrefix: 64
    machineNetwork:
      - cidr: 1111:2222:3333:4444::/64
    serviceNetwork:
      - 1001:2::/112
    additionalNTPSources:
      - 1111:2222:3333:4444::2
    # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
    # please see Workload Partitioning Feature for a complete guide.
    cpuPartitioningMode: AllNodes
    # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
    #crTemplates:
    #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
    nodes:
      - hostName: "example-node1.example.com"
        role: "master"
        # Optionally; This can be used to configure desired BIOS setting on a host:
        #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:BB:CC:DD:EE:11"
        # Use UEFISecureBoot to enable secure boot
        bootMode: "UEFI"
        rootDeviceHints:
          deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
        # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
        ignitionConfigOverride: |
           {
            "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"
               }
              ]
            }
           }
        nodeNetwork:
          interfaces:
            - name: eno1
              macAddress: "AA:BB:CC:DD:EE:11"
          config:
            interfaces:
              - name: eno1
                type: ethernet
                state: up
                ipv4:
                  enabled: false
                ipv6:
                  enabled: true
                  address:
                  # For SNO sites with static IP addresses, the node-specific,
                  # API and Ingress IPs should all be the same and configured on
                  # the interface
                  - ip: 1111:2222:3333:4444::aaaa:1
                    prefix-length: 64
            dns-resolver:
              config:
                search:
                - example.com
                server:
                - 1111:2222:3333:4444::2
            routes:
              config:
              - destination: ::/0
                next-hop-interface: eno1
                next-hop-address: 1111:2222:3333:4444::1
                table-id: 254

DisableSnoNetworkDiag.yaml

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  annotations: {}
spec:
  disableNetworkDiagnostics: true

ReduceMonitoringFootprint.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
  annotations: {}
data:
  config.yaml: |
    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    telemeterClient:
      enabled: false
    prometheusK8s:
       retention: 24h

DefaultCatsrc.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: default-cat-source
  namespace: openshift-marketplace
  annotations:
    target.workload.openshift.io/management: '{"effect": "PreferredDuringScheduling"}'
spec:
  displayName: default-cat-source
  image: $imageUrl
  publisher: Red Hat
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 1h
status:
  connectionState:
    lastObservedState: READY

DisconnectedICSP.yaml

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
  annotations: {}
spec:
  repositoryDigestMirrors:
    - $mirrors

OperatorHub.yaml

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
  annotations: {}
spec:
  disableAllDefaultSources: true

3.2.4.4.3. 머신 구성 참조 YAML

enable-crun-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: enable-crun-master
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/master: ""
  containerRuntimeConfig:
    defaultRuntime: crun

enable-crun-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: enable-crun-worker
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  containerRuntimeConfig:
    defaultRuntime: crun

99-crio-disable-wipe-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-crio-disable-wipe-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,W2NyaW9dCmNsZWFuX3NodXRkb3duX2ZpbGUgPSAiIgo=
          mode: 420
          path: /etc/crio/crio.conf.d/99-crio-disable-wipe.toml

99-crio-disable-wipe-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-crio-disable-wipe-worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,W2NyaW9dCmNsZWFuX3NodXRkb3duX2ZpbGUgPSAiIgo=
          mode: 420
          path: /etc/crio/crio.conf.d/99-crio-disable-wipe.toml

05-kdump-config-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 05-kdump-config-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump-remove-ice-module.service
          contents: |
            [Unit]
            Description=Remove ice module when doing kdump
            Before=kdump.service
            [Service]
            Type=oneshot
            RemainAfterExit=true
            ExecStart=/usr/local/bin/kdump-remove-ice-module.sh
            [Install]
            WantedBy=multi-user.target
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvdXNyL2Jpbi9lbnYgYmFzaAoKIyBUaGlzIHNjcmlwdCByZW1vdmVzIHRoZSBpY2UgbW9kdWxlIGZyb20ga2R1bXAgdG8gcHJldmVudCBrZHVtcCBmYWlsdXJlcyBvbiBjZXJ0YWluIHNlcnZlcnMuCiMgVGhpcyBpcyBhIHRlbXBvcmFyeSB3b3JrYXJvdW5kIGZvciBSSEVMUExBTi0xMzgyMzYgYW5kIGNhbiBiZSByZW1vdmVkIHdoZW4gdGhhdCBpc3N1ZSBpcwojIGZpeGVkLgoKc2V0IC14CgpTRUQ9Ii91c3IvYmluL3NlZCIKR1JFUD0iL3Vzci9iaW4vZ3JlcCIKCiMgb3ZlcnJpZGUgZm9yIHRlc3RpbmcgcHVycG9zZXMKS0RVTVBfQ09ORj0iJHsxOi0vZXRjL3N5c2NvbmZpZy9rZHVtcH0iClJFTU9WRV9JQ0VfU1RSPSJtb2R1bGVfYmxhY2tsaXN0PWljZSIKCiMgZXhpdCBpZiBmaWxlIGRvZXNuJ3QgZXhpc3QKWyAhIC1mICR7S0RVTVBfQ09ORn0gXSAmJiBleGl0IDAKCiMgZXhpdCBpZiBmaWxlIGFscmVhZHkgdXBkYXRlZAoke0dSRVB9IC1GcSAke1JFTU9WRV9JQ0VfU1RSfSAke0tEVU1QX0NPTkZ9ICYmIGV4aXQgMAoKIyBUYXJnZXQgbGluZSBsb29rcyBzb21ldGhpbmcgbGlrZSB0aGlzOgojIEtEVU1QX0NPTU1BTkRMSU5FX0FQUEVORD0iaXJxcG9sbCBucl9jcHVzPTEgLi4uIGhlc3RfZGlzYWJsZSIKIyBVc2Ugc2VkIHRvIG1hdGNoIGV2ZXJ5dGhpbmcgYmV0d2VlbiB0aGUgcXVvdGVzIGFuZCBhcHBlbmQgdGhlIFJFTU9WRV9JQ0VfU1RSIHRvIGl0CiR7U0VEfSAtaSAncy9eS0RVTVBfQ09NTUFORExJTkVfQVBQRU5EPSJbXiJdKi8mICcke1JFTU9WRV9JQ0VfU1RSfScvJyAke0tEVU1QX0NPTkZ9IHx8IGV4aXQgMAo=
          mode: 448
          path: /usr/local/bin/kdump-remove-ice-module.sh

05-kdump-config-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 05-kdump-config-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump-remove-ice-module.service
          contents: |
            [Unit]
            Description=Remove ice module when doing kdump
            Before=kdump.service
            [Service]
            Type=oneshot
            RemainAfterExit=true
            ExecStart=/usr/local/bin/kdump-remove-ice-module.sh
            [Install]
            WantedBy=multi-user.target
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvdXNyL2Jpbi9lbnYgYmFzaAoKIyBUaGlzIHNjcmlwdCByZW1vdmVzIHRoZSBpY2UgbW9kdWxlIGZyb20ga2R1bXAgdG8gcHJldmVudCBrZHVtcCBmYWlsdXJlcyBvbiBjZXJ0YWluIHNlcnZlcnMuCiMgVGhpcyBpcyBhIHRlbXBvcmFyeSB3b3JrYXJvdW5kIGZvciBSSEVMUExBTi0xMzgyMzYgYW5kIGNhbiBiZSByZW1vdmVkIHdoZW4gdGhhdCBpc3N1ZSBpcwojIGZpeGVkLgoKc2V0IC14CgpTRUQ9Ii91c3IvYmluL3NlZCIKR1JFUD0iL3Vzci9iaW4vZ3JlcCIKCiMgb3ZlcnJpZGUgZm9yIHRlc3RpbmcgcHVycG9zZXMKS0RVTVBfQ09ORj0iJHsxOi0vZXRjL3N5c2NvbmZpZy9rZHVtcH0iClJFTU9WRV9JQ0VfU1RSPSJtb2R1bGVfYmxhY2tsaXN0PWljZSIKCiMgZXhpdCBpZiBmaWxlIGRvZXNuJ3QgZXhpc3QKWyAhIC1mICR7S0RVTVBfQ09ORn0gXSAmJiBleGl0IDAKCiMgZXhpdCBpZiBmaWxlIGFscmVhZHkgdXBkYXRlZAoke0dSRVB9IC1GcSAke1JFTU9WRV9JQ0VfU1RSfSAke0tEVU1QX0NPTkZ9ICYmIGV4aXQgMAoKIyBUYXJnZXQgbGluZSBsb29rcyBzb21ldGhpbmcgbGlrZSB0aGlzOgojIEtEVU1QX0NPTU1BTkRMSU5FX0FQUEVORD0iaXJxcG9sbCBucl9jcHVzPTEgLi4uIGhlc3RfZGlzYWJsZSIKIyBVc2Ugc2VkIHRvIG1hdGNoIGV2ZXJ5dGhpbmcgYmV0d2VlbiB0aGUgcXVvdGVzIGFuZCBhcHBlbmQgdGhlIFJFTU9WRV9JQ0VfU1RSIHRvIGl0CiR7U0VEfSAtaSAncy9eS0RVTVBfQ09NTUFORExJTkVfQVBQRU5EPSJbXiJdKi8mICcke1JFTU9WRV9JQ0VfU1RSfScvJyAke0tEVU1QX0NPTkZ9IHx8IGV4aXQgMAo=
          mode: 448
          path: /usr/local/bin/kdump-remove-ice-module.sh

06-kdump-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 06-kdump-enable-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump.service
  kernelArguments:
    - crashkernel=512M

06-kdump-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 06-kdump-enable-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump.service
  kernelArguments:
    - crashkernel=512M

01-container-mount-ns-and-kubelet-conf-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: container-mount-namespace-and-kubelet-conf-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKCmRlYnVnKCkgewogIGVjaG8gJEAgPiYyCn0KCnVzYWdlKCkgewogIGVjaG8gVXNhZ2U6ICQoYmFzZW5hbWUgJDApIFVOSVQgW2VudmZpbGUgW3Zhcm5hbWVdXQogIGVjaG8KICBlY2hvIEV4dHJhY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCBFeGVjU3RhcnQgc3RhbnphIGZyb20gdGhlIGdpdmVuIHN5c3RlbWQgdW5pdCBhbmQgcmV0dXJuIGl0IHRvIHN0ZG91dAogIGVjaG8KICBlY2hvICJJZiAnZW52ZmlsZScgaXMgcHJvdmlkZWQsIHB1dCBpdCBpbiB0aGVyZSBpbnN0ZWFkLCBhcyBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZSBuYW1lZCAndmFybmFtZSciCiAgZWNobyAiRGVmYXVsdCAndmFybmFtZScgaXMgRVhFQ1NUQVJUIGlmIG5vdCBzcGVjaWZpZWQiCiAgZXhpdCAxCn0KClVOSVQ9JDEKRU5WRklMRT0kMgpWQVJOQU1FPSQzCmlmIFtbIC16ICRVTklUIHx8ICRVTklUID09ICItLWhlbHAiIHx8ICRVTklUID09ICItaCIgXV07IHRoZW4KICB1c2FnZQpmaQpkZWJ1ZyAiRXh0cmFjdGluZyBFeGVjU3RhcnQgZnJvbSAkVU5JVCIKRklMRT0kKHN5c3RlbWN0bCBjYXQgJFVOSVQgfCBoZWFkIC1uIDEpCkZJTEU9JHtGSUxFI1wjIH0KaWYgW1sgISAtZiAkRklMRSBdXTsgdGhlbgogIGRlYnVnICJGYWlsZWQgdG8gZmluZCByb290IGZpbGUgZm9yIHVuaXQgJFVOSVQgKCRGSUxFKSIKICBleGl0CmZpCmRlYnVnICJTZXJ2aWNlIGRlZmluaXRpb24gaXMgaW4gJEZJTEUiCkVYRUNTVEFSVD0kKHNlZCAtbiAtZSAnL15FeGVjU3RhcnQ9LipcXCQvLC9bXlxcXSQvIHsgcy9eRXhlY1N0YXJ0PS8vOyBwIH0nIC1lICcvXkV4ZWNTdGFydD0uKlteXFxdJC8geyBzL15FeGVjU3RhcnQ9Ly87IHAgfScgJEZJTEUpCgppZiBbWyAkRU5WRklMRSBdXTsgdGhlbgogIFZBUk5BTUU9JHtWQVJOQU1FOi1FWEVDU1RBUlR9CiAgZWNobyAiJHtWQVJOQU1FfT0ke0VYRUNTVEFSVH0iID4gJEVOVkZJTEUKZWxzZQogIGVjaG8gJEVYRUNTVEFSVApmaQo=
          mode: 493
          path: /usr/local/bin/extractExecStart
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKbnNlbnRlciAtLW1vdW50PS9ydW4vY29udGFpbmVyLW1vdW50LW5hbWVzcGFjZS9tbnQgIiRAIgo=
          mode: 493
          path: /usr/local/bin/nsenterCmns
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Manages a mount namespace that both kubelet and crio can use to share their container-specific mounts

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            RuntimeDirectory=container-mount-namespace
            Environment=RUNTIME_DIRECTORY=%t/container-mount-namespace
            Environment=BIND_POINT=%t/container-mount-namespace/mnt
            ExecStartPre=bash -c "findmnt ${RUNTIME_DIRECTORY} || mount --make-unbindable --bind ${RUNTIME_DIRECTORY} ${RUNTIME_DIRECTORY}"
            ExecStartPre=touch ${BIND_POINT}
            ExecStart=unshare --mount=${BIND_POINT} --propagation slave mount --make-rshared /
            ExecStop=umount -R ${RUNTIME_DIRECTORY}
          name: container-mount-namespace.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART}"
              name: 90-container-mount-namespace.conf
          name: crio.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART} --housekeeping-interval=30s"
              name: 90-container-mount-namespace.conf
            - contents: |
                [Service]
                Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
                Environment="OPENSHIFT_EVICTION_MONITORING_PERIOD_DURATION=30s"
              name: 30-kubelet-interval-tuning.conf
          name: kubelet.service

01-container-mount-ns-and-kubelet-conf-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: container-mount-namespace-and-kubelet-conf-worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKCmRlYnVnKCkgewogIGVjaG8gJEAgPiYyCn0KCnVzYWdlKCkgewogIGVjaG8gVXNhZ2U6ICQoYmFzZW5hbWUgJDApIFVOSVQgW2VudmZpbGUgW3Zhcm5hbWVdXQogIGVjaG8KICBlY2hvIEV4dHJhY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCBFeGVjU3RhcnQgc3RhbnphIGZyb20gdGhlIGdpdmVuIHN5c3RlbWQgdW5pdCBhbmQgcmV0dXJuIGl0IHRvIHN0ZG91dAogIGVjaG8KICBlY2hvICJJZiAnZW52ZmlsZScgaXMgcHJvdmlkZWQsIHB1dCBpdCBpbiB0aGVyZSBpbnN0ZWFkLCBhcyBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZSBuYW1lZCAndmFybmFtZSciCiAgZWNobyAiRGVmYXVsdCAndmFybmFtZScgaXMgRVhFQ1NUQVJUIGlmIG5vdCBzcGVjaWZpZWQiCiAgZXhpdCAxCn0KClVOSVQ9JDEKRU5WRklMRT0kMgpWQVJOQU1FPSQzCmlmIFtbIC16ICRVTklUIHx8ICRVTklUID09ICItLWhlbHAiIHx8ICRVTklUID09ICItaCIgXV07IHRoZW4KICB1c2FnZQpmaQpkZWJ1ZyAiRXh0cmFjdGluZyBFeGVjU3RhcnQgZnJvbSAkVU5JVCIKRklMRT0kKHN5c3RlbWN0bCBjYXQgJFVOSVQgfCBoZWFkIC1uIDEpCkZJTEU9JHtGSUxFI1wjIH0KaWYgW1sgISAtZiAkRklMRSBdXTsgdGhlbgogIGRlYnVnICJGYWlsZWQgdG8gZmluZCByb290IGZpbGUgZm9yIHVuaXQgJFVOSVQgKCRGSUxFKSIKICBleGl0CmZpCmRlYnVnICJTZXJ2aWNlIGRlZmluaXRpb24gaXMgaW4gJEZJTEUiCkVYRUNTVEFSVD0kKHNlZCAtbiAtZSAnL15FeGVjU3RhcnQ9LipcXCQvLC9bXlxcXSQvIHsgcy9eRXhlY1N0YXJ0PS8vOyBwIH0nIC1lICcvXkV4ZWNTdGFydD0uKlteXFxdJC8geyBzL15FeGVjU3RhcnQ9Ly87IHAgfScgJEZJTEUpCgppZiBbWyAkRU5WRklMRSBdXTsgdGhlbgogIFZBUk5BTUU9JHtWQVJOQU1FOi1FWEVDU1RBUlR9CiAgZWNobyAiJHtWQVJOQU1FfT0ke0VYRUNTVEFSVH0iID4gJEVOVkZJTEUKZWxzZQogIGVjaG8gJEVYRUNTVEFSVApmaQo=
          mode: 493
          path: /usr/local/bin/extractExecStart
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKbnNlbnRlciAtLW1vdW50PS9ydW4vY29udGFpbmVyLW1vdW50LW5hbWVzcGFjZS9tbnQgIiRAIgo=
          mode: 493
          path: /usr/local/bin/nsenterCmns
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Manages a mount namespace that both kubelet and crio can use to share their container-specific mounts

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            RuntimeDirectory=container-mount-namespace
            Environment=RUNTIME_DIRECTORY=%t/container-mount-namespace
            Environment=BIND_POINT=%t/container-mount-namespace/mnt
            ExecStartPre=bash -c "findmnt ${RUNTIME_DIRECTORY} || mount --make-unbindable --bind ${RUNTIME_DIRECTORY} ${RUNTIME_DIRECTORY}"
            ExecStartPre=touch ${BIND_POINT}
            ExecStart=unshare --mount=${BIND_POINT} --propagation slave mount --make-rshared /
            ExecStop=umount -R ${RUNTIME_DIRECTORY}
          name: container-mount-namespace.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART}"
              name: 90-container-mount-namespace.conf
          name: crio.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART} --housekeeping-interval=30s"
              name: 90-container-mount-namespace.conf
            - contents: |
                [Service]
                Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
                Environment="OPENSHIFT_EVICTION_MONITORING_PERIOD_DURATION=30s"
              name: 30-kubelet-interval-tuning.conf
          name: kubelet.service

99-sync-time-once-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-sync-time-once-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Sync time once
            After=network.service
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service

99-sync-time-once-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-sync-time-once-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Sync time once
            After=network.service
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service

03-sctp-machine-config-master.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: load-sctp-module-master
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

03-sctp-machine-config-worker.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: load-sctp-module-worker
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

3.2.5. Telco RAN DU 참조 구성 소프트웨어 사양

다음 정보는 Intelco RAN DU 참조 설계 사양(RDS) 검증된 소프트웨어 버전을 설명합니다.

3.2.5.1. Telco RAN DU 4.14 검증 소프트웨어 구성 요소

Red Hat telco RAN DU 4.14 솔루션은 OpenShift Container Platform 관리 클러스터 및 허브 클러스터에 대해 다음과 같은 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.

표 3.8. Telco RAN DU 관리 클러스터 검증 소프트웨어 구성 요소
Component소프트웨어 버전

관리형 클러스터 버전

4.14

Cluster Logging Operator

5.7

Local Storage Operator

4.14

PTP Operator

4.14

SRIOV Operator

4.14

Node Tuning Operator

4.14

Logging Operator

4.14

SRIOV-FEC Operator

2.7

표 3.9. hub 클러스터 검증 소프트웨어 구성 요소
Component소프트웨어 버전

hub 클러스터 버전

4.14

GitOps ZTP 플러그인

4.14

Red Hat Advanced Cluster Management(RHACM)

2.9, 2.10

Red Hat OpenShift GitOps

1.9, 1.10

토폴로지 인식 라이프사이클 관리자(TALM)

4.14

3.3. Telco 코어 참조 설계 사양

3.3.1. telco core 4.14 참조 설계 개요

Telco 코어 참조 설계 사양(RDS)은 상용 하드웨어에서 실행되는 OpenShift Container Platform 클러스터를 구성하여 통신 핵심 워크로드를 호스팅합니다.

3.3.1.1. 통신 코어를 위한 OpenShift Container Platform 4.14 기능

OpenShift Container Platform 4.14에 포함되어 telco core reference design specification (RDS)에 의해 활용되는 다음 기능이 추가되거나 업데이트되었습니다.

표 3.10. OpenShift Container Platform 4.14의 telco core를 위한 새로운 기능
기능설명

Cryostat CNI 플러그인을 사용하여 커널 액세스로 DPDK(rootless Data Plane Development Kit) 워크로드 실행 지원

커널에 트래픽을 삽입하는 DPDK 애플리케이션은 Cryostat CNI 플러그인을 사용하여 권한이 없는 Pod에서 실행할 수 있습니다.

OVS에 예약되지 않은 CPU의 동적 사용

이번 릴리스에서는 OVS(Open vSwitch) 네트워킹 스택에서 예약되지 않은 CPU를 동적으로 사용할 수 있습니다. 예약되지 않은 CPU의 동적 사용은 기본적으로 CPU 관리자 정책이 static 으로 설정된 성능 조정 클러스터에서 발생합니다. 예약되지 않은 사용 가능한 CPU를 동적으로 사용하면 OVS의 컴퓨팅 리소스를 최대화하고 수요가 많은 기간에 워크로드의 네트워크 대기 시간을 최소화합니다. OVS는 Guaranteed QoS Pod의 컨테이너에 할당된 격리된 CPU를 사용할 수 없습니다. 이와 같이 분리하면 중요한 애플리케이션 워크로드에 대한 중단을 방지할 수 있습니다.

각 Pod의 C-state를 더 많이 제어 가능

PerformanceProfile 은 Pod의 C 상태를 더 많이 제어하는 perPodPowerManagement 를 지원합니다. 이제 C-상태를 완전히 비활성화하는 대신 C 상태의 경우 최대 대기 시간을 microseconds로 지정할 수 있습니다. cpu-c-states.crio.io 주석에서 이 옵션을 구성하면 완전히 비활성화하지 않고 몇 개의 C-state를 활성화하여 우선 순위가 높은 애플리케이션에 대한 전원 절감을 최적화하는 데 도움이 됩니다.

NUMA 인식 스케줄링의 SR-IOV 네트워크 토폴로지 제외

SR-IOV 네트워크의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자에게 제외할 수 있습니다. SR-IOV 네트워크의 NUMA 노드를 알리지 않으면 NUMA 인식 Pod 예약 중에 더 유연한 SR-IOV 네트워크 배포를 허용할 수 있습니다.

예를 들어 일부 시나리오에서는 Pod 배포 방법에 대한 유연성을 원합니다. 토폴로지 관리자는 Pod의 SR-IOV 네트워크 리소스에 대한 NUMA 노드 힌트를 제공하지 않기 때문에 토폴로지 관리자는 SR-IOV 네트워크 리소스 및 Pod CPU 및 메모리 리소스를 다른 NUMA 노드에 배포할 수 있습니다. 이전 OpenShift Container Platform 릴리스에서는 토폴로지 관리자가 동일한 NUMA 노드에 모든 리소스를 배치하려고 했습니다.

로드 밸런서 뒤의 Pod에 대한 송신 트래픽을 관리하는 송신 서비스 리소스(기술 프리뷰)

이번 업데이트를 통해 EgressService CR(사용자 정의 리소스)을 사용하여 로드 밸런서 서비스 뒤의 Pod의 송신 트래픽을 관리할 수 있습니다.

EgressService CR을 사용하여 다음과 같은 방식으로 송신 트래픽을 관리할 수 있습니다.

  • 로드 밸런서 서비스의 IP 주소를 로드 밸런서 서비스 뒤의 포드의 송신 트래픽 소스 IP 주소로 할당합니다.
  • 로드 밸런서 뒤의 포드의 송신 트래픽을 기본 노드 네트워크와 다른 네트워크로 구성합니다.
  • 송신 서비스 구성

3.3.2. Telco core 4.14 사용 모델 개요

Telco 코어 참조 설계 사양(RDS)은 신호 및 집계와 같은 컨트롤 플레인 기능을 포함하여 대규모 통신 애플리케이션을 지원하는 플랫폼을 설명합니다. 또한 몇 가지 중앙 집중식 데이터 플레인 기능(예: 사용자 플레인 기능(UPF))이 포함되어 있습니다. 이러한 기능에는 일반적으로 확장성, 복잡한 네트워킹 지원, 탄력적 소프트웨어 정의 스토리지 및 RAN과 같은 대규모 배포보다 제한된 성능 요구 사항이 필요합니다.

Telco core 사용 모델 아키텍처

Use model architecture

통신 핵심 기능에 대한 네트워킹 사전 요구 사항은 다양하며 다양한 네트워킹 속성 및 성능 벤치마크를 포함합니다. IPv6는 필수이며 이중 스택 구성이 우선합니다. 특정 기능에는 최대 처리량 및 트랜잭션 속도가 필요하며 DPDK와 같은 사용자 플레인 네트워킹 지원이 필요합니다. 다른 기능은 기존의 클라우드 네이티브 패턴을 준수하고 OVN-K, 커널 네트워킹 및 로드 밸런싱과 같은 솔루션을 사용할 수 있습니다.

Telco 코어 클러스터는 RT(Non real-time) 커널로 구성된 작업자 노드가 있는 표준 3개의 컨트롤 플레인 클러스터로 구성됩니다. 다양한 네트워킹 및 성능 요구 사항이 있는 워크로드를 지원하기 위해 MachineConfigPool CR을 사용하여 작업자 노드를 분할합니다. 예를 들어, 이는 비사용자 데이터 플레인 노드를 높은 처리량 노드에서 분리하기 위해 수행됩니다. 필요한 통신 운영 기능을 지원하기 위해 클러스터에는 표준 OLM(Operator Lifecycle Manager) Day 2 Operator 세트가 설치되어 있습니다.

3.3.2.1. 공통 기준 모델

다음 구성 및 사용 모델 설명은 모든 통신 코어 사용 사례에 적용됩니다.

Cluster

클러스터는 다음 요구 사항을 준수합니다.

  • 고가용성 (3+ 감독 노드) 컨트롤 플레인
  • 예약할 수 없는 슈퍼바이저 노드
스토리지
코어 사용 사례에는 외부 OpenShift Data Foundation에서 제공하는 영구 스토리지가 필요합니다. 자세한 내용은 "참조 코어 설계 구성 요소"의 "스토리지" 섹션을 참조하십시오.
네트워킹

Telco 핵심 클러스터 네트워킹은 다음 요구 사항을 준수합니다.

  • 듀얼 스택 IPv4/IPv6
  • 완전히 연결이 끊긴: 클러스터는 라이프사이클의 어느 시점에서도 공용 네트워킹에 액세스할 수 없습니다.
  • 다중 네트워크: 세그먼트화된 네트워킹은 OAM, 신호 처리 및 스토리지 트래픽 간에 격리를 제공합니다.
  • 클러스터 네트워크 유형: IPv6 지원에 OVN-Kubernetes가 필요합니다.

코어 클러스터에는 기본 RHCOS, SR-IOV Operator, 로드 밸런서 및 다음 "네트워크" 섹션에 설명된 기타 구성 요소에서 지원되는 여러 네트워킹 계층이 있습니다. 높은 수준에서 이러한 계층은 다음과 같습니다.

  • 클러스터 네트워킹: 클러스터 네트워크 구성이 정의되고 설치 구성을 통해 적용됩니다. 구성 업데이트는 NMState Operator를 통해 2일 차에 수행할 수 있습니다. 초기 구성을 사용하여 다음을 설정할 수 있습니다.

    • 호스트 인터페이스 구성
    • A/A Bonding(LACP(Link Aggregation Control Protocol))
  • 보조 또는 추가 네트워크: OpenShift CNI는 네트워크 additionalNetworks 또는 NetworkAttachmentDefinition CR을 통해 구성됩니다.

    • MACVLAN
  • 애플리케이션 워크로드: 사용자 플레인 네트워킹이 클라우드 네이티브 네트워크 기능(CNF)에서 실행되고 있습니다.
서비스 메시
통신 CNF의 서비스 메시 사용은 매우 일반적입니다. 모든 코어 클러스터에는 Service Mesh 구현이 포함되어야 합니다. 서비스 메시 구현 및 구성은 이 사양의 범위를 벗어납니다.
3.3.2.1.1. 엔지니어링 고려 사항 일반적인 사용 모델

다음 엔지니어링 고려 사항은 일반적인 사용 모델과 관련이 있습니다.

작업자 노드
  • Intel 3세대 Xeon(IceLake) 프로세서 이상에서 작업자 노드가 실행됩니다. 또는 Skylake 또는 이전 프로세서를 사용하는 경우 Spectre와 같은 보안 취약점에 대한 완화 조치를 비활성화해야 합니다. 이렇게 하지 않으면 트랜잭션 성능이 40%를 크게 줄일 수 있습니다.
  • IRQ Balancing은 작업자 노드에서 활성화됩니다. PerformanceProfilegloballyDisableIrqLoadBalancing: false 를 설정합니다. 보장된 QoS Pod는 "참조 코어 설계 구성 요소" 섹션의 "CPU 파티셔닝 및 성능 튜닝" 섹션에 설명된 대로 격리를 보장하기 위해 주석이 지정됩니다.
모든 노드
  • Hyper-Threading은 모든 노드에서 사용 가능
  • CPU 아키텍처는 x86_64 전용입니다.
  • 노드가 주식 (RT가 아닌) 커널을 실행하고 있습니다.
  • 노드가 워크로드 파티셔닝을 위해 구성되지 않음

전원 관리와 최대 성능 간의 노드 구성의 균형은 클러스터 의 MachineConfigPool 에 따라 다릅니다. 이 구성은 MachineConfigPool 내의 모든 노드에 일관되게 유지됩니다.

CPU 파티셔닝
CPU 파티션은 PerformanceProfile을 사용하여 구성되며 MachineConfigPool 에 따라 적용됩니다. "참조 코어 설계 구성 요소"의 "CPU 파티셔닝 및 성능 튜닝" 섹션을 참조하십시오.
3.3.2.1.2. 애플리케이션 워크로드

핵심 클러스터에서 실행되는 애플리케이션 워크로드에는 고성능 네트워킹 CNF와 기존의 최적의 Pod 워크로드 또는 버스트 Pod 워크로드가 혼합되어 있을 수 있습니다.

보장된 QoS 예약은 성능 또는 보안 요구 사항으로 인해 CPU를 독점적 또는 전용으로 사용해야 하는 Pod에서 사용할 수 있습니다. 일반적으로 DPDK와 함께 사용자 플레인 네트워킹을 활용하는 고성능 및 대기 시간에 민감한 CNF(Cloud Native Functions)를 호스팅하는 Pod는 전체 CPU의 독점적인 사용률이 필요합니다. 이는 노드 튜닝 및 QoS(Quality of Service) 스케줄링을 통해 수행됩니다. CPU를 독점적으로 사용해야 하는 Pod의 경우 하이퍼 스레딩 시스템의 잠재적 영향을 인식하고 전체 코어 (2 하이퍼스레드)를 Pod에 할당해야 하는 경우 2 CPU의 배수를 요청하도록 구성합니다.

높은 처리량과 짧은 대기 시간 네트워킹이 필요하지 않은 네트워크 기능을 실행하는 Pod는 일반적으로 best-effort 또는 burstable QoS로 예약되며 전용 또는 분리된 CPU 코어가 필요하지 않습니다.

제한 설명
  • CNF 애플리케이션은 최신 버전의 Red Hat Best Practices for Kubernetes 가이드를 준수해야 합니다.
  • best-effort 및 burstable QoS Pod가 혼합된 경우

    • 보장된 QoS Pod를 사용할 수 있지만 PerformanceProfile 에서 예약 및 분리된 CPU의 올바른 구성이 필요합니다.
    • 보장된 QoS Pod에는 CPU를 완전히 분리하기 위한 주석이 포함되어야 합니다.
    • 최상의 작업 및 버스블 Pod는 CPU를 독점적으로 사용할 수 없습니다. 다른 워크로드, 운영 체제 데몬 또는 커널 작업에서 워크로드를 선점할 수 있습니다.
  • 실행 가능한 대안이 없는 한 exec 프로브를 피해야 합니다.

    • CNF에서 CPU 고정을 사용하는 경우 exec 프로브를 사용하지 마십시오.
    • 다른 프로브 구현(예: httpGet/tcpSocket )을 사용해야 합니다.
참고

시작 프로브에는 지속적인 상태 작업 중에 최소한의 리소스가 필요합니다. exec 프로브의 제한은 주로 liveness 및 readiness 프로브에 적용됩니다.

워크로드 신호
  • 신호 처리 워크로드는 일반적으로 SCTP, REST, gRPC 또는 유사한 TCP 또는 UDP 프로토콜을 사용합니다.
  • TPS(초당 트랜잭션)는 MACVLAN 또는 SR-IOV로 구성된 보조 CNI(multus)를 사용하여 수십만 개의 순서로 사용됩니다.
  • 전송 워크로드는 guaranteed 또는 burstable QoS가 있는 Pod에서 실행됩니다.

3.3.3. Telco 핵심 참조 설계 구성 요소

다음 섹션에서는 통신 핵심 워크로드를 실행하기 위해 클러스터를 구성하고 배포하는 데 사용하는 다양한 OpenShift Container Platform 구성 요소 및 구성에 대해 설명합니다.

3.3.3.1. CPU 파티셔닝 및 성능 튜닝
이번 릴리스의 새로운 기능
OVS(Open vSwitch)는 CPU 파티셔닝에서 제거됩니다. OVS는 네트워크 트래픽 요구에 자동으로 조정하기 위해 cpuset을 동적으로 관리합니다. 사용자는 더 이상 기본 컨테이너 네트워크 인터페이스(CNI)에서 높은 네트워크 처리량을 처리하기 위해 추가 CPU를 예약할 필요가 없습니다. 이러한 변경에 필요한 구성에 영향을 미치지 않습니다.
설명

CPU 파티셔닝을 사용하면 중요한 워크로드를 일반 목적, 보조 프로세스, 인터럽트 및 드라이버 작업 대기열과 분리하여 성능과 대기 시간을 개선할 수 있습니다. 이러한 보조 프로세스에 할당된 CPU를 다음 섹션에서 예약해야 합니다. 하이퍼 스레딩 시스템에서 CPU는 하나의 하이퍼스레드입니다.

자세한 내용은 인프라 및 애플리케이션 컨테이너의 CPU 제한을 참조하십시오.

시스템 수준 성능 구성. 권장 설정은 짧은 대기 시간과 고성능에 대한 호스트 펌웨어 구성 을 참조하십시오.

제한 및 요구사항
  • 운영 체제에는 커널 네트워킹을 포함한 모든 지원 작업을 수행하려면 일정 양의 CPU가 필요합니다.

    • DPDK(사용자 플레인 네트워킹 애플리케이션)만 있는 시스템에는 운영 체제 및 인프라 구성 요소를 위해 예약된 코어(2개의 하이퍼 스레딩)가 하나 이상 필요합니다.
  • 하이퍼 스레딩이 활성화된 시스템은 항상 모든 코어 형제 스레드를 동일한 CPU 풀에 배치해야 합니다.
  • 예약 및 분리된 코어 세트에는 모든 CPU 코어가 포함되어야 합니다.
  • 각 NUMA 노드의 코어 0은 예약된 CPU 세트에 포함되어야 합니다.
  • 격리된 코어는 인터럽트의 영향을 받을 수 있습니다. 보장된 QoS Pod에 CPU를 완전히 사용해야 하는 경우 다음 주석을 Pod에 연결해야 합니다.

    cpu-load-balancing.crio.io: "disable"
    cpu-quota.crio.io: "disable"
    irq-load-balancing.crio.io: "disable"
  • PerformanceProfile.workloadHints.perPodPowerManagement 를 사용하여 Pod별 전원 관리를 활성화하면 보장된 QoS Pod에 CPU를 완전히 사용해야 하는 경우 다음 주석도 Pod에 연결해야 합니다.

    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
엔지니어링 고려 사항
  • 필요한 최소 예약 용량(systemReserved)은 " 얼마나 많은 CPU 및 메모리가 OCP 4 노드에서 시스템을 예약하는 것이 좋습니다."의 지침에 따라 확인할 수 있습니다.
  • 실제 필수 예약된 CPU 용량은 클러스터 구성 및 워크로드 특성에 따라 다릅니다.
  • 이 예약된 CPU 값은 전체 코어(2하이퍼 스레드) 정렬으로 반올림해야 합니다.
  • CPU 파티셔닝을 변경하면 MCP의 노드를 드레이닝하고 재부팅합니다.
  • 예약된 CPU는 OpenShift 노드의 할당 가능한 용량에서 제거되므로 예약된 CPU는 Pod 밀도를 줄입니다.
  • 워크로드를 실시간으로 사용할 수 있는 경우 실시간 워크로드 힌트를 활성화해야 합니다.
  • IIRQ(Interrupt Request) 선호도 지원이 없는 하드웨어는 분리된 CPU에 영향을 미칩니다. 보장된 CPU QoS가 있는 Pod에서 할당된 CPU를 완전히 사용하려면 서버의 모든 하드웨어가 IRQ 선호도를 지원해야 합니다.
3.3.3.2. 서비스 메시
설명
통신 핵심 CNF에는 일반적으로 서비스 메시 구현이 필요합니다. 필요한 특정 기능 및 성능은 애플리케이션에 따라 다릅니다. 서비스 메시 구현 및 구성을 선택하는 것은 이 문서의 범위를 벗어납니다. Pod 네트워킹에 도입된 추가 대기 시간을 포함하여 클러스터 리소스 사용률 및 성능에 대한 서비스 메시의 영향은 전체 솔루션 엔지니어링에서 고려되어야 합니다.
3.3.3.3. 네트워킹

OpenShift Container Platform 네트워킹은 클러스터가 하나 이상의 하이브리드 클러스터의 네트워크 트래픽을 관리하는 데 필요한 고급 네트워킹 관련 기능을 사용하여 Kubernetes 네트워킹을 확장하는 기능, 플러그인 및 고급 네트워킹 기능으로 구성된 에코시스템입니다.

추가 리소스

3.3.3.3.1. CNO(Cluster Network Operator)
이번 릴리스의 새로운 기능
해당 없음
설명

CNO는 OpenShift Container Platform 클러스터 설치 중에 기본 OVN-Kubernetes 네트워크 플러그인을 포함하여 클러스터 네트워크 구성 요소를 배포하고 관리합니다. 기본 인터페이스 MTU 설정, OVN 게이트웨이 모드를 구성하여 Pod 송신에 노드 라우팅 테이블 및 MACVLAN과 같은 추가 보조 네트워크를 사용할 수 있습니다.

네트워크 트래픽 분리를 지원하기 위해 CNO를 통해 여러 네트워크 인터페이스가 구성됩니다. 이러한 인터페이스로의 트래픽은 NMState Operator를 사용하여 적용되는 정적 경로를 통해 구성됩니다. Pod 트래픽이 올바르게 라우팅되도록 하려면 OVN-K는 routingViaHost 옵션을 활성화하여 구성됩니다. 이 설정은 Pod 송신 트래픽에 대해 OVN이 아닌 커널 라우팅 테이블 및 적용된 정적 경로를 사용합니다.

Whereabouts CNI 플러그인은 DHCP 서버를 사용하지 않고 추가 Pod 네트워크 인터페이스에 대한 동적 IPv4 및 IPv6 주소를 제공하는 데 사용됩니다.

제한 및 요구사항
  • IPv6 지원에는 OVN-Kubernetes가 필요합니다.
  • 대규모 MTU 클러스터 지원을 사용하려면 연결된 네트워크 장치를 동일하거나 더 큰 값으로 설정해야 합니다.
엔지니어링 고려 사항
  • Pod 송신 트래픽은 routingViaHost 옵션을 사용하여 커널 라우팅 테이블에 의해 처리됩니다. 적절한 정적 경로를 호스트에 구성해야 합니다.
3.3.3.3.2. 로드 밸런서
이번 릴리스의 새로운 기능
해당 없음
설명

MetalLB는 표준 라우팅 프로토콜을 사용하여 베어 메탈 Kubernetes 클러스터에 대한 로드 밸런서 구현입니다. Kubernetes 서비스는 클러스터의 호스트 네트워크에도 추가된 외부 IP 주소를 가져올 수 있습니다.

일부 사용 사례에는 MetalLB에서 사용할 수 없는 기능(예: 상태 저장 로드 밸런싱)이 필요할 수 있습니다. 필요한 경우 외부 타사 로드 밸런서를 사용할 수 있습니다. 외부 로드 밸런서의 선택 및 구성은 이 사양의 범위를 벗어납니다. 외부 타사 로드 밸런서를 사용하는 경우 통합 작업에는 모든 성능 및 리소스 사용률 요구 사항이 충족되는지 확인하기에 충분한 분석이 포함되어야 합니다.

제한 및 요구사항
  • MetalLB에서 상태 저장 로드 밸런싱을 지원하지 않습니다. 워크로드 CNF에 대한 요구 사항인 경우 대체 로드 밸런서 구현을 사용해야 합니다.
  • 네트워킹 인프라는 클라이언트에서 클러스터의 호스트 네트워크로 외부 IP 주소를 라우팅할 수 있는지 확인해야 합니다.
엔지니어링 고려 사항
  • MetalLB는 코어 사용 사례 모델에만 BGP 모드에서 사용됩니다.
  • 코어 사용 모델의 경우 MetalLB는 로컬 게이트웨이 모드에서 사용되는 OVN-Kubernetes 네트워크 공급자에서만 지원됩니다. "Cluster Network Operator" 섹션의 routingViaHost 를 참조하십시오.
  • MetalLB의 BGP 구성은 네트워크 및 피어의 요구 사항에 따라 다릅니다.
  • 주소 풀은 필요에 따라 구성할 수 있으므로 주소, 집계 길이, 자동 할당 및 기타 관련 매개 변수의 변형을 허용합니다.
  • BFD(Bi-Directional Forwarding Detection) 프로파일의 매개 변수의 값은 기본값에 가깝게 유지되어야 합니다. 값이 더 짧은 경우 false 음수가 되고 성능에 영향을 미칠 수 있습니다.
3.3.3.3.3. SR-IOV
이번 릴리스의 새로운 기능
해당 없음
설명
SR-IOV를 사용하면 물리적 네트워크 인터페이스(PF)를 여러 VF(가상 기능)로 나눌 수 있습니다. 그러면 Pod를 분리한 상태로 유지하면서 더 높은 처리량 성능을 달성하기 위해 VFS를 여러 Pod에 할당할 수 있습니다. SR-IOV Network Operator는 SR-IOV CNI, 네트워크 장치 플러그인 및 SR-IOV 스택의 기타 구성 요소를 프로비저닝하고 관리합니다.
제한 및 요구사항
  • 지원되는 네트워크 인터페이스 컨트롤러는 OCP 지원 SR-IOV 장치에나열되어 있습니다.
  • BIOS에서 SR-IOV 및 IOMMU 활성화: SR-IOV Network Operator는 커널 명령줄에서 IOMMU를 자동으로 활성화합니다.
  • SR-IOV VF는 PF에서 링크 상태 업데이트를 수신하지 않습니다. 링크 다운 탐지가 필요한 경우 프로토콜 수준에서 수행해야 합니다.
엔지니어링 고려 사항
  • vfio 모드의 SR-IOV 인터페이스는 일반적으로 처리량 또는 짧은 대기 시간이 필요한 애플리케이션의 추가 보조 네트워크를 활성화하는 데 사용됩니다.
3.3.3.3.4. NMState Operator
이번 릴리스의 새로운 기능
해당 없음
설명
NMState Operator는 클러스터 노드에서 네트워크 구성을 수행하기 위한 Kubernetes API를 제공합니다. 보조 인터페이스에서 네트워크 인터페이스 구성, 고정 IP 및 DNS, VLAN, 트렁크, 본딩, 정적 경로, MTU를 활성화하고 보조 인터페이스에서 무차별 모드를 활성화합니다. 클러스터 노드는 각 노드의 네트워크 인터페이스 상태를 API 서버에 정기적으로 보고합니다.
제한 및 요구사항
해당 없음
엔지니어링 고려 사항
  • 초기 네트워킹 구성은 설치 CR의 NMStateConfig 콘텐츠를 사용하여 적용됩니다. NMState Operator는 네트워크 업데이트에 필요한 경우에만 사용됩니다.
  • SR-IOV 가상 기능이 호스트 네트워킹에 사용되는 경우 NodeNetworkConfigurationPolicy 를 사용하는 NMState Operator는 해당 VF 인터페이스(예: VLAN 및 MTU)를 구성하는 데 사용됩니다.
3.3.3.4. 로깅
이번 릴리스의 새로운 기능
해당 없음
설명
ClusterLogging Operator를 사용하면 원격 아카이브 및 분석을 위해 노드에서 로그를 수집 및 전달할 수 있습니다. 참조 구성은 Kafka를 사용하여 원격 아카이브에 감사 및 인프라 로그를 제공합니다.
제한 및 요구사항
해당 없음
엔지니어링 고려 사항
  • 클러스터 CPU 사용 영향은 생성된 로그 수 또는 크기와 구성된 로그 필터링 양을 기반으로 합니다.
  • 참조 구성에는 애플리케이션 로그 전달이 포함되어 있지 않습니다. 구성에 애플리케이션 로그를 포함하려면 애플리케이션 로깅 속도를 평가하고 예약된 세트에 할당된 추가 CPU 리소스를 평가해야 합니다.

추가 리소스

3.3.3.5. 전원 관리
이번 릴리스의 새로운 기능
  • Pod별 전원 관리를 사용할 때 짧은 대기 시간 Pod에 대해 C-state인 최대 대기 시간을 지정할 수 있습니다. 이전에는 Pod별로 C-states만 완전히 비활성화할 수 있었습니다.
설명
성능 프로파일 을 사용하여 고가용성, 저출력 또는 혼합(Pod별 전원 관리) 모드로 클러스터를 구성할 수 있습니다. 전원 모드를 선택하는 것은 클러스터에서 실행되는 워크로드의 특성, 특히 대기 시간에 얼마나 민감한지에 따라 달라집니다.
제한 및 요구사항
  • 전원 구성은 적절한 BIOS 구성을 사용합니다(예: C 상태 및 P-상태 활성화). 구성은 하드웨어 벤더마다 다릅니다.
엔지니어링 고려 사항
  • 대기 시간: 대기 시간에 민감한 워크로드가 요구 사항을 충족하도록 하려면 고급 구성 또는 Pod별 전원 관리 구성이 필요합니다. Pod별 전원 관리는 전용 고정 CPU가 있는 QoS Pod에서만 사용할 수 있습니다.
3.3.3.6. 스토리지
개요

클라우드 네이티브 스토리지 서비스는 Red Hat 또는 타사의 OpenShift Data Foundation을 비롯한 여러 솔루션에서 제공할 수 있습니다.

OpenShift Data Foundation은 컨테이너용 Ceph 기반 소프트웨어 정의 스토리지 솔루션입니다. 영구 및 비영구 데이터 요구 사항에 대해 동적으로 프로비저닝할 수 있는 블록 스토리지, 파일 시스템 스토리지 및 온-프레미스 개체 스토리지를 제공합니다. 통신 핵심 애플리케이션에는 영구 스토리지가 필요합니다.

참고

모든 스토리지 데이터가 이동 중에 암호화되지 않을 수 있습니다. 위험을 줄이려면 스토리지 네트워크를 다른 클러스터 네트워크와 분리합니다. 다른 클러스터 네트워크에서 스토리지 네트워크에 연결할 수 없거나 라우팅할 수 없어야 합니다. 스토리지 네트워크에 직접 연결된 노드만 액세스할 수 있어야 합니다.

3.3.3.6.1. OpenShift Data Foundation
이번 릴리스의 새로운 기능
해당 없음
설명
Red Hat OpenShift Data Foundation은 컨테이너용 소프트웨어 정의 스토리지 서비스입니다. Telco 핵심 클러스터의 경우 애플리케이션 워크로드 클러스터 외부에서 실행되는 OpenShift Data Foundation 스토리지 서비스에서 스토리지 지원을 제공합니다. OpenShift Data Foundation은 보조 CNI 네트워크를 사용하여 스토리지 트래픽 분리를 지원합니다.
제한 및 요구사항
엔지니어링 고려 사항
  • OpenShift Data Foundation 네트워크 트래픽은 예를 들어 VLAN 격리를 사용하여 전용 네트워크의 다른 트래픽과 격리해야 합니다.
3.3.3.6.2. 기타 스토리지

기타 스토리지 솔루션을 사용하여 코어 클러스터에 영구 스토리지를 제공할 수 있습니다. 이러한 솔루션의 구성 및 통합은 통신 코어 RDS의 범위를 벗어납니다. 스토리지 솔루션을 코어 클러스터에 통합하려면 스토리지가 전체 성능 및 리소스 사용률 요구 사항을 충족하는지 확인하기 위해 올바른 크기 조정 및 성능 분석을 포함해야 합니다.

3.3.3.7. 모니터링
이번 릴리스의 새로운 기능
해당 없음
설명

CCMO(Cluster Monitoring Operator)는 기본적으로 모든 OpenShift 클러스터에 포함되어 있으며 플랫폼 구성 요소와 사용자 프로젝트에 대한 모니터링(metrics, 대시보드, 경고)도 제공합니다.

모니터링 Operator를 구성하면 다음을 포함하여 사용자 정의할 수 있습니다.

  • 기본 보존 기간
  • 사용자 정의 경고 규칙

Pod CPU 및 메모리 메트릭의 기본 처리는 업스트림 Kubernetes cAdvisor 를 기반으로 하며 메트릭 정확도에 비해 오래된 데이터를 처리하는 것을 선호하는 절충 역할을 합니다. 이로 인해 사용자 지정 임계값에 대해 잘못된 경고 트리거를 생성하는 spiky 데이터가 생성됩니다. OpenShift는 spiky 동작으로 영향을 받지 않는 추가 Pod CPU 및 메모리 메트릭 세트를 생성하는 옵트인 전용 서비스 모니터 기능을 지원합니다. 자세한 내용은 이 솔루션 가이드를 참조하십시오.

기본 구성 외에도 telco 코어 클러스터에 대해 다음 메트릭을 구성해야 합니다.

  • 사용자 워크로드에 대한 Pod CPU 및 메모리 메트릭 및 경고
제한 및 요구사항
  • 모니터링 구성에서 Pod 메트릭을 정확하게 표시하려면 전용 서비스 모니터 기능을 활성화해야 합니다.
엔지니어링 고려 사항
  • Prometheus 보존 기간은 사용자가 지정합니다. 사용된 값은 CPU 및 스토리지 리소스에 대해 클러스터의 기록 데이터를 유지 관리하기 위한 운영 요구 사항 간의 절충입니다. 보존 기간이 길어지면 스토리지의 필요성이 증가하고 데이터 인덱싱을 관리하기 위해 추가 CPU가 필요합니다.

추가 리소스

3.3.3.8. 스케줄링
이번 릴리스의 새로운 기능
  • NUMA 리소스 Operator를 사용한 NUMA 인식 스케줄링은 이제 OpenShift Container Platform 4.14에서 일반적으로 사용할 수 있습니다.
  • 이번 릴리스에서는 SR-IOV 네트워크의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자에게 알리는 것을 제외할 수 있습니다. SR-IOV 네트워크의 NUMA 노드를 알리지 않으면 NUMA 인식 Pod 예약 중에 더 유연한 SR-IOV 네트워크 배포를 허용할 수 있습니다. SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 SriovNetworkNodePolicy CR에서 excludeTopology 값을 true 로 설정합니다. 자세한 내용은 NUMA 인식 스케줄링에 대한 SR-IOV 네트워크 토폴로지 제외 를 참조하십시오.
설명
  • 스케줄러는 지정된 워크로드에 적합한 노드를 선택하는 클러스터 전체 구성 요소입니다. 이는 플랫폼의 핵심 부분이며 일반적인 배포 시나리오에서 특정 구성이 필요하지 않습니다. 그러나 다음 섹션에서 설명하는 몇 가지 특정 사용 사례가 있습니다.
제한 및 요구사항
  • 기본 스케줄러는 워크로드의 NUMA 현지성을 인식하지 못합니다. 작업자 노드에서 사용 가능한 모든 리소스의 합계만 알고 있습니다. 이로 인해 토폴로지 관리자 정책이 single-numa-node 또는 restricted 로 설정된 노드에 예약할 때 워크로드가 거부될 수 있습니다.

    • 예를 들어 Pod에서 6개의 CPU를 요청하고 NUMA 노드당 CPU가 4개인 빈 노드로 예약되는 것이 좋습니다. 노드의 총 할당 가능 용량은 8개의 CPU이며 스케줄러는 Pod를 배치합니다. 노드 로컬 승인은 실패하지만 각 NUMA 노드에서 사용할 수 있는 CPU는 4개뿐입니다.
    • NUMA 노드가 있는 모든 클러스터는 NUMA 리소스 Operator 를 사용해야 합니다. NUMA 리소스 Operator의 machineConfigPoolSelector 는 NUMA 정렬 스케줄링이 필요한 모든 노드를 선택해야 합니다.
  • 모든 머신 구성 풀에는 일관된 하드웨어 구성이 있어야 합니다. 예를 들어 모든 노드에는 동일한 NUMA 영역 수가 있어야 합니다.
엔지니어링 고려 사항
  • Pod에 올바른 스케줄링 및 격리를 위한 주석이 필요할 수 있습니다. 주석에 대한 자세한 내용은 "CPU 파티셔닝 및 성능 튜닝" 섹션을 참조하십시오.
3.3.3.9. 설치
이번 릴리스의 새로운 기능, 설명

Telco 코어 클러스터는 ABI(agent Based Installer)를 사용하여 설치할 수 있습니다. 이 방법을 사용하면 설치를 관리하기 위해 추가 서버 또는 VM 없이도 베어 메탈 서버에 OpenShift Container Platform을 설치할 수 있습니다. ABI 설치 프로그램은 예를 들어 ISO 설치 이미지를 생성하는 랩탑과 같은 시스템에서 실행할 수 있습니다. 이 ISO는 클러스터 감독 노드의 설치 미디어로 사용됩니다. 감독 노드의 API 인터페이스에 대한 네트워크 연결이 있는 모든 시스템에서 ABI 툴을 사용하여 진행 상황을 모니터링할 수 있습니다.

  • 선언적 CR에서 설치
  • 설치를 지원하기 위해 추가 서버가 필요하지 않음
  • 연결이 끊긴 환경에서 설치 지원
제한 및 요구사항
  • 연결이 끊긴 설치에는 필요한 모든 콘텐츠가 미러링된 연결 가능한 레지스트리가 필요합니다.
엔지니어링 고려 사항
  • 네트워킹 구성은 NMState Operator를 사용하여 2일차 구성에 우선하여 설치 중에 NMState 구성으로 적용해야 합니다.
3.3.3.10. 보안
이번 릴리스의 새로운 기능
  • 커널에 트래픽을 삽입해야 하는 DPDK 애플리케이션은 Cryostat CNI 플러그인을 사용하여 권한이 없는 Pod에서 실행할 수 있습니다. 또한 이 4.14 릴리스에서는 컨테이너 네임스페이스의 마스터 인터페이스를 기반으로 MAC-VLAN, IP-VLAN 및 VLAN 하위 인터페이스를 생성하는 기능을 일반적으로 사용할 수 있습니다.
설명

통신 운영자는 보안에 대해 자심하고 있으며 여러 공격 벡터에 대해 클러스터를 강화해야 합니다. OpenShift Container Platform에는 클러스터 보안을 담당하는 단일 구성 요소 또는 기능이 없습니다. 이 섹션에서는 이 사양에서 다루는 사용 모델에 대한 보안 지향 기능 및 구성에 대한 세부 정보를 제공합니다.

  • SecurityContextConstraints: 모든 워크로드 Pod는 restricted-v2 또는 restricted SCC를 사용하여 실행해야 합니다.
  • seccomp: 모든 Pod는 RuntimeDefault (또는 더 강력한) seccomp 프로필을 사용하여 실행해야 합니다.
  • rootless DPDK Pod: 많은 DPDK(사용자 플레인 네트워킹) CNF는 root 권한으로 Pod를 실행해야 합니다. 이 기능을 사용하면 root 권한 없이도 준수 DPDK Pod를 실행할 수 있습니다.
  • 스토리지: 스토리지 네트워크를 다른 클러스터 네트워크로 분리하고 라우팅할 수 없어야 합니다. 자세한 내용은 "스토리지" 섹션을 참조하십시오.
제한 및 요구사항
  • rootless DPDK Pod에는 다음과 같은 추가 구성 단계가 필요합니다.

    • container_t SELinux 컨텍스트를 사용하여 Cryostat 플러그인을 구성합니다.
    • 호스트에서 container_use_devices SELinux 부울을 활성화합니다.
엔지니어링 고려 사항
  • rootless DPDK Pod를 지원하려면 Cryostat 장치를 생성하려면 호스트에서 SELinux 부울 container_use_devices 를 활성화해야 합니다. 이로 인해 단기간에 사용 가능한 보안 위험이 발생합니다. 다른 해결책도 살펴볼 것입니다.
3.3.3.11. 확장성
이번 릴리스의 새로운 기능
해당 없음
설명

클러스터는 limits 및 requirements 섹션에 나열된 크기 조정으로 확장됩니다.

워크로드 스케일링은 사용 모델 섹션에 설명되어 있습니다.

제한 및 요구사항
  • 클러스터는 최소 120개의 노드로 확장 가능
엔지니어링 고려 사항
해당 없음
3.3.3.12. 추가 구성
3.3.3.12.1. 연결이 끊긴 환경
설명

통신 핵심 클러스터는 인터넷에 직접 액세스하지 않고 네트워크에 설치해야 합니다. 클러스터를 설치, 구성, Operator에 필요한 모든 컨테이너 이미지는 연결이 끊긴 레지스트리에서 사용할 수 있어야 합니다. 여기에는 OpenShift Container Platform 이미지, day-2 Operator Lifecycle Manager(OLM) Operator 이미지, 애플리케이션 워크로드 이미지가 포함됩니다. 연결이 끊긴 환경을 사용하면 다음과 같은 여러 이점이 있습니다.

  • 보안을 위해 클러스터에 대한 액세스 제한
  • 선별된 콘텐츠: 클러스터의 큐레이션 및 승인된 업데이트를 기반으로 레지스트리가 채워집니다.
제한 및 요구사항
  • 모든 사용자 정의 CatalogSources에는 고유한 이름이 필요합니다. 기본 카탈로그 이름을 재사용하지 마십시오.
  • 유효한 시간 소스는 클러스터 설치의 일부로 구성해야 합니다.
엔지니어링 고려 사항
해당 없음
3.3.3.12.2. 커널
이번 릴리스의 새로운 기능
해당 없음
설명

사용자는 MachineConfig 를 사용하여 확장된 커널 기능을 CNFs에 제공하여 다음 커널 모듈을 설치할 수 있습니다.

  • sctp
  • ip_gre
  • ip6_tables
  • ip6t_REJECT
  • ip6table_filter
  • ip6table_mangle
  • iptable_filter
  • iptable_mangle
  • iptable_nat
  • xt_multiport
  • xt_owner
  • xt_REDIRECT
  • xt_statistic
  • xt_TCPMSS
제한 및 요구사항
  • 이러한 커널 모듈을 통해 사용할 수 있는 기능의 사용은 CPU 부하, 시스템 성능 및 KPI 유지 기능에 미치는 영향을 확인하려면 사용자가 분석해야 합니다.
참고

트리 부족 드라이버는 지원되지 않습니다.

엔지니어링 고려 사항
해당 없음

3.3.4. Telco core 4.14 참조 구성 CR

다음 CR(사용자 정의 리소스)을 사용하여 telco core 프로필로 OpenShift Container Platform 클러스터를 구성하고 배포합니다. 달리 표시되지 않는 한 모든 특정 사용 모델에 사용되는 공통 기준을 형성하려면 CR을 사용합니다.

3.3.4.1. 리소스 튜닝 참조 CR
표 3.11. 리소스 튜닝 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

시스템 예약 용량

pid-limits-cr.yaml

없음

시스템 예약 용량

control-plane-system-reserved.yaml

없음

3.3.4.2. 스토리지 참조 CR
표 3.12. 스토리지 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

외부 ODF 구성

odfNS.yaml

없음

없음

외부 ODF 구성

odfOperGroup.yaml

없음

없음

외부 ODF 구성

odfSubscription.yaml

없음

없음

외부 ODF 구성

01-rook-ceph-external-cluster-details.secret.yaml

없음

없음

외부 ODF 구성

02-ocs-external-storagecluster.yaml

없음

없음

3.3.4.3. 네트워킹 참조 CR
표 3.13. Networking CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

기준

Network.yaml

없음

없음

기준

networkAttachmentDefinition.yaml

없음

SR-IOV 네트워크 Operator

SriovSubscriptionNS.yaml

없음

없음

SR-IOV 네트워크 Operator

SriovSubscriptionOperGroup.yaml

없음

없음

SR-IOV 네트워크 Operator

SriovSubscription.yaml

없음

없음

SR-IOV 네트워크 Operator

SriovOperatorConfig.yaml

없음

없음

SR-IOV 네트워크 Operator

sriovNetworkNodePolicy.yaml

없음

없음

SR-IOV 네트워크 Operator

sriovNetwork.yaml

없음

없음

로드 밸런서

metallbNS.yaml

없음

없음

로드 밸런서

metallbOperGroup.yaml

없음

없음

로드 밸런서

metallbSubscription.yaml

없음

없음

로드 밸런서

metallb.yaml

없음

없음

로드 밸런서

bgp-peer.yaml

없음

없음

로드 밸런서

bfd-profile.yaml

없음

없음

로드 밸런서

addr-pool.yaml

없음

없음

로드 밸런서

bgp-advr.yaml

없음

없음

Multus - rootless DPDK Pod의 경우 Tap CNI

mc_rootless_pods_selinux.yaml

없음

3.3.4.4. 참조 CR 예약
표 3.14. CR 예약
Component참조 CR선택 사항이번 릴리스의 새로운 기능

NUMA 인식 스케줄러

NROPSubscriptionNS.yaml

없음

없음

NUMA 인식 스케줄러

NROPSubscriptionOperGroup.yaml

없음

없음

NUMA 인식 스케줄러

NROPSubscription.yaml

없음

없음

NUMA 인식 스케줄러

sched.yaml

없음

없음

NUMA 인식 스케줄러

nrop.yaml

없음

없음

3.3.4.5. 기타 참조 CR
표 3.15. 기타 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

연결이 끊긴 구성

catalog-source.yaml

없음

없음

연결이 끊긴 구성

icsp.yaml

없음

없음

연결이 끊긴 구성

operator-hub.yaml

없음

없음

클러스터 로깅

ClusterLogNS.yaml

없음

클러스터 로깅

ClusterLogOperGroup.yaml

없음

클러스터 로깅

ClusterLogSubscription.yaml

없음

클러스터 로깅

ClusterLogForwarder.yaml

없음

클러스터 로깅

ClusterLogging.yaml

없음

추가 커널 모듈

control-plane-load-kernel-modules.yaml

없음

추가 커널 모듈

worker-load-kernel-modules.yaml

없음

추가 커널 모듈

sctp_module_mc.yaml

없음

전원 관리

PerformanceProfile.yaml

없음

없음

모니터링 및 관찰 기능

monitoring-config-cm.yaml

없음

3.3.4.6. YAML 참조
3.3.4.6.1. 리소스 튜닝 참조 YAML

pid-limits-cr.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: 99-change-pidslimit-custom
spec:
  machineConfigPoolSelector:
    matchLabels:
      # Set to appropriate MCP
      pools.operator.machineconfiguration.openshift.io/master: ""
  containerRuntimeConfig:
    pidsLimit: $pidsLimit
    # Example:
    #pidsLimit: 4096

control-plane-system-reserved.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: KubeletConfig
metadata:
  name: autosizing-master
spec:
  autoSizingReserved: true
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/master: ""

3.3.4.6.2. 스토리지 참조 YAML

odfNS.yaml

# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-storage
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

odfOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-storage-operatorgroup
  namespace: openshift-storage
spec:
  targetNamespaces:
    - openshift-storage

odfSubscription.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: odf-operator
  namespace: openshift-storage
spec:
  channel: "stable-4.14"
  name: odf-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

01-rook-ceph-external-cluster-details.secret.yaml

# required
# count: 1
---
apiVersion: v1
kind: Secret
metadata:
  name: rook-ceph-external-cluster-details
  namespace: openshift-storage
type: Opaque
data:
  # encoded content has been made generic
  external_cluster_details: eyJuYW1lIjoicm9vay1jZXBoLW1vbi1lbmRwb2ludHMiLCJraW5kIjoiQ29uZmlnTWFwIiwiZGF0YSI6eyJkYXRhIjoiY2VwaHVzYTE9MS4yLjMuNDo2Nzg5IiwibWF4TW9uSWQiOiIwIiwibWFwcGluZyI6Int9In19LHsibmFtZSI6InJvb2stY2VwaC1tb24iLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJhZG1pbi1zZWNyZXQiOiJhZG1pbi1zZWNyZXQiLCJmc2lkIjoiMTExMTExMTEtMTExMS0xMTExLTExMTEtMTExMTExMTExMTExIiwibW9uLXNlY3JldCI6Im1vbi1zZWNyZXQifX0seyJuYW1lIjoicm9vay1jZXBoLW9wZXJhdG9yLWNyZWRzIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsidXNlcklEIjoiY2xpZW50LmhlYWx0aGNoZWNrZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoibW9uaXRvcmluZy1lbmRwb2ludCIsImtpbmQiOiJDZXBoQ2x1c3RlciIsImRhdGEiOnsiTW9uaXRvcmluZ0VuZHBvaW50IjoiMS4yLjMuNCwxLjIuMy4zLDEuMi4zLjIiLCJNb25pdG9yaW5nUG9ydCI6IjkyODMifX0seyJuYW1lIjoiY2VwaC1yYmQiLCJraW5kIjoiU3RvcmFnZUNsYXNzIiwiZGF0YSI6eyJwb29sIjoib2RmX3Bvb2wifX0seyJuYW1lIjoicm9vay1jc2ktcmJkLW5vZGUiLCJraW5kIjoiU2VjcmV0IiwiZGF0YSI6eyJ1c2VySUQiOiJjc2ktcmJkLW5vZGUiLCJ1c2VyS2V5IjoiIn19LHsibmFtZSI6InJvb2stY3NpLXJiZC1wcm92aXNpb25lciIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7InVzZXJJRCI6ImNzaS1yYmQtcHJvdmlzaW9uZXIiLCJ1c2VyS2V5IjoiYzJWamNtVjAifX0seyJuYW1lIjoicm9vay1jc2ktY2VwaGZzLXByb3Zpc2lvbmVyIiwia2luZCI6IlNlY3JldCIsImRhdGEiOnsiYWRtaW5JRCI6ImNzaS1jZXBoZnMtcHJvdmlzaW9uZXIiLCJhZG1pbktleSI6IiJ9fSx7Im5hbWUiOiJyb29rLWNzaS1jZXBoZnMtbm9kZSIsImtpbmQiOiJTZWNyZXQiLCJkYXRhIjp7ImFkbWluSUQiOiJjc2ktY2VwaGZzLW5vZGUiLCJhZG1pbktleSI6ImMyVmpjbVYwIn19LHsibmFtZSI6ImNlcGhmcyIsImtpbmQiOiJTdG9yYWdlQ2xhc3MiLCJkYXRhIjp7ImZzTmFtZSI6ImNlcGhmcyIsInBvb2wiOiJtYW5pbGFfZGF0YSJ9fQ==

02-ocs-external-storagecluster.yaml

# required
# count: 1
---
apiVersion: ocs.openshift.io/v1
kind: StorageCluster
metadata:
  name: ocs-external-storagecluster
  namespace: openshift-storage
spec:
  externalStorage:
    enable: true
  labelSelector: {}

3.3.4.6.3. 네트워킹 참조 YAML

Network.yaml

# required
# count: 1
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
spec:
  defaultNetwork:
    ovnKubernetesConfig:
      gatewayConfig:
        routingViaHost: true
  # additional networks are optional and may alternatively be specified using NetworkAttachmentDefinition CRs
  additionalNetworks: [$additionalNetworks]
  # eg
  #- name: add-net-1
  #  namespace: app-ns-1
  #  rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "add-net-1", "plugins": [{"type": "macvlan", "master": "bond1", "ipam": {}}] }'
  #  type: Raw
  #- name: add-net-2
  #  namespace: app-ns-1
  #  rawCNIConfig: '{ "cniVersion": "0.4.0", "name": "add-net-2", "plugins": [ {"type": "macvlan", "master": "bond1", "mode": "private" },{ "type": "tuning", "name": "tuning-arp" }] }'
  #  type: Raw

networkAttachmentDefinition.yaml

# optional
# copies: 0-N
apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: $name
  namespace: $ns
spec:
  nodeSelector:
    kubernetes.io/hostname: $nodeName
  config: $config
  #eg
  #config: '{
  #  "cniVersion": "0.3.1",
  #  "name": "external-169",
  #  "type": "vlan",
  #  "master": "ens8f0",
  #  "mode": "bridge",
  #  "vlanid": 169,
  #  "ipam": {
  #    "type": "static",
  #  }
  #}'

SriovSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management

SriovSubscriptionOperGroup.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

SriovSubscription.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

SriovOperatorConfig.yaml

# required
# count: 1
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
spec:
  configDaemonNodeSelector:
    node-role.kubernetes.io/worker: ""
  enableInjector: true
  enableOperatorWebhook: true

sriovNetworkNodePolicy.yaml

# optional (though expected in all deployments)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: $name
  namespace: openshift-sriov-network-operator
spec: {} # $spec
# eg
#deviceType: netdevice
#nicSelector:
#  deviceID: "1593"
#  pfNames:
#  - ens8f0np0#0-9
#  rootDevices:
#  - 0000:d8:00.0
#  vendor: "8086"
#nodeSelector:
#  kubernetes.io/hostname: host.sample.lab
#numVfs: 20
#priority: 99
#excludeTopology: true
#resourceName: resourceNameABCD

sriovNetwork.yaml

# optional (though expected for all)
# count: 0-N
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: $name # eg sriov-network-abcd
  namespace: openshift-sriov-network-operator
spec:
  capabilities: "$capabilities" # eg '{"mac": true, "ips": true}'
  ipam: "$ipam" # eg '{ "type": "host-local", "subnet": "10.3.38.0/24" }'
  networkNamespace: $nns # eg cni-test
  resourceName: $resource # eg resourceTest

metallbNS.yaml

# required: yes
# count: 1
---
apiVersion: v1
kind: Namespace
metadata:
  name: metallb-system
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"

metallbOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system

metallbSubscription.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: metallb-operator-sub
  namespace: metallb-system
spec:
  channel: stable
  name: metallb-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

metallb.yaml

# required
# count: 1
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec:
  nodeSelector:
    node-role.kubernetes.io/worker: ""

bgp-peer.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BGPPeer
metadata:
  name: $name
  namespace: metallb-system
spec:
  peerAddress: $ip # eg 192.168.1.2
  peerASN: $peerasn # eg 64501
  myASN: $myasn # eg 64500
  routerID: $id # eg 10.10.10.10
  bfdProfile: bfdprofile

bfd-profile.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
  name: bfdprofile
  namespace: metallb-system
spec:
  ################
  # These values may vary. Recommended values are included as default
  receiveInterval: 150 # default 300ms
  transmitInterval: 150 # default 300ms
  #echoInterval: 300 # default 50ms
  detectMultiplier: 10 # default 3
  echoMode: true
  passiveMode: true
  minimumTtl: 5 # default 254
  #
  ################

addr-pool.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: $name # eg addresspool3
  namespace: metallb-system
  annotations:
    metallb.universe.tf/address-pool: $name # eg addresspool3
spec:
  ##############
  # Expected variation in this configuration
  addresses: [$pools]
  #- 3.3.3.0/24
  autoAssign: true
  ##############

bgp-advr.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BGPAdvertisement
metadata:
  name: $name # eg bgpadvertisement-1
  namespace: metallb-system
spec:
  ipAddressPools: [$pool]
  # eg:

  #  - addresspool3
  peers: [$peers]
  # eg:

  #    - peer-one
  communities: [$communities]
  # Note correlation with address pool.
  # eg:

  #    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100

mc_rootless_pods_selinux.yaml

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-worker-setsebool
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Set SELinux boolean for tap cni plugin
            Before=kubelet.service

            [Service]
            Type=oneshot
            ExecStart=/sbin/setsebool container_use_devices=on
            RemainAfterExit=true

            [Install]
            WantedBy=multi-user.target graphical.target
          enabled: true
          name: setsebool.service

3.3.4.6.4. 참조 YAML 예약

NROPSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-numaresources
  annotations:
    workload.openshift.io/allowed: management

NROPSubscriptionOperGroup.yaml

# required: yes
# count: 1
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  targetNamespaces:
    - openshift-numaresources

NROPSubscription.yaml

# required
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  channel: "4.14"
  name: numaresources-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace

sched.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesScheduler
metadata:
  name: numaresourcesscheduler
spec:
  #cacheResyncPeriod: "0"
  # Image spec should be the latest for the release
  imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.14.0"
  #logLevel: "Trace"
  schedulerName: topo-aware-scheduler

nrop.yaml

# Optional
# count: 1
apiVersion: nodetopology.openshift.io/v1
kind: NUMAResourcesOperator
metadata:
  name: numaresourcesoperator
spec:
  nodeGroups:
    - config:
        # Periodic is the default setting
        infoRefreshMode: Periodic
      machineConfigPoolSelector:
        matchLabels:
          # This label must match the pool(s) you want to run NUMA-aligned workloads
          pools.operator.machineconfiguration.openshift.io/worker: ""

3.3.4.6.5. 기타 참조 YAML

catalog-source.yaml

# required
# count: 1..N
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: redhat-operators-disconnected
  namespace: openshift-marketplace
spec:
  displayName: Red Hat Disconnected Operators Catalog
  image: $imageUrl
  publisher: Red Hat
  sourceType: grpc
#  updateStrategy:
#    registryPoll:
#      interval: 1h
#status:
#    connectionState:
#        lastObservedState: READY

icsp.yaml

# required
# count: 1
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
spec:
  repositoryDigestMirrors: []
#    - $mirrors

operator-hub.yaml

# required
# count: 1
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
    - openshift-logging

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic

ClusterLogForwarder.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  outputs:
    - type: "kafka"
      name: kafka-open
      url: tcp://10.11.12.13:9092/test
  pipelines:
    - inputRefs:
        - infrastructure
        #- application
        - audit
      labels:
        label1: test1
        label2: test2
        label3: test3
        label4: test4
        label5: test5
      name: all-to-default
      outputRefs:
        - kafka-open

ClusterLogging.yaml

# required
# count: 1
apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
spec:
  collection:
    type: vector
  managementState: Managed

control-plane-load-kernel-modules.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 40-load-kernel-modules-control-plane
spec:
  config:
    # Release info found in https://github.com/coreos/butane/releases
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:,
          mode: 420
          overwrite: true
          path: /etc/modprobe.d/kernel-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwp4dF91MzI=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf

worker-load-kernel-modules.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 40-load-kernel-modules-worker
spec:
  config:
    # Release info found in https://github.com/coreos/butane/releases
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:,
          mode: 420
          overwrite: true
          path: /etc/modprobe.d/kernel-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwp4dF91MzI=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf

sctp_module_mc.yaml

# optional
# count: 1
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: load-sctp-module
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8;base64,c2N0cA==
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

PerformanceProfile.yaml

# required
# count: 1
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: $name
  annotations:
    # Some pods want the kernel stack to ignore IPv6 router Advertisement.
    kubeletconfig.experimental: |
      {"allowedUnsafeSysctls":["net.ipv6.conf.all.accept_ra"]}
spec:
  cpu:
    # node0 CPUs: 0-17,36-53
    # node1 CPUs: 18-34,54-71
    # siblings: (0,36), (1,37)...
    # we want to reserve the first Core of each NUMA socket
    #
    # no CPU left behind! all-cpus == isolated + reserved
    isolated: $isolated # eg 1-17,19-35,37-53,55-71
    reserved: $reserved # eg 0,18,36,54
  # Guaranteed QoS pods will disable IRQ balancing for cores allocated to the pod.
  # default value of globallyDisableIrqLoadBalancing is false
  globallyDisableIrqLoadBalancing: false
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      # 32GB per numa node
      - count: $count # eg 64
        size: 1G
  machineConfigPoolSelector:
    # For SNO: machineconfiguration.openshift.io/role: 'master'
    pools.operator.machineconfiguration.openshift.io/worker: ''
  nodeSelector:
    # For SNO: node-role.kubernetes.io/master: ""
    node-role.kubernetes.io/worker: ""
  workloadHints:
    realTime: false
    highPowerConsumption: false
    perPodPowerManagement: true
  realTimeKernel:
    enabled: false
  numa:
    # All guaranteed QoS containers get resources from a single NUMA node
    topologyPolicy: "single-numa-node"
  net:
    # Limit the number or IRQs to 8 (number or reserved CPUs)
    # => this is good enough as I have only 262 IT now instead of 501
    # but this is a waste... TODO: now waste (see below)!
    #
    # This is more than enough for eno1 (host and OVN)
    # eno2 should be down. TODO: add MCO or use NMSTATE in OCP4.10
    # SR-IOV PFs: only VFs are used. TODO: MCO to have a single IRQ
    userLevelNetworking: false

monitoring-config-cm.yaml

# optional
# count: 1
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    k8sPrometheusAdapter:
      dedicatedServiceMonitors:
        enabled: true
    prometheusK8s:
      retention: 15d
      volumeClaimTemplate:
        spec:
          storageClassName: ocs-external-storagecluster-ceph-rbd
          resources:
            requests:
              storage: 100Gi
    alertmanagerMain:
      volumeClaimTemplate:
        spec:
          storageClassName: ocs-external-storagecluster-ceph-rbd
          resources:
            requests:
              storage: 20Gi

4장. 오브젝트 최대값에 따른 환경 계획

OpenShift Container Platform 클러스터를 계획하는 경우 다음과 같은 테스트된 오브젝트 최대값을 고려하십시오.

이러한 지침은 가능한 가장 큰 클러스터를 기반으로 합니다. 크기가 작은 클러스터의 경우 최대값이 더 낮습니다. etcd 버전 또는 스토리지 데이터 형식을 비롯하여 명시된 임계값에 영향을 주는 요인은 여러 가지가 있습니다.

대부분의 경우 이러한 수치를 초과하면 전체 성능이 저하됩니다. 반드시 클러스터가 실패하는 것은 아닙니다.

주의

Pod 시작 및 중지가 많은 경우와 같이 신속한 변경이 발생하는 클러스터는 문서화된 것보다 실용적인 최대 크기를 줄일 수 있습니다.

4.1. OpenShift Container Platform에 대해 테스트된 클러스터 최대값(주요 릴리스)

참고

Red Hat은 OpenShift Container Platform 클러스터 크기 조정에 대한 직접적인 지침을 제공하지 않습니다. 이는 클러스터가 OpenShift Container Platform의 지원되는 범위 내에 있는지 여부를 확인하려면 클러스터 스케일링을 제한하는 모든 다차원 요인을 신중하게 고려해야 하기 때문입니다.

OpenShift Container Platform은 절대 클러스터 최대값이 아닌 테스트된 클러스터 최대값을 지원합니다. OpenShift Container Platform 버전, 컨트롤 플레인 워크로드 및 네트워크 플러그인을 모두 조합한 것은 아니므로 다음 표는 모든 배포에 대한 대규모의 절대 기대치를 나타내지는 않습니다. 모든 차원의 최대값을 동시에 확장하지 못할 수 있습니다. 이 표에는 특정 워크로드 및 배포 구성에 대해 테스트된 최대값이 포함되어 있으며 유사한 배포로 예상되는 항목에 대한 스케일 가이드 역할을 합니다.

최대값 유형4.x 테스트된 최대값

노드 수

2,000 [1]

Pod 수 [2]

150,000

노드당 Pod 수

2,500 [3][4]

코어당 Pod 수

기본값 없음

네임스페이스 수 [5]

10,000

빌드 수

10,000(기본 Pod RAM 512Mi) - S2I(Source-to-Image) 빌드 전략

네임스페이스당 Pod 수 [6]

25,000

Ingress 컨트롤러당 경로 및 백엔드 수

라우터당 2,000개

보안 수

80,000

구성 맵 수

90,000

서비스 수 [7]

10,000

네임스페이스당 서비스 수

5,000

서비스당 백엔드 수

5,000

네임스페이스당 배포 수 [6]

2,000

빌드 구성 수

12,000

CRD(사용자 정의 리소스 정의) 수

1,024 [8]

  1. Pod 일시 중지는 2000 노드 규모로 OpenShift Container Platform의 컨트롤 플레인 구성 요소를 강조하기 위해 배포되었습니다. 유사한 숫자로 확장하는 기능은 특정 배포 및 워크로드 매개변수에 따라 달라집니다.
  2. 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
  3. 이 테스트는 컨트롤 플레인 3개, 인프라 노드 2개, 작업자 노드 26개 등 31개의 서버가 있는 클러스터에서 테스트되었습니다. 2,500개의 사용자 Pod가 필요한 경우 각 노드에 2000개 이상의 Pod를 포함할 수 있을 만큼 큰 네트워크를 할당하고 maxPods2500 으로 설정된 사용자 정의 kubelet 구성이 모두 필요한 20 개의 hostPrefix 가 필요합니다. 자세한 내용은 OCP 4.13에서 노드당 2500개의 Pod 실행을 참조하십시오.
  4. 노드당 테스트된 최대 Pod는 OVNKubernetes 네트워크 플러그인을 사용하는 클러스터의 경우 2,500입니다. OpenShiftSDN 네트워크 플러그인의 노드당 테스트된 최대 Pod는 500개의 포드입니다.
  5. 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하기 위해 조각 모음을 포함한 etcd의 유지보수를 정기적으로 수행하는 것이 좋습니다.
  6. 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트를 반복해야 하는 컨트롤 루프가 여러 개 있습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
  7. 각 서비스 포트와 각 서비스 백엔드에는 iptables 에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
  8. 29개의 서버가 있는 클러스터에서 테스트되었습니다. 컨트롤 플레인 3개, 인프라 노드 2개 및 작업자 노드 24개 클러스터에는 500개의 네임스페이스가 있습니다. OpenShift Container Platform에는 OpenShift Container Platform에서 설치하는 제품을 포함하여 OpenShift Container Platform 및 사용자 생성 CRD와 통합되는 제품을 포함하여 1,024개의 총 사용자 정의 리소스 정의(CRD) 제한이 있습니다. 1,024 CRD 이상이 생성된 경우 oc 명령 요청이 제한될 수 있습니다.

4.1.1. 시나리오 예

예를 들어 500개의 작업자 노드(m5.2xl)가 테스트되었으며 OpenShift Container Platform 4.14, OVN-Kubernetes 네트워크 플러그인 및 다음 워크로드 오브젝트를 사용하여 지원됩니다.

  • 200개의 네임스페이스(기본값 포함)
  • 노드당 60 Pod, 서버 30개 및 클라이언트 Pod 30개(총 30개)
  • 57 이미지 스트림/ns (최대 11.4k)
  • 서버 Pod가 지원하는 15개의 서비스/서버(총 3k)
  • 이전 서비스에서 지원하는 15개의 경로/ns(총 3k)
  • 20개의 시크릿/ns (4k 전체)
  • 10개의 구성 맵/ns (2k 합계)
  • 6 네트워크 정책/ns, deny-all, allow-from ingress 및 intra-namespace 규칙 6개
  • 57개의 빌드/ns

다음 요인은 클러스터 워크로드 확장, 긍정 또는 부정적인 영향을 미치는 것으로 알려져 있으며 배포를 계획할 때 스케일 숫자로 고려해야 합니다. 자세한 내용 및 지침은 영업 담당자 또는 Red Hat 지원에 문의하십시오.

  • 노드당 Pod 수
  • Pod당 컨테이너 수
  • 사용된 프로브 유형(예: liveness/readiness, exec/http)
  • 네트워크 정책 수
  • 프로젝트 수 또는 네임스페이스
  • 프로젝트당 이미지 스트림 수
  • 프로젝트당 빌드 수
  • 서비스/엔드포인트 및 유형 수
  • 경로 수
  • shard 수
  • 보안 수
  • 구성 맵 수
  • 클러스터 구성에서 상황이 얼마나 빠르게 변경되는지 추정하는 API 호출 속도 또는 클러스터 "churn"입니다.

    • 5분 동안의 초당 Pod 생성 요청에 대한 Prometheus 쿼리: sum(irate(apiserver_request_count{resource="pods",verb="POST"}[5m]))
    • 5분 동안의 모든 API 요청에 대한 Prometheus 쿼리: sum(apiserver_request_count{}[5m])
  • CPU의 클러스터 노드 리소스 사용
  • 메모리의 클러스터 노드 리소스 사용

4.2. 클러스터 최대값 테스트를 위한 OpenShift Container Platform 환경 및 구성

4.2.1. AWS 클라우드 플랫폼

노드플레이버vCPURAM(GiB)디스크 유형디스크 크기(GiB)/IOS수량리전

컨트롤 플레인/etcd [1]

r5.4xlarge

16

128

gp3

220

3

us-west-2

인프라 [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

  1. etcd가 대기 시간에 민감하기 때문에 초당 3000 IOPS 및 125MiB의 기본 성능이 있는 gp3 디스크는 컨트롤 플레인/etcd 노드에 사용됩니다. gp3 볼륨은 버스트 성능을 사용하지 않습니다.
  2. 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
  3. 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
  4. 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
  5. 클러스터는 반복적으로 확장되며 성능 및 확장성 테스트는 지정된 노드 수에 따라 실행됩니다.

4.2.2. IBM Power 플랫폼

노드vCPURAM(GiB)디스크 유형디스크 크기(GiB)/IOS수량

컨트롤 플레인/etcd [1]

16

32

io1

GiB당 120/10 IOPS

3

인프라 [2]

16

64

gp2

120

2

워크로드 [3]

16

256

gp2

120 [4]

1

Compute

16

64

gp2

120

2에서 100까지 [5]

  1. etcd는 I/O 집약적이고 대기 시간에 민감하므로 GiB당 120/10 IOPS가 있는 io1 디스크는 컨트롤 플레인/etcd 노드에 사용됩니다.
  2. 인프라 노드는 모니터링, Ingress 및 레지스트리 구성 요소를 호스팅하는데 사용되어 대규모로 실행할 수 있는 충분한 리소스가 있는지 확인합니다.
  3. 워크로드 노드는 성능 및 확장 가능한 워크로드 생성기 실행 전용입니다.
  4. 성능 및 확장성 테스트 실행 중에 수집되는 대량의 데이터를 저장할 수 있는 충분한 공간을 확보 할 수 있도록 큰 디스크 크기가 사용됩니다.
  5. 클러스터는 반복으로 확장됩니다.

4.2.3. IBM Z 플랫폼

노드vCPU [4]RAM(GiB)[5]디스크 유형디스크 크기(GiB)/IOS수량

컨트롤 플레인/etcd [1,2]

8

32

ds8k

300 / LCU 1

3

컴퓨팅 [1,3]

8

32

ds8k

150 / LCU 2

4개의 노드(노드당 100/250/500 Pod로 스케일링)

  1. etcd는 I/O 집약적이고 대기 시간에 민감하므로 컨트롤 플레인/etcd 노드의 디스크 I/O 로드를 최적화하기 위해 두 개의 LCU(Logical Control Unit) 간에 노드가 배포됩니다. etcd I/O 요구 사항은 다른 워크로드를 방해하지 않아야 합니다.
  2. 4개의 컴퓨팅 노드는 동시에 100/250/500개의 Pod가 있는 여러 반복 실행 테스트에 사용됩니다. 먼저 Pod를 유휴 상태로 설정하여 Pod 인스턴스를 평가할 수 있습니다. 다음으로, 과부하에 따른 시스템의 안정성을 평가하는 데 네트워크 및 CPU가 클라이언트/서버 워크로드를 사용했습니다. 클라이언트 및 서버 pod는 쌍으로 배포되었으며 각 쌍이 두 개의 컴퓨팅 노드에 분배되었습니다.
  3. 별도의 워크로드 노드가 사용되지 않았습니다. 워크로드는 두 컴퓨팅 노드 간에 마이크로 서비스 워크로드를 시뮬레이션합니다.
  4. 사용되는 물리적 프로세서 수는 Linux(IFL)에 대한 통합 6개입니다.
  5. 사용된 총 실제 메모리는 512GiB입니다.

4.3. 테스트된 클러스터 최대값에 따라 환경을 계획하는 방법

중요

노드에서 물리적 리소스에 대한 서브스크립션을 초과하면 Pod를 배치하는 동안 Kubernetes 스케줄러가 보장하는 리소스에 영향을 미칩니다. 메모리 교체가 발생하지 않도록 하기 위해 수행할 수 있는 조치를 알아보십시오.

테스트된 최대값 중 일부는 단일 차원에서만 확장됩니다. 클러스터에서 실행되는 오브젝트가 많으면 최대값이 달라집니다.

이 문서에 명시된 수치는 Red Hat의 테스트 방법론, 설정, 구성, 튜닝을 기반으로 한 것입니다. 고유한 개별 설정 및 환경에 따라 수치가 달라질 수 있습니다.

환경을 계획하는 동안 노드당 몇 개의 Pod가 적합할 것으로 예상되는지 결정하십시오.

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

노드 수를 20으로 늘리면 Pod 배포는 노드당 110개 Pod로 변경됩니다.

2200 / 20 = 110

다음과 같습니다.

required pods per cluster / total number of nodes = expected pods per node

OpenShift Container Platform에는 기본적으로 모든 작업자 노드에서 실행되는 SDN, DNS, Operator 등과 같은 여러 시스템 Pod가 제공됩니다. 따라서 위의 공식의 결과는 다를 수 있습니다.

4.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입니다.

노드의 인스턴스 크기는 기본 설정에 따라 높게 또는 낮게 조정될 수 있습니다. 노드에서는 리소스 초과 커밋이 발생하는 경우가 많습니다. 이 배포 시나리오에서는 동일한 양의 리소스를 제공하는 데 더 작은 노드를 추가로 실행하도록 선택할 수도 있고 더 적은 수의 더 큰 노드를 실행하도록 선택할 수도 있습니다. 운영 민첩성 및 인스턴스당 비용과 같은 요인을 고려해야 합니다.

노드 유형수량CPURAM(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 및 배포가 실패하기 시작합니다. 이 문제를 해결하려면 배포의 서비스 사양 파일에서 서비스 링크를 비활성화하십시오.

---
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  name: deployment-config-template
  creationTimestamp:
  annotations:
    description: This template will create a deploymentConfig with 1 replica, 4 env vars and a service.
    tags: ''
objects:
- apiVersion: apps.openshift.io/v1
  kind: DeploymentConfig
  metadata:
    name: deploymentconfig${IDENTIFIER}
  spec:
    template:
      metadata:
        labels:
          name: replicationcontroller${IDENTIFIER}
      spec:
        enableServiceLinks: false
        containers:
        - name: pause${IDENTIFIER}
          image: "${IMAGE}"
          ports:
          - containerPort: 8080
            protocol: TCP
          env:
          - name: ENVVAR1_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR2_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR3_${IDENTIFIER}
            value: "${ENV_VALUE}"
          - name: ENVVAR4_${IDENTIFIER}
            value: "${ENV_VALUE}"
          resources: {}
          imagePullPolicy: IfNotPresent
          capabilities: {}
          securityContext:
            capabilities: {}
            privileged: false
        restartPolicy: Always
        serviceAccount: ''
    replicas: 1
    selector:
      name: replicationcontroller${IDENTIFIER}
    triggers:
    - type: ConfigChange
    strategy:
      type: Rolling
- apiVersion: v1
  kind: Service
  metadata:
    name: service${IDENTIFIER}
  spec:
    selector:
      name: replicationcontroller${IDENTIFIER}
    ports:
    - name: serviceport${IDENTIFIER}
      protocol: TCP
      port: 80
      targetPort: 8080
    clusterIP: ''
    type: ClusterIP
    sessionAffinity: None
  status:
    loadBalancer: {}
parameters:
- name: IDENTIFIER
  description: Number to append to the name of resources
  value: '1'
  required: true
- name: IMAGE
  description: Image to use for deploymentConfig
  value: gcr.io/google-containers/pause-amd64:3.0
  required: false
- name: ENV_VALUE
  description: Value to use for environment variables
  generate: expression
  from: "[A-Za-z0-9]{255}"
  required: false
labels:
  template: deployment-config-template

네임스페이스에서 실행할 수 있는 애플리케이션 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를 실행할 수 있습니다.

5장.

중요

5.1.

참고

표 5.1. 할당량으로 관리하는 컴퓨팅 리소스
리소스 이름설명

cpu

터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. cpurequests.cpu는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

memory

터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. memoryrequests.memory는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

ephemeral-storage

터미널이 아닌 상태에서 모든 Pod의 로컬 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. ephemeral-storagerequests.ephemeral-storage는 동일한 값이며 서로 바꿔 사용할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다.

requests.cpu

터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 이 값을 초과할 수 없습니다. cpurequests.cpu는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

requests.memory

터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 이 값을 초과할 수 없습니다. memoryrequests.memory는 동일한 값이며 서로 바꿔 사용할 수 있습니다.

requests.ephemeral-storage

터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 이 값을 초과할 수 없습니다. ephemeral-storagerequests.ephemeral-storage는 동일한 값이며 서로 바꿔 사용할 수 있습니다. 이 기능은 기본적으로 비활성화되어 있습니다.

limits.cpu

터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.

limits.memory

터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.

limits.ephemeral-storage

터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다. 이 기능은 기본적으로 비활성화되어 있습니다.

표 5.2. 할당량으로 관리되는 스토리지 리소스
리소스 이름설명

requests.storage

상태와 관계없이 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다.

persistentvolumeclaims

프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다.

<storage-class-name>.storageclass.storage.k8s.io/requests.storage

상태와 관계없이 일치하는 스토리지 클래스가 있는 모든 영구 볼륨 클레임의 스토리지 요청 합계는 이 값을 초과할 수 없습니다.

<storage-class-name>.storageclass.storage.k8s.io/persistentvolumeclaims

프로젝트에 존재할 수 있는, 일치하는 스토리지 클래스가 있는 총 영구 볼륨 클레임 수입니다.

표 5.3. 할당량으로 관리하는 오브젝트 수
리소스 이름설명

pods

프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.

replicationcontrollers

프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다.

resourcequotas

프로젝트에 존재할 수 있는 총 리소스 할당량 수입니다.

services

프로젝트에 존재할 수 있는 총 서비스 수입니다.

secrets

프로젝트에 존재할 수 있는 총 시크릿 수입니다.

configmaps

프로젝트에 존재할 수 있는 총 ConfigMap 오브젝트 수입니다.

persistentvolumeclaims

프로젝트에 존재할 수 있는 총 영구 볼륨 클레임 수입니다.

openshift.io/imagestreams

프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.

$ oc create quota <name> --hard=count/<resource>.<group>=<quota> 1
1
<resource>는 리소스 이름이고 <group>은 API 그룹입니다(해당하는 경우).

5.1.1. 확장 리소스에 대한 리소스 할당량 설정

확장 리소스에는 리소스 과다 할당이 허용되지 않으므로 할당량의 해당 확장 리소스에 requestslimits를 지정해야 합니다. 다음은 GPU 리소스 nvidia.com/gpu에 대한 리소스 할당량을 설정하는 방법에 대한 예제 시나리오입니다.

프로세스

  1. $ oc describe node ip-172-31-27-209.us-west-2.compute.internal | egrep 'Capacity|Allocatable|gpu'

    출력 예

                        openshift.com/gpu-accelerator=true
    Capacity:
     nvidia.com/gpu:  2
    Allocatable:
     nvidia.com/gpu:  2
     nvidia.com/gpu:  0           0

    이 예에서는 GPU 2개를 사용할 수 있습니다.

  2. 이 예에서 할당량은 1입니다.

    $ cat gpu-quota.yaml

    출력 예

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gpu-quota
      namespace: nvidia
    spec:
      hard:
        requests.nvidia.com/gpu: 1

  3. $ oc create -f gpu-quota.yaml

    출력 예

    resourcequota/gpu-quota created

  4. $ oc describe quota gpu-quota -n nvidia

    출력 예

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  0     1

  5. $ oc create pod gpu-pod.yaml

    출력 예

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: gpu-pod-s46h7
      namespace: nvidia
    spec:
      restartPolicy: OnFailure
      containers:
      - name: rhel7-gpu-pod
        image: rhel7
        env:
          - name: NVIDIA_VISIBLE_DEVICES
            value: all
          - name: NVIDIA_DRIVER_CAPABILITIES
            value: "compute,utility"
          - name: NVIDIA_REQUIRE_CUDA
            value: "cuda>=5.0"
    
        command: ["sleep"]
        args: ["infinity"]
    
        resources:
          limits:
            nvidia.com/gpu: 1

  6. $ oc get pods

    출력 예

    NAME              READY     STATUS      RESTARTS   AGE
    gpu-pod-s46h7     1/1       Running     0          1m

  7. $ oc describe quota gpu-quota -n nvidia

    출력 예

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  1     1

  8. 노드에 GPU가 2개 있으므로 기술적으로 가능합니다.

    $ oc create -f gpu-pod.yaml

    출력 예

    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

5.1.2. 할당량 범위

각 할당량에는 일련의 관련 범위가 있을 수 있습니다. 특정 할당량은 열거된 범위의 교집합과 일치하는 경우에만 리소스 사용량을 측정합니다.

할당량에 범위를 추가하면 할당량을 적용할 수 있는 리소스 세트가 제한됩니다. 허용된 설정을 벗어난 리소스를 지정하면 검증 오류가 발생합니다.

범위설명

Terminating

spec.activeDeadlineSeconds©= 0인 Pod와 일치합니다.

NotTerminating

spec.activeDeadlineSecondsnil인 Pod와 일치합니다.

BestEffort

cpu 또는 memory에 대해 최상의 작업 품질을 제공하는 Pod와 일치합니다.

otBestEffort

cpumemory에 최상의 작업 품질을 제공하지 않는 Pod와 일치합니다.

BestEffort 범위는 할당량을 제한하여 다음 리소스를 제한합니다.

  • pods

Terminating, NotTerminating, NotBestEffort 범위는 할당량을 제한하여 다음 리소스를 추적합니다.

  • pods
  • memory
  • requests.memory
  • limits.memory
  • cpu
  • requests.cpu
  • limits.cpu
  • ephemeral-storage
  • requests.ephemeral-storage
  • limits.ephemeral-storage
참고

이 기능은 기본적으로 비활성화되어 있습니다.

추가 리소스

5.2.

5.2.1. 할당량 적용

할당량이 생성되고 사용량 통계가 업데이트되면 프로젝트에서 새 콘텐츠 생성을 허용합니다. 리소스를 생성하거나 수정할 때는 리소스 생성 또는 수정 요청에 따라 할당량 사용이 즉시 증가합니다.

리소스를 삭제할 때는 프로젝트에 대한 다음 할당량 통계 전체 재계산 중 할당량 사용이 감소합니다.

구성 가능한 시간에 따라 현재 관찰되는 시스템 값으로 할당량 사용을 줄이는 데 걸리는 시간이 결정됩니다.

5.2.2.

할당량은 이러한 값 중을 제한할 수 있습니다.

할당량에 requests.cpu 또는 requests.memory에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스를 명시적으로 요청해야 합니다. 할당량에 limits.cpu 또는 limits.memory에 대해 지정된 값이 있는 경우 들어오는 모든 컨테이너에서 해당 리소스에 대한 제한을 명시적으로 지정해야 합니다.

5.2.3. 리소스 할당량 정의의 예

apiVersion: v1
kind: ResourceQuota
metadata:
  name: core-object-counts
spec:
  hard:
    configmaps: "10" 1
    persistentvolumeclaims: "4" 2
    replicationcontrollers: "20" 3
    secrets: "10" 4
    services: "10" 5

1
프로젝트에 존재할 수 있는 총 ConfigMap 오브젝트 수입니다.
2
프로젝트에 존재할 수 있는 총 PVC(영구 볼륨 클레임) 수입니다.
3
프로젝트에 존재할 수 있는 총 복제 컨트롤러 수입니다.
4
프로젝트에 존재할 수 있는 총 시크릿 수입니다.
5
프로젝트에 존재할 수 있는 총 서비스 수입니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" 1

1
프로젝트에 존재할 수 있는 총 이미지 스트림 수입니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
spec:
  hard:
    pods: "4" 1
    requests.cpu: "1" 2
    requests.memory: 1Gi 3
    requests.ephemeral-storage: 2Gi 4
    limits.cpu: "2" 5
    limits.memory: 2Gi 6
    limits.ephemeral-storage: 4Gi 7

1
프로젝트에 존재할 수 있는 터미널이 아닌 상태의 총 Pod 수입니다.
2
터미널이 아닌 상태에서 모든 Pod의 CPU 요청 합계는 코어 1개를 초과할 수 없습니다.
3
터미널이 아닌 상태에서 모든 Pod의 메모리 요청 합계는 1Gi를 초과할 수 없습니다.
4
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 요청 합계는 2Gi를 초과할 수 없습니다.
5
터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 코어 2개를 초과할 수 없습니다.
6
터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 2Gi를 초과할 수 없습니다.
7
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 4Gi를 초과할 수 없습니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: besteffort
spec:
  hard:
    pods: "1" 1
  scopes:
  - BestEffort 2

1
2

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-long-running
spec:
  hard:
    pods: "4" 1
    limits.cpu: "4" 2
    limits.memory: "2Gi" 3
    limits.ephemeral-storage: "4Gi" 4
  scopes:
  - NotTerminating 5

1
터미널이 아닌 상태의 총 Pod 수입니다.
2
터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
3
터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
4
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다.
5
할당량을 spec.activeDeadlineSecondsnil로 설정된 일치하는 Pod로만 제한합니다. 빌드 Pod는 RestartNever 정책을 적용하지 않는 한 NotTerminating에 해당합니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources-time-bound
spec:
  hard:
    pods: "2" 1
    limits.cpu: "1" 2
    limits.memory: "1Gi" 3
    limits.ephemeral-storage: "1Gi" 4
  scopes:
  - Terminating 5

1
터미널이 아닌 상태의 총 Pod 수입니다.
2
터미널이 아닌 상태에서 모든 Pod의 CPU 제한 합계는 이 값을 초과할 수 없습니다.
3
터미널이 아닌 상태에서 모든 Pod의 메모리 제한 합계는 이 값을 초과할 수 없습니다.
4
터미널이 아닌 상태에서 모든 Pod의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다.
5
할당량을 spec.activeDeadlineSeconds >=0인 일치하는 Pod로만 제한합니다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: storage-consumption
spec:
  hard:
    persistentvolumeclaims: "10" 1
    requests.storage: "50Gi" 2
    gold.storageclass.storage.k8s.io/requests.storage: "10Gi" 3
    silver.storageclass.storage.k8s.io/requests.storage: "20Gi" 4
    silver.storageclass.storage.k8s.io/persistentvolumeclaims: "5" 5
    bronze.storageclass.storage.k8s.io/requests.storage: "0" 6
    bronze.storageclass.storage.k8s.io/persistentvolumeclaims: "0" 7

1
프로젝트의 총 영구 볼륨 클레임 수
2
프로젝트의 모든 영구 볼륨 클레임에서 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
3
프로젝트의 모든 영구 볼륨 클레임에서 골드 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
4
프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다.
5
프로젝트의 모든 영구 볼륨 클레임에서 실버 스토리지 클래스의 총 클레임 수는 이 값을 초과할 수 없습니다.
6
프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 스토리지를 요청할 수 없습니다.
7
프로젝트의 모든 영구 볼륨 클레임에서 브론즈 스토리지 클래스에 요청된 스토리지 합계는 이 값을 초과할 수 없습니다. 이 값을 0으로 설정하면 브론즈 스토리지 클래스에서 클레임을 생성할 수 없습니다.

5.2.4. 할당량 생성

$ oc create -f <resource_quota_definition> [-n <project_name>]

$ oc create -f core-object-counts.yaml -n demoproject

5.2.5. 오브젝트 수 할당량 생성

모든 OpenShift Container Platform 표준 네임스페이스 리소스 유형(예: BuildConfig, DeploymentConfig)에 대해 오브젝트 수 할당량을 생성할 수 있습니다. 오브젝트 할당량 수는 모든 표준 네임스페이스 리소스 유형에 정의된 할당량을 지정합니다.

리소스 할당량을 사용할 때 서버 스토리지에 존재하는 경우 오브젝트는 할당량에 대해 부과됩니다. 이러한 유형의 할당량은 스토리지 리소스의 소진을 방지하는 데 유용합니다.

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>

$ oc create quota test --hard=count/deployments.extensions=2,count/replicasets.extensions=4,count/pods=3,count/secrets=4
resourcequota "test" created

$ oc describe quota test
Name:                         test
Namespace:                    quota
Resource                      Used  Hard
--------                      ----  ----
count/deployments.extensions  0     2
count/pods                    0     3
count/replicasets.extensions  0     4
count/secrets                 0     4

이 예제에서는 나열된 리소스가 클러스터에 있는 각 프로젝트의 하드 제한으로 제한됩니다.

5.2.6. 할당량 보기

  1. 예를 들어 demoproject라는 프로젝트의 경우 다음과 같습니다.

    $ oc get quota -n demoproject
    NAME                AGE
    besteffort          11m
    compute-resources   2m
    core-object-counts  29m
  2. 관심 있는 할당량을 입력합니다. 예를 들어 core-object-counts 할당량은 다음과 같습니다.

    $ oc describe quota core-object-counts -n demoproject
    Name:			core-object-counts
    Namespace:		demoproject
    Resource		Used	Hard
    --------		----	----
    configmaps		3	10
    persistentvolumeclaims	0	4
    replicationcontrollers	3	20
    secrets			9	10
    services		2	10

5.2.7.

kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"

$ master-restart api
$ master-restart controllers

참고

5.2.8.

admissionConfig:
  pluginConfig:
    ResourceQuota:
      configuration:
        apiVersion: resourcequota.admission.k8s.io/v1alpha1
        kind: Configuration
        limitedResources:
        - resource: persistentvolumeclaims 1
        matchContains:
        - gold.storageclass.storage.k8s.io/requests.storage 2
1
2

추가 리소스

5.3.

리소스 생성 및 수정을 위한 모든 요청은 프로젝트의 각 LimitRange 오브젝트에 대해 평가됩니다. 리소스가 열거된 제약 조건을 위반하는 경우 해당 리소스는 거부됩니다.

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "core-resource-limits" 1
spec:
  limits:
    - type: "Pod"
      max:
        cpu: "2" 2
        memory: "1Gi" 3
      min:
        cpu: "200m" 4
        memory: "6Mi" 5
    - type: "Container"
      max:
        cpu: "2" 6
        memory: "1Gi" 7
      min:
        cpu: "100m" 8
        memory: "4Mi" 9
      default:
        cpu: "300m" 10
        memory: "200Mi" 11
      defaultRequest:
        cpu: "200m" 12
        memory: "100Mi" 13
      maxLimitRequestRatio:
        cpu: "10" 14

1
제한 범위 오브젝트의 이름입니다.
2
3
4
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최소 CPU 양입니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과가 제한이 없으며 Pod에서 max CPU 값보다 더 많이 사용할 수 있습니다.
5
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최소 메모리 양입니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과가 제한이 없으며 Pod에서 max 메모리 값보다 더 많이 사용할 수 있습니다.
6
Pod의 단일 컨테이너에서 요청할 수 있는 최대 CPU 양입니다.
7
Pod의 단일 컨테이너에서 요청할 수 있는 최대 메모리 양입니다.
8
Pod의 단일 컨테이너에서 요청할 수 있는 최소 CPU 양입니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과가 제한이 없으며 Pod에서 max CPU 값보다 더 많이 사용할 수 있습니다.
9
Pod의 단일 컨테이너에서 요청할 수 있는 최소 메모리 양입니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과가 제한이 없으며 Pod에서 max 메모리 값보다 더 많이 사용할 수 있습니다.
10
Pod 사양에 제한을 지정하지 않는 경우 컨테이너의 기본 CPU 제한입니다.
11
Pod 사양에 제한을 지정하지 않는 경우 컨테이너의 기본 메모리 제한입니다.
12
Pod 사양에 요청을 지정하지 않는 경우 컨테이너에 대한 기본 CPU 요청입니다.
13
Pod 사양에 요청을 지정하지 않는 경우 컨테이너에 대한 기본 메모리 요청입니다.
14
컨테이너에 대한 최대 제한 대 요청 비율입니다.

OpenShift Container Platform 제한 범위 오브젝트 정의

apiVersion: "v1"
kind: "LimitRange"
metadata:
  name: "openshift-resource-limits"
spec:
  limits:
    - type: openshift.io/Image
      max:
        storage: 1Gi 1
    - type: openshift.io/ImageStream
      max:
        openshift.io/image-tags: 20 2
        openshift.io/images: 30 3
    - type: "Pod"
      max:
        cpu: "2" 4
        memory: "1Gi" 5
        ephemeral-storage: "1Gi" 6
      min:
        cpu: "1" 7
        memory: "1Gi" 8

1
내부 레지스트리로 내보낼 수 있는 이미지의 최대 크기입니다.
2
이미지 스트림 사양에 정의된 최대 고유 이미지 태그 수입니다.
3
이미지 스트림 상태에 대한 사양에 정의된 최대 고유 이미지 참조 수입니다.
4
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최대 CPU 양입니다.
5
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최대 메모리 양입니다.
6
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최대 임시 스토리지 양입니다.
7
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최소 CPU 양입니다. 중요한 정보는 지원되는 제약 조건 표를 참조하십시오.
8
Pod에서 모든 컨테이너의 노드에 요청할 수 있는 최소 메모리 양입니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과 값이 제한이 아니며 Pod에서 max 메모리 값보다 더 많이 사용할 수 있습니다.

코어 및 OpenShift Container Platform 리소스를 모두 하나의 제한 범위 오브젝트로 지정할 수 있습니다.

5.3.1. 컨테이너 제한

지원되는 리소스:

  • CPU
  • 메모리

지원되는 제한

지정된 경우 컨테이너별로 다음이 true여야 합니다.

컨테이너

제약 조건동작

min[<resource>] container.resources.requests[<resource>] (필수) container/resources.limits[<resource>] 보다 작거나 같습니다(선택 사항)

구성에서 min CPU를 정의하는 경우 요청 값이 CPU 값보다 커야 합니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과가 제한이 없으며 Pod에서 max 값보다 더 많은 리소스를 사용할 수 있습니다.

Max

container.resources.limits[<resource>] (필수) Max[<resource>]보다 작거나 같습니다.

구성에서 max CPU를 정의하는 경우 CPU 요청 값을 정의할 필요가 없습니다. 그러나 제한 범위에 지정된 최대 CPU 제약 조건을 충족하는 제한을 설정해야 합니다.

MaxLimitRequestRatio

max LimitRequestRatio[<resource>] less than or equal (container.resources[<resource>] / container.resources.requests[<resource>])

제한 범위가 maxLimitRequestRatio 제약 조건을 정의하는 경우 새 컨테이너에 requestlimit 값이 모두 있어야 합니다. 또한 OpenShift Container Platform은 제한을 요청으로 나눠 제한 대 요청 비율을 계산합니다. 결과는 1보다 큰 정수여야 합니다.

예를 들어 컨테이너의 limit 값이 cpu: 500이고 request 값이 cpu: 100인 경우 cpu의 제한 대 요청 비율은 5입니다. 이 비율은 maxLimitRequestRatio보다 작거나 같아야 합니다.

지원되는 기본값:

default[<resource>]
기본값은 container.resources.limit[<resource>] to specified value if none입니다.
기본 요청[<resource>]
기본값은 container.resources.requests[<resource>] to specified value if none입니다.

5.3.2. Pod 제한

지원되는 리소스:

  • CPU
  • 메모리

지원되는 제한 사항:

Pod의 모든 컨테이너에서 다음 사항이 충족되어야 합니다.

표 5.4. Pod
제약 조건강제 동작

min[<resource>] container.resources.requests[<resource>] (필수) container.resources.limits[<resource>] 보다 작거나 같습니다. min 값을 설정하지 않거나 min0 으로 설정하면 결과가 제한이 없으며 Pod에서 max 값보다 더 많은 리소스를 사용할 수 있습니다.

Max

container.resources.limits[<resource>] (필수) Max[<resource>].

MaxLimitRequestRatio

max LimitRequestRatio[<resource>] 보다 작거나 같습니다(container.resources[<resource>] / container.resources.requests[<resource>]).

5.3.3. 이미지 제한

지원되는 리소스:

  • 스토리지

리소스 유형 이름:

  • openshift.io/Image

지정된 경우 이미지당 다음 사항이 충족되어야 합니다.

표 5.5. 이미지
제약 조건동작

Max

image.dockerimagemetadata.size less than or equal to Max[<resource>]

참고

제한을 초과하는 Blob이 레지스트리에 업로드되지 않도록 하려면 할당량을 적용하도록 레지스트리를 구성해야 합니다. REGISTRY_MIDDLEWARE_REPOSITORY_OPENSHIFT_ENFORCEQUOTA 환경 변수를 true 로 설정해야 합니다. 새 배포에 대해 기본적으로 환경 변수는 true 로 설정됩니다.

5.3.4. 이미지 스트림 제한

지원되는 리소스:

  • openshift.io/image-tags
  • openshift.io/images

리소스 유형 이름:

  • openshift.io/ImageStream

지정된 경우 이미지 스트림별로 다음 사항이 충족되어야 합니다.

표 5.6. ImageStream
제약 조건동작

Max[openshift.io/image-tags]

Length( uniqueimagetags( imagestream.spec.tags )) Max[openshift.io/image-tags]보다 작거나 같습니다.

uniqueimagetags 는 지정된 spec 태그의 이미지에 대한 고유한 참조를 반환합니다.

Max[openshift.io/images]

Length( uniqueimages( imagestream.status.tags ) ) Max[openshift.io/images]보다 작거나 같습니다.

uniqueimages 는 상태 태그에 있는 고유한 이미지 이름을 반환합니다. 이름은 이미지의 다이제스트와 동일합니다.

5.3.5. 이미지 참조 수

openshift.io/image-tags 리소스는 고유한 스트림 제한을 나타냅니다. 가능한 참조는 ImageStreamTag, ImageStreamImage 또는 DockerImage 입니다. 태그는 oc tagoc import-image 명령을 사용하거나 이미지 스트림을 사용하여 생성할 수 있습니다. 내부 참조와 외부 참조는 구분되지 않습니다. 그러나 이미지 스트림 사양에 태그된 각 고유 참조는 한 번만 계산됩니다. 내부 컨테이너 이미지 레지스트리에 대한 내보내기는 어떤 방식으로든 제한하지 않지만 태그 제한에 유용합니다.

openshift.io/images 리소스는 이미지 스트림 상태에 기록된 고유한 이미지 이름을 나타냅니다. 내부 레지스트리로 내보낼 수 있는 여러 이미지를 제한하는 데 도움이 됩니다. 내부 및 외부 참조는 구분되지 않습니다.

5.3.6. PersistentVolumeClaim 제한

지원되는 리소스:

  • 스토리지

지원되는 제한 사항:

프로젝트의 모든 영구 볼륨 클레임에서 다음 사항이 충족되어야 합니다.

표 5.7. Pod
제약 조건강제 동작

min[<resource>] <= claim.spec.resources.requests[<resource>] (필수)

Max

claim.spec.resources.requests[<resource>] (필수) <= Max[<resource>]

제한 범위 오브젝트 정의

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs" 1
  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi" 2
        },
        "max": {
          "storage": "50Gi" 3
        }
      }
    ]
  }
}

1
제한 범위 오브젝트의 이름입니다.
2
영구 볼륨 클레임에서 요청할 수 있는 최소 스토리지 양입니다.
3
영구 볼륨 클레임에서 요청할 수 있는 최대 스토리지 양입니다.

추가 리소스

스트림 제한에 대한 자세한 내용은 이미지 스트림 관리를 참조하십시오.

스트림 제한에 대한 자세한 내용은 다음을 수행합니다.

컴퓨팅 리소스 제약 조건에 대한 자세한 내용은 다음을 수행합니다.

CPU 및 메모리 측정 방법에 대한 자세한 내용은 권장 컨트롤 플레인 관행을 참조하십시오.

임시 스토리지에 대한 제한 및 요청을 지정할 수 있습니다. 이 기능에 대한 자세한 내용은 임시 스토리지 이해 를 참조하십시오.

5.4. 제한 범위 작업

5.4.1. 제한 범위 생성

다음은 제한 범위를 생성하기 위해 따라야 하는 절차의 예입니다.

프로세스

  1. 오브젝트를 생성합니다.

    $ oc create -f <limit_range_file> -n <project>

5.4.2. 제한 보기

웹 콘솔에서 프로젝트의 할당량 페이지로 이동하여 프로젝트에 정의된 제한 범위를 볼 수 있습니다. CLI를 사용하여 다음 단계를 수행하여 제한 범위 세부 정보를 볼 수도 있습니다.

프로세스

  1. 프로젝트에 정의된 제한 범위 오브젝트 목록을 가져옵니다. 예를 들어 demoproject 라는 프로젝트는 다음과 같습니다.

    $ oc get limits -n demoproject

    출력 예

    NAME              AGE
    resource-limits   6d

  2. 제한 범위를 설명합니다. 예를 들어 resource-limits 라는 제한 범위의 경우 다음을 수행합니다.

    $ oc describe limits resource-limits -n demoproject

    출력 예

    Name:                           resource-limits
    Namespace:                      demoproject
    Type                            Resource                Min     Max     Default Request Default Limit   Max Limit/Request Ratio
    ----                            --------                ---     ---     --------------- -------------   -----------------------
    Pod                             cpu                     200m    2       -               -               -
    Pod                             memory                  6Mi     1Gi     -               -               -
    Container                       cpu                     100m    2       200m            300m            10
    Container                       memory                  4Mi     1Gi     100Mi           200Mi           -
    openshift.io/Image              storage                 -       1Gi     -               -               -
    openshift.io/ImageStream        openshift.io/image      -       12      -               -               -
    openshift.io/ImageStream        openshift.io/image-tags -       10      -               -               -

5.4.3. 제한 범위 삭제

제한 범위를 제거하려면 다음 명령을 실행합니다.

+

$ oc delete limits <limit_name>

S

추가 리소스

사용자가 프로젝트 리소스에 대해 생성, 제한 및 할당량을 관리할 수 있는 프로젝트 수에 대한 다양한 제한을 적용하는 방법에 대한 자세한 내용은 프로젝트당 리소스 할당량을 참조하십시오.

7장. Node Tuning Operator 사용

Node Tuning Operator에 대해 알아보고, Node Tuning Operator를 사용하여 Tuned 데몬을 오케스트레이션하고 노드 수준 튜닝을 관리하는 방법도 알아봅니다.

7.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에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서 이 기능은 Node Tuning Operator의 일부입니다.

7.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

기본 CR은 OpenShift Container Platform 플랫폼의 표준 노드 수준 튜닝을 제공하기 위한 것이며 Operator 관리 상태를 설정하는 경우에만 수정할 수 있습니다. Operator는 기본 CR에 대한 다른 모든 사용자 정의 변경사항을 덮어씁니다. 사용자 정의 튜닝의 경우 고유한 Tuned CR을 생성합니다. 새로 생성된 CR은 노드 또는 Pod 라벨 및 프로필 우선 순위에 따라 OpenShift Container Platform 노드에 적용된 기본 CR 및 사용자 정의 튜닝과 결합됩니다.

주의

특정 상황에서는 Pod 라벨에 대한 지원이 필요한 튜닝을 자동으로 제공하는 편리한 방법일 수 있지만 이러한 방법은 권장되지 않으며 특히 대규모 클러스터에서는 이러한 방법을 사용하지 않는 것이 좋습니다. 기본 Tuned CR은 Pod 라벨이 일치되지 않은 상태로 제공됩니다. Pod 라벨이 일치된 상태로 사용자 정의 프로필이 생성되면 해당 시점에 이 기능이 활성화됩니다. Pod 레이블 기능은 Node Tuning Operator의 향후 버전에서 더 이상 사용되지 않습니다.

7.3. 클러스터에 설정된 기본 프로필

다음은 클러스터에 설정된 기본 프로필입니다.

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Optimize systems running OpenShift (provider specific parent profile)
      include=-provider-${f:exec:cat:/var/lib/tuned/provider},openshift
    name: openshift
  recommend:
  - profile: openshift-control-plane
    priority: 30
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
  - profile: openshift-node
    priority: 40

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 ^ {} \;

7.4. TuneD 프로필이 적용되었는지 검증

클러스터 노드에 적용되는 TuneD 프로필을 확인합니다.

$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

출력 예

NAME             TUNED                     APPLIED   DEGRADED   AGE
master-0         openshift-control-plane   True      False      6h33m
master-1         openshift-control-plane   True      False      6h33m
master-2         openshift-control-plane   True      False      6h33m
worker-a         openshift-node            True      False      6h28m
worker-b         openshift-node            True      False      6h28m

  • NAME: Profile 오브젝트의 이름입니다. 노드당 하나의 Profile 오브젝트가 있고 해당 이름이 일치합니다.
  • TUNED: 적용할 TuneD 프로파일의 이름입니다.
  • APPLIED: TuneD 데몬이 원하는 프로필을 적용한 경우 True입니다. (True/False/Unknown).
  • DEGRADED: TuneD 프로파일 적용 중에 오류가 보고된 경우 (True/False/Unknown).
  • AGE: Profile 개체 생성 이후 경과 시간입니다.

ClusterOperator/node-tuning 오브젝트에는 Operator 및 해당 노드 에이전트의 상태에 대한 유용한 정보도 포함되어 있습니다. 예를 들어 Operator 구성 오류는 ClusterOperator/node-tuning 상태 메시지에 의해 보고됩니다.

ClusterOperator/node-tuning 오브젝트에 대한 상태 정보를 가져오려면 다음 명령을 실행합니다.

$ oc get co/node-tuning -n openshift-cluster-node-tuning-operator

출력 예

NAME          VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
node-tuning   4.14.1    True        False         True       60m     1/5 Profiles with bootcmdline conflict

ClusterOperator/node-tuning 또는 프로파일 오브젝트의 상태가 DEGRADED 인 경우 Operator 또는 피연산자 로그에 추가 정보가 제공됩니다.

7.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:
- name: tuned_profile_1
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_1 profile

    [sysctl]
    net.ipv4.ip_forward=1
    # ... other sysctl's or other TuneD daemon plugins supported by the containerized TuneD

# ...

- name: tuned_profile_n
  data: |
    # TuneD profile specification
    [main]
    summary=Description of tuned_profile_n profile

    # tuned_profile_n profile settings

권장 프로필

profile: 선택 논리는 CR의 recommend: 섹션에 의해 정의됩니다. recommend: 섹션은 선택 기준에 따라 프로필을 권장하는 항목의 목록입니다.

recommend:
<recommend-item-1>
# ...
<recommend-item-n>

목록의 개별 항목은 다음과 같습니다.

- machineConfigLabels: 1
    <mcLabels> 2
  match: 3
    <match> 4
  priority: <priority> 5
  profile: <tuned_profile_name> 6
  operand: 7
    debug: <bool> 8
    tunedConfig:
      reapply_sysctl: <bool> 9
1
선택 사항:
2
키/값 MachineConfig 라벨 사전입니다. 키는 고유해야 합니다.
3
생략하면 우선 순위가 높은 프로필이 먼저 일치되거나 machineConfigLabels가 설정되어 있지 않으면 프로필이 일치하는 것으로 가정합니다.
4
선택사항 목록입니다.
5
프로필 순서 지정 우선 순위입니다. 숫자가 작을수록 우선 순위가 높습니다(0이 가장 높은 우선 순위임).
6
일치에 적용할 TuneD 프로필입니다. 예를 들어 tuned_profile_1이 있습니다.
7
선택적 피연산자 구성입니다.
8
TuneD 데몬에 대해 디버깅을 켜거나 끕니다. on 또는 false 의 경우 옵션은 true 입니다. 기본값은 false입니다.
9
TuneD 데몬의 경우 reapply_sysctl 기능을 켭니다. on 및 false 의 경우 옵션은 true 입니다.

<match>는 다음과 같이 재귀적으로 정의되는 선택사항 목록입니다.

- label: <label_name> 1
  value: <label_value> 2
  type: <label_type> 3
    <match> 4
1
노드 또는 Pod 라벨 이름입니다.
2
선택사항 노드 또는 Pod 라벨 값입니다. 생략하면 <label_name>이 있기 때문에 일치 조건을 충족합니다.
3
선택사항 오브젝트 유형(node 또는 pod)입니다. 생략하면 node라고 가정합니다.
4
선택사항 <match> 목록입니다.

<match>를 생략하지 않으면 모든 중첩 <match> 섹션도 true로 평가되어야 합니다. 생략하면 false로 가정하고 해당 <match> 섹션이 있는 프로필을 적용하지 않거나 권장하지 않습니다. 따라서 중첩(하위 <match> 섹션)은 논리 AND 연산자 역할을 합니다. 반대로 <match> 목록의 항목이 일치하면 전체 <match> 목록이 true로 평가됩니다. 따라서 이 목록이 논리 OR 연산자 역할을 합니다.

machineConfigLabels가 정의되면 지정된 recommend: 목록 항목에 대해 머신 구성 풀 기반 일치가 설정됩니다. <mcLabels>는 머신 구성의 라벨을 지정합니다. 머신 구성은 <tuned_profile_name> 프로필에 대해 커널 부팅 매개변수와 같은 호스트 설정을 적용하기 위해 자동으로 생성됩니다. 여기에는 <mcLabels>와 일치하는 머신 구성 선택기가 있는 모든 머신 구성 풀을 찾고 머신 구성 풀이 할당된 모든 노드에서 <tuned_profile_name> 프로필을 설정하는 작업이 포함됩니다. 마스터 및 작업자 역할이 모두 있는 노드를 대상으로 하려면 마스터 역할을 사용해야 합니다.

목록 항목 matchmachineConfigLabels는 논리 OR 연산자로 연결됩니다. match 항목은 단락 방식으로 먼저 평가됩니다. 따라서 true로 평가되면 machineConfigLabels 항목이 고려되지 않습니다.

중요

머신 구성 풀 기반 일치를 사용하는 경우 동일한 하드웨어 구성을 가진 노드를 동일한 머신 구성 풀로 그룹화하는 것이 좋습니다. 이 방법을 따르지 않으면 TuneD 피연산자가 동일한 머신 구성 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.

예: 노드 또는 Pod 라벨 기반 일치

- match:
  - label: tuned.openshift.io/elasticsearch
    match:
    - label: node-role.kubernetes.io/master
    - label: node-role.kubernetes.io/infra
    type: pod
  priority: 10
  profile: openshift-control-plane-es
- match:
  - label: node-role.kubernetes.io/master
  - label: node-role.kubernetes.io/infra
  priority: 20
  profile: openshift-control-plane
- priority: 30
  profile: openshift-node

위의 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 프로필 역할을 합니다.

결정 워크플로

예: 머신 구성 풀 기반 일치

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-custom
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile with an additional kernel parameter
      include=openshift-node
      [bootloader]
      cmdline_openshift_node_custom=+skew_tick=1
    name: openshift-node-custom

  recommend:
  - machineConfigLabels:
      machineconfiguration.openshift.io/role: "worker-custom"
    priority: 20
    profile: openshift-node-custom

노드 재부팅을 최소화하려면 머신 구성 풀의 노드 선택기와 일치하는 라벨로 대상 노드에 라벨을 지정한 후 위의 Tuned CR을 생성하고 마지막으로 사용자 정의 머신 구성 풀을 생성합니다.

클라우드 공급자별 TuneD 프로필

이 기능을 사용하면 모든 클라우드 공급자별 노드에 OpenShift Container Platform 클러스터의 지정된 클라우드 공급자에 특별히 맞춰진 TuneD 프로필을 편리하게 할당할 수 있습니다. 이 작업은 노드를 머신 구성 풀에 추가하거나 노드를 그룹화하지 않고 수행할 수 있습니다.

이 기능은 <cloud-provider> ://<cloud-provider-specific-id> 형식의 spec.provider ID 노드 오브젝트 값을 활용하고 NTO 피연산자 컨테이너의 < cloud-provider> 값으로 /var/lib/tuned/provider 파일을 씁니다. 그런 다음 이 파일의 내용은 해당 프로필이 존재하는 경우 TuneD에서 provider-<cloud-provider > 프로필을 로드하는 데 사용됩니다.

이제 openshift -control-planeopenshift-node 프로필에서 설정을 상속하는 openshift 프로파일이 조건부 프로필 로드를 사용하여 이 기능을 사용하도록 업데이트되었습니다. NTO 및 TuneD에는 현재 클라우드 공급자별 프로필이 포함되어 있지 않습니다. 그러나 모든 Cloud 공급자별 클러스터 노드에 적용할 사용자 지정 프로필 provider-<cloud- provider>를 생성할 수 있습니다.

GCE 클라우드 공급자 프로파일의 예

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: provider-gce
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=GCE Cloud provider-specific profile
      # Your tuning for GCE Cloud provider goes here.
    name: provider-gce

참고

프로필 상속으로 인해 provider-< cloud-provider > 프로필에 지정된 모든 설정은 openshift 프로필 및 해당 하위 프로필이 덮어씁니다.

7.6. 사용자 정의 튜닝 예

기본 CR에서 TuneD 프로파일 사용

다음 CR에서는 tuned.openshift.io/ingress-node-label 레이블이 임의의 값으로 설정된 OpenShift Container Platform 노드에 대해 사용자 정의 노드 수준 튜닝을 적용합니다.

예: openshift-control-plane TuneD 프로필을 사용한 사용자 정의 튜닝

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: ingress
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=A custom OpenShift ingress profile
      include=openshift-control-plane
      [sysctl]
      net.ipv4.ip_local_port_range="1024 65535"
      net.ipv4.tcp_tw_reuse=1
    name: openshift-ingress
  recommend:
  - match:
    - label: tuned.openshift.io/ingress-node-label
    priority: 10
    profile: openshift-ingress

중요

사용자 정의 프로필 작성자는 기본 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|^.*/||'

사용자 정의 튜닝 사양에서 이 명령으로 검색한 프로필 이름을 사용할 수 있습니다.

예: 기본 제공 hpc-compute TuneD 프로필 사용

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-node-hpc-compute
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift node profile for HPC compute workloads
      include=openshift-node,hpc-compute
    name: openshift-node-hpc-compute

  recommend:
  - match:
    - label: tuned.openshift.io/openshift-node-hpc-compute
    priority: 20
    profile: openshift-node-hpc-compute

기본 제공 hpc-compute 프로필 외에도 위의 예제에는 기본 Tuned CR 내에 제공된 openshift-node TuneD 데몬 프로필이 포함되어 컴퓨팅 노드에 OpenShift별 튜닝을 사용합니다.

호스트 수준 sysctl 덮어쓰기

/run/sysctl.d/, /etc/sysctl.d/, /etc/sysctl.conf 호스트 구성 파일을 사용하여 런타임 시 다양한 커널 매개변수를 변경할 수 있습니다. OpenShift Container Platform은 런타임 시 커널 매개변수를 설정하는 여러 호스트 구성 파일을 추가합니다(예: net.ipv[4-6]., fs.inotify., vm.max_map_count ). 이러한 런타임 매개변수는 kubelet 및 Operator가 시작되기 전에 시스템에 대한 기본 기능 튜닝을 제공합니다.

reapply_sysctl 옵션이 false 로 설정되지 않는 한 Operator는 이러한 설정을 재정의하지 않습니다. 이 옵션을 false 로 설정하면 사용자 지정 프로필이 적용된 후 TuneD 가 호스트 구성 파일의 설정을 적용하지 않습니다.

예: 호스트 수준 sysctl 덮어쓰기

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: openshift-no-reapply-sysctl
  namespace: openshift-cluster-node-tuning-operator
spec:
  profile:
  - data: |
      [main]
      summary=Custom OpenShift profile
      include=openshift-node
      [sysctl]
      vm.max_map_count=>524288
    name: openshift-no-reapply-sysctl
  recommend:
  - match:
    - label: tuned.openshift.io/openshift-no-reapply-sysctl
    priority: 15
    profile: openshift-no-reapply-sysctl
    operand:
      tunedConfig:
        reapply_sysctl: false

7.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) 작업자 노드만 지원합니다.

7.8. 호스트 클러스터에서 노드 튜닝 구성

호스팅된 클러스터의 노드에 노드 수준 튜닝을 설정하려면 Node Tuning Operator를 사용할 수 있습니다. 호스팅된 컨트롤 플레인에서는 Tuned 오브젝트가 포함된 구성 맵을 생성하고 노드 풀에 해당 구성 맵을 참조하여 노드 튜닝을 구성할 수 있습니다.

절차

  1. 유효한 tuned 매니페스트가 포함된 구성 맵을 생성하고 노드 풀에서 매니페스트를 참조합니다. 다음 예에서 Tuned 매니페스트는 tuned-1-node-label 노드 라벨이 임의의 값이 포함된 노드에서 vm.dirty_ratio 를 55로 설정하는 프로필을 정의합니다. tuned-1.yaml 이라는 파일에 다음 ConfigMap 매니페스트를 저장합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: tuned-1
          namespace: clusters
        data:
          tuning: |
            apiVersion: tuned.openshift.io/v1
            kind: Tuned
            metadata:
              name: tuned-1
              namespace: openshift-cluster-node-tuning-operator
            spec:
              profile:
              - data: |
                  [main]
                  summary=Custom OpenShift profile
                  include=openshift-node
                  [sysctl]
                  vm.dirty_ratio="55"
                name: tuned-1-profile
              recommend:
              - priority: 20
                profile: tuned-1-profile
    참고

    Tuned 사양의 spec.recommend 섹션에 있는 항목에 라벨을 추가하지 않으면 node-pool 기반 일치로 간주되므로 spec.recommend 섹션에서 가장 높은 우선 순위 프로필이 풀의 노드에 적용됩니다. Tuned .spec.recommend.match 섹션에서 레이블 값을 설정하여 보다 세분화된 노드 레이블 기반 일치를 수행할 수 있지만 노드 레이블은 노드 풀의 .spec.management.upgradeType 값을 InPlace 로 설정하지 않는 한 업그레이드 중에 유지되지 않습니다.

  2. 관리 클러스터에 ConfigMap 오브젝트를 생성합니다.

    $ oc --kubeconfig="$MGMT_KUBECONFIG" create -f tuned-1.yaml
  3. 노드 풀을 편집하거나 하나를 생성하여 노드 풀의 spec.tuningConfig 필드에서 ConfigMap 오브젝트를 참조합니다. 이 예에서는 2개의 노드가 포함된 nodepool-1 이라는 NodePool 이 하나만 있다고 가정합니다.

        apiVersion: hypershift.openshift.io/v1alpha1
        kind: NodePool
        metadata:
          ...
          name: nodepool-1
          namespace: clusters
        ...
        spec:
          ...
          tuningConfig:
          - name: tuned-1
        status:
        ...
    참고

    여러 노드 풀에서 동일한 구성 맵을 참조할 수 있습니다. 호스팅된 컨트롤 플레인에서 Node Tuning Operator는 노드 풀 이름과 네임스페이스의 해시를 Tuned CR 이름에 추가하여 구별합니다. 이 경우 동일한 호스트 클러스터에 대해 다른 Tuned CR에 동일한 이름의 여러 TuneD 프로필을 생성하지 마십시오.

검증

이제 Tuned 매니페스트가 포함된 ConfigMap 오브젝트를 생성하여 NodePool 에서 참조하므로 Node Tuning Operator가 Tuned 오브젝트를 호스팅된 클러스터에 동기화합니다. 정의된 Tuned 오브젝트와 각 노드에 적용되는 TuneD 프로필을 확인할 수 있습니다.

  1. 호스트 클러스터에서 Tuned 오브젝트를 나열합니다.

    $ oc --kubeconfig="$HC_KUBECONFIG" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    출력 예

    NAME       AGE
    default    7m36s
    rendered   7m36s
    tuned-1    65s

  2. 호스팅된 클러스터의 Profile 오브젝트를 나열합니다.

    $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    출력 예

    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

    참고

    사용자 지정 프로필이 생성되지 않으면 기본적으로 openshift-node 프로필이 적용됩니다.

  3. 튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고 sysctl 값을 확인합니다.

    $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio

    출력 예

    vm.dirty_ratio = 55

7.9. 커널 부팅 매개변수를 설정하여 호스팅된 클러스터의 고급 노드 튜닝

커널 부팅 매개변수를 설정해야 하는 호스팅된 컨트롤 플레인의 고급 튜닝의 경우 Node Tuning Operator를 사용할 수도 있습니다. 다음 예제에서는 대규모 페이지가 예약된 노드 풀을 생성하는 방법을 보여줍니다.

프로세스

  1. 크기가 2MB인 대규모 페이지 10개를 생성하기 위한 Tuned 오브젝트 매니페스트가 포함된 ConfigMap 오브젝트를 생성합니다. 이 ConfigMap 매니페스트를 tuned-hugepages.yaml 이라는 파일에 저장합니다.

        apiVersion: v1
        kind: ConfigMap
        metadata:
          name: tuned-hugepages
          namespace: clusters
        data:
          tuning: |
            apiVersion: tuned.openshift.io/v1
            kind: Tuned
            metadata:
              name: hugepages
              namespace: openshift-cluster-node-tuning-operator
            spec:
              profile:
              - data: |
                  [main]
                  summary=Boot time configuration for hugepages
                  include=openshift-node
                  [bootloader]
                  cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50
                name: openshift-node-hugepages
              recommend:
              - priority: 20
                profile: openshift-node-hugepages
    참고

    .spec.recommend.match 필드는 의도적으로 비워 둡니다. 이 경우 이 Tuned 오브젝트는 이 ConfigMap 오브젝트가 참조되는 노드 풀의 모든 노드에 적용됩니다. 동일한 하드웨어 구성이 있는 노드를 동일한 노드 풀로 그룹화합니다. 그렇지 않으면 TuneD 피연산자가 동일한 노드 풀을 공유하는 두 개 이상의 노드에 대해 충돌하는 커널 매개변수를 계산할 수 있습니다.

  2. 관리 클러스터에 ConfigMap 오브젝트를 생성합니다.

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml 1
    1
    & lt;management_cluster_kubeconfig& gt;를 관리 클러스터 kubeconfig 파일의 이름으로 바꿉니다.
  3. NodePool 매니페스트 YAML 파일을 생성하고 NodePool 의 업그레이드 유형을 사용자 지정하고 spec.tuningConfig 섹션에서 생성한 ConfigMap 오브젝트를 참조합니다. NodePool 매니페스트를 생성하고 hcp CLI를 사용하여 hugepages-nodepool.yaml 이라는 파일에 저장합니다.

    $ hcp create nodepool aws \
      --cluster-name <hosted_cluster_name> \1
      --name <nodepool_name> \2
      --node-count <nodepool_replicas> \3
      --instance-type <instance_type> \4
      --render > hugepages-nodepool.yaml
    1
    & lt;hosted_cluster_name& gt;을 호스트된 클러스터 이름으로 바꿉니다.
    2
    & lt;nodepool_name >을 노드 풀 이름으로 바꿉니다.
    3
    & lt;nodepool_replicas >를 노드 풀 복제본 수(예: 2 )로 바꿉니다.
    4
    & lt;instance_type& gt;을 인스턴스 유형으로 바꿉니다(예: m5.2xlarge ).
    참고

    hcp create 명령의 --render 플래그는 시크릿을 렌더링하지 않습니다. 보안을 렌더링하려면 hcp create 명령에서 --render--render-sensitive 플래그를 모두 사용해야 합니다.

  4. hugepages-nodepool.yaml 파일에서 .spec.management.upgradeTypeInPlace 로 설정하고 .spec.tuningConfig 를 설정하여 사용자가 생성한 tuned-hugepages ConfigMap 오브젝트를 참조합니다.

        apiVersion: hypershift.openshift.io/v1alpha1
        kind: NodePool
        metadata:
          name: hugepages-nodepool
          namespace: clusters
          ...
        spec:
          management:
            ...
            upgradeType: InPlace
          ...
          tuningConfig:
          - name: tuned-hugepages
    참고

    MachineConfig 오브젝트를 적용할 때 노드의 불필요한 재생성을 방지하려면 .spec.management.upgradeTypeInPlace 로 설정합니다. 업그레이드 교체 유형을 사용하는 경우 노드가 완전히 삭제되고 TuneD 피연산자가 계산된 새 커널 부팅 매개변수를 적용할 때 새 노드가 대체될 수 있습니다.

  5. 관리 클러스터에서 NodePool 을 생성합니다.

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml

검증

노드를 사용할 수 있게 되면 컨테이너화된 TuneD 데몬은 적용된 TuneD 프로필을 기반으로 필요한 커널 부팅 매개변수를 계산합니다. 생성된 MachineConfig 오브젝트를 적용하기 위해 노드를 준비하고 재부팅한 후 TuneD 프로필이 적용되고 커널 부팅 매개변수가 설정되었는지 확인할 수 있습니다.

  1. 호스트 클러스터에서 Tuned 오브젝트를 나열합니다.

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    출력 예

    NAME                 AGE
    default              123m
    hugepages-8dfb1fed   1m23s
    rendered             123m

  2. 호스팅된 클러스터의 Profile 오브젝트를 나열합니다.

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator

    출력 예

    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

    NodePool 의 작업자 노드 모두 openshift-node-hugepages 프로필이 적용됩니다.

  3. 튜닝이 올바르게 적용되었는지 확인하려면 노드에서 디버그 쉘을 시작하고 /proc/cmdline 을 확인합니다.

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline

    출력 예

    BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50

추가 리소스

호스팅된 컨트롤 플레인에 대한 자세한 내용은 호스팅 컨트롤 플레인 을 참조하십시오.

8장. CPU 관리자 및 토폴로지 관리자 사용

CPU 관리자는 CPU 그룹을 관리하고 워크로드를 특정 CPU로 제한합니다.

CPU 관리자는 다음과 같은 속성 중 일부가 포함된 워크로드에 유용합니다.

  • 가능한 한 많은 CPU 시간이 필요합니다.
  • 프로세서 캐시 누락에 민감합니다.
  • 대기 시간이 짧은 네트워크 애플리케이션입니다.
  • 다른 프로세스와 조정하고 단일 프로세서 캐시 공유를 통해 얻는 이점이 있습니다.

토폴로지 관리자는 동일한 NUMA(Non-Uniform Memory Access) 노드의 모든 QoS(Quality of Service) 클래스에 대해 CPU 관리자, 장치 관리자, 기타 힌트 공급자로부터 힌트를 수집하여 CPU, SR-IOV VF, 기타 장치 리소스 등의 Pod 리소스를 정렬합니다.

토폴로지 관리자는 토폴로지 관리자 정책 및 요청된 Pod 리소스에 따라 수집된 힌트의 토폴로지 정보를 사용하여 노드에서 Pod를 수락하거나 거부할 수 있는지 결정합니다.

토폴로지 관리자는 하드웨어 가속기를 사용하여 대기 시간이 중요한 실행과 처리량이 높은 병렬 계산을 지원하는 워크로드에 유용합니다.

토폴로지 관리자를 사용하려면 정적 정책을 사용하여 CPU 관리자를 구성해야 합니다.

8.1. CPU 관리자 설정

프로세스

  1. 선택사항: 노드에 레이블을 지정합니다.

    # oc label node perf-node.example.com cpumanager=true
  2. CPU 관리자를 활성화해야 하는 노드의 MachineConfigPool을 편집합니다. 이 예에서는 모든 작업자의 CPU 관리자가 활성화됩니다.

    # oc edit machineconfigpool worker
  3. 작업자 머신 구성 풀에 레이블을 추가합니다.

    metadata:
      creationTimestamp: 2020-xx-xxx
      generation: 3
      labels:
        custom-kubelet: cpumanager-enabled
  4. KubeletConfig, cpumanager-kubeletconfig.yaml, CR(사용자 정의 리소스)을 생성합니다. 이전 단계에서 생성한 레이블을 참조하여 올바른 노드가 새 kubelet 구성으로 업데이트되도록 합니다. machineConfigPoolSelector 섹션을 참조하십시오.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 1
         cpuManagerReconcilePeriod: 5s 2
    1
    정책을 지정합니다.
    • none. 이 정책은 기존 기본 CPU 선호도 체계를 명시적으로 활성화하여 스케줄러가 자동으로 수행하는 것 이상으로 선호도를 제공하지 않도록 합니다. 이는 기본 정책입니다.
    • static. 이 정책은 정수 CPU 요청이 있는 보장된 Pod의 컨테이너를 허용합니다. 또한 노드의 전용 CPU로 액세스를 제한합니다. 적인 경우 소문자 s 를 사용해야 합니다.
    2
    선택 사항: CPU 관리자 조정 빈도를 지정합니다. 기본값은 5s입니다.
  5. 동적 kubelet 구성을 생성합니다.

    # oc create -f cpumanager-kubeletconfig.yaml

    그러면 kubelet 구성에 CPU 관리자 기능이 추가되고 필요한 경우 MCO(Machine Config Operator)가 노드를 재부팅합니다. CPU 관리자를 활성화하는 데는 재부팅이 필요하지 않습니다.

  6. 병합된 kubelet 구성을 확인합니다.

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7

    출력 예

           "ownerReferences": [
                {
                    "apiVersion": "machineconfiguration.openshift.io/v1",
                    "kind": "KubeletConfig",
                    "name": "cpumanager-enabled",
                    "uid": "7ed5616d-6b72-11e9-aae1-021e1ce18878"
                }
            ]

  7. 작업자에서 업데이트된 kubelet.conf를 확인합니다.

    # oc debug node/perf-node.example.com
    sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager

    출력 예

    cpuManagerPolicy: static        1
    cpuManagerReconcilePeriod: 5s   2

    1
    cpuManagerPolicyKubeletConfig CR을 생성할 때 정의됩니다.
    2
    KubeletConfig CR을 생성할 때 cpuManagerReconcilePeriod 가 정의됩니다.
  8. 코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다.

    # cat cpumanager-pod.yaml

    출력 예

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: cpumanager-
    spec:
      containers:
      - name: cpumanager
        image: gcr.io/google_containers/pause:3.2
        resources:
          requests:
            cpu: 1
            memory: "1G"
          limits:
            cpu: 1
            memory: "1G"
      nodeSelector:
        cpumanager: "true"

  9. Pod를 생성합니다.

    # oc create -f cpumanager-pod.yaml
  10. 레이블 지정한 노드에 Pod가 예약되어 있는지 검증합니다.

    # oc describe pod cpumanager

    출력 예

    Name:               cpumanager-6cqz7
    Namespace:          default
    Priority:           0
    PriorityClassName:  <none>
    Node:  perf-node.example.com/xxx.xx.xx.xxx
    ...
     Limits:
          cpu:     1
          memory:  1G
        Requests:
          cpu:        1
          memory:     1G
    ...
    QoS Class:       Guaranteed
    Node-Selectors:  cpumanager=true

  11. cgroups가 올바르게 설정되었는지 검증합니다. pause 프로세스의 PID(프로세스 ID)를 가져옵니다.

    # ├─init.scope
    │ └─1 /usr/lib/systemd/systemd --switched-root --system --deserialize 17
    └─kubepods.slice
      ├─kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice
      │ ├─crio-b5437308f1a574c542bdf08563b865c0345c8f8c0b0a655612c.scope
      │ └─32706 /pause

    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

    출력 예

    cpuset.cpus 1
    tasks 32706

  12. 작업에 허용되는 CPU 목록을 확인합니다.

    # grep ^Cpus_allowed_list /proc/32706/status

    출력 예

     Cpus_allowed_list:    1

  13. Guaranteed Pod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우 burstable QoS 계층의 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

    출력 예

    ...
    Capacity:
     attachable-volumes-aws-ebs:  39
     cpu:                         2
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      8162900Ki
     pods:                        250
    Allocatable:
     attachable-volumes-aws-ebs:  39
     cpu:                         1500m
     ephemeral-storage:           124768236Ki
     hugepages-1Gi:               0
     hugepages-2Mi:               0
     memory:                      7548500Ki
     pods:                        250
    -------                               ----                           ------------  ----------  ---------------  -------------  ---
      default                                 cpumanager-6cqz7               1 (66%)       1 (66%)     1G (12%)         1G (12%)       29m
    
    Allocated resources:
      (Total limits may be over 100 percent, i.e., overcommitted.)
      Resource                    Requests          Limits
      --------                    --------          ------
      cpu                         1440m (96%)       1 (66%)

    이 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

8.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 허용 실패가 발생합니다.

8.3. 토폴로지 관리자 설정

토폴로지 관리자를 사용하려면 cpumanager-enabled 라는 KubeletConfig CR(사용자 정의 리소스)에서 할당 정책을 구성해야 합니다. CPU 관리자를 설정한 경우 해당 파일이 존재할 수 있습니다. 파일이 없으면 파일을 생성할 수 있습니다.

사전 요구 사항

  • CPU 관리자 정책을 static으로 구성하십시오.

프로세스

토폴로지 관리자를 활성화하려면 다음을 수행합니다.

  1. 사용자 정의 리소스에서 토폴로지 관리자 할당 정책을 구성합니다.

    $ oc edit KubeletConfig cpumanager-enabled
    apiVersion: machineconfiguration.openshift.io/v1
    kind: KubeletConfig
    metadata:
      name: cpumanager-enabled
    spec:
      machineConfigPoolSelector:
        matchLabels:
          custom-kubelet: cpumanager-enabled
      kubeletConfig:
         cpuManagerPolicy: static 1
         cpuManagerReconcilePeriod: 5s
         topologyManagerPolicy: single-numa-node 2
    1
    이 매개변수는 소문자 s 를 사용하여 적이어야 합니다.
    2
    선택한 토폴로지 관리자 할당 정책을 지정합니다. 여기서는 정책이 single-numa-node입니다. 사용할 수 있는 값은 default, best-effort, restricted, single-numa-node입니다.

8.4. Pod와 토폴로지 관리자 정책 간의 상호 작용

아래 Pod 사양의 예는 Pod와 토폴로지 관리자 간 상호 작용을 보여주는 데 도움이 됩니다.

다음 Pod는 리소스 요청 또는 제한이 지정되어 있지 않기 때문에 BestEffort QoS 클래스에서 실행됩니다.

spec:
  containers:
  - name: nginx
    image: nginx

다음 Pod는 요청이 제한보다 작기 때문에 Burstable QoS 클래스에서 실행됩니다.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"

선택한 정책이 none이 아니면 토폴로지 관리자는 이러한 Pod 사양 중 하나를 고려하지 않습니다.

아래 마지막 예의 Pod는 요청이 제한과 동일하기 때문에 Guaranteed QoS 클래스에서 실행됩니다.

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"
      requests:
        memory: "200Mi"
        cpu: "2"
        example.com/device: "1"

토폴로지 관리자는 이러한 Pod를 고려합니다. 토폴로지 관리자는 CPU 관리자 및 장치 관리자인 힌트 공급자를 참조하여 Pod의 토폴로지 힌트를 가져옵니다.

토폴로지 관리자는 이 정보를 사용하여 이 컨테이너에 대한 최상의 토폴로지를 저장합니다. 이 Pod의 경우 CPU 관리자와 장치 관리자는 리소스 할당 단계에서 이러한 저장된 정보를 사용합니다.

9장. NUMA 인식 워크로드 예약

NUMA 인식 스케줄링 및 이를 사용하여 OpenShift Container Platform 클러스터에 고성능 워크로드를 배포하는 방법을 알아봅니다.

NUMA 리소스 Operator를 사용하면 동일한 NUMA 영역에 고성능 워크로드를 예약할 수 있습니다. 사용 가능한 클러스터 노드 NUMA 리소스와 워크로드를 관리하는 보조 스케줄러에 보고하는 노드 리소스를 배포합니다.

9.1. NUMA 인식 스케줄링 정보

NUMA 소개

NUMA(Non-Uniform Memory Access)는 서로 다른 CPU가 다른 속도로 다른 메모리 영역에 액세스할 수 있도록 하는 컴퓨팅 플랫폼 아키텍처입니다. NUMA 리소스 토폴로지는 계산 노드에서 서로 상대적인 CPU, 메모리 및 PCI 장치의 위치를 나타냅니다. 배치된 리소스는 동일한 NUMA 영역에 있다고 합니다. 고성능 애플리케이션의 경우 클러스터는 단일 NUMA 영역에서 Pod 워크로드를 처리해야 합니다.

성능 고려 사항

NUMA 아키텍처를 사용하면 여러 메모리 컨트롤러가 있는 CPU에서 메모리가 있는 위치에 관계없이 CPU 복잡한 CPU에서 사용 가능한 메모리를 사용할 수 있습니다. 이렇게 하면 성능이 저하될 때 유연성이 향상됩니다. NUMA 영역 외부에 있는 메모리를 사용하여 워크로드를 처리하는 CPU는 단일 NUMA 영역에서 처리된 워크로드보다 느립니다. 또한 I/O가 제한적인 워크로드의 경우 원격 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 예약에 대한 개괄적인 개요를 보여줍니다.

그림 9.1. NUMA 인식 스케줄링 개요

클러스터에서 다양한 구성 요소가 서로 상호 작용하는 방법을 보여주는 NUMA 인식 스케줄링 다이어그램
NodeResourceTopology API
NodeResourceTopology API는 각 컴퓨팅 노드에서 사용 가능한 NUMA 영역 리소스를 설명합니다.
NUMA 인식 스케줄러
NUMA 인식 보조 스케줄러는 NodeResourceTopology API에서 사용 가능한 NUMA 영역에 대한 정보를 수신하고 최적으로 처리할 수 있는 노드에서 고성능 워크로드를 예약합니다.
노드 토폴로지 내보내기
노드 토폴로지 내보내기는 각 컴퓨팅 노드에 대해 사용 가능한 NUMA 영역 리소스를 NodeResourceTopology API에 노출합니다. 노드 토폴로지 내보내기 데몬은 PodResources API를 사용하여 kubelet의 리소스 할당을 추적합니다.
PodResources API

PodResources API는 각 노드에 로컬이며 리소스 토폴로지 및 사용 가능한 리소스를 kubelet에 노출합니다.

참고

PodResources API의 List 끝점은 특정 컨테이너에 할당된 전용 CPU를 노출합니다. API는 공유 풀에 속하는 CPU를 노출하지 않습니다.

GetAllocatableResources 끝점은 노드에서 사용 가능한 할당 가능한 리소스를 노출합니다.

추가 리소스

  • 클러스터에서 보조 Pod 스케줄러를 실행하는 방법 및 보조 Pod 스케줄러를 사용하여 Pod를 배포하는 방법에 대한 자세한 내용은 보조 스케줄러 를 사용하여 Pod 예약을 참조하십시오.

9.2. NUMA Resources Operator 설치

NUMA 리소스 Operator는 NUMA 인식 워크로드 및 배포를 예약할 수 있는 리소스를 배포합니다. OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 NUMA 리소스 Operator를 설치할 수 있습니다.

9.2.1. CLI를 사용하여 NUMA 리소스 Operator 설치

클러스터 관리자는 CLI를 사용하여 Operator를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. NUMA Resources Operator의 네임스페이스를 생성합니다.

    1. 다음 YAML을 nro-namespace.yaml 파일에 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-numaresources
    2. 다음 명령을 실행하여 네임스페이스 CR을 생성합니다.

      $ oc create -f nro-namespace.yaml
  2. NUMA Resources Operator에 대한 Operator 그룹을 생성합니다.

    1. 다음 YAML을 nro-operatorgroup.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        targetNamespaces:
        - openshift-numaresources
    2. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다.

      $ oc create -f nro-operatorgroup.yaml
  3. NUMA Resources Operator에 대한 서브스크립션을 생성합니다.

    1. 다음 YAML을 nro-sub.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        channel: "4.14"
        name: numaresources-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다.

      $ oc create -f nro-sub.yaml

검증

  1. openshift-numaresources 네임스페이스에서 CSV 리소스를 검사하여 설치에 성공했는지 확인합니다. 다음 명령을 실행합니다.

    $ oc get csv -n openshift-numaresources

    출력 예

    NAME                             DISPLAY                  VERSION   REPLACES   PHASE
    numaresources-operator.v4.14.2   numaresources-operator   4.14.2               Succeeded

9.2.2. 웹 콘솔을 사용하여 NUMA Resources Operator 설치

클러스터 관리자는 웹 콘솔을 사용하여 NUMA 리소스 Operator를 설치할 수 있습니다.

프로세스

  1. NUMA Resources Operator의 네임스페이스를 생성합니다.

    1. OpenShift Container Platform 웹 콘솔에서 관리네임스페이스를 클릭합니다.
    2. 네임스페이스 생성을 클릭하고 이름 필드에 openshift-numaresources 를 입력한 다음 생성 을 클릭합니다.
  2. NUMA Resources Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 numaresources-operator 를 선택한 다음 설치를 클릭합니다.
    3. 설치된 네임스페이스 필드에서 openshift-numaresources 네임스페이스를 선택한 다음 설치를 클릭합니다.
  3. 선택 사항: NUMA Resources Operator가 성공적으로 설치되었는지 확인합니다.

    1. Operator설치된 Operator 페이지로 전환합니다.
    2. NUMA Resources Operatoropenshift-numaresources 네임스페이스에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.

      • Operator설치된 Operator 페이지로 이동하고 Operator 서브스크립션설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • 워크로드Pod 페이지로 이동하여 기본 프로젝트에서 Pod 로그를 확인합니다.

9.3. NUMA 인식 워크로드 예약

대기 시간에 민감한 워크로드를 실행하는 클러스터는 일반적으로 워크로드 대기 시간을 최소화하고 성능을 최적화하는 데 도움이 되는 성능 프로필을 제공합니다. NUMA 인식 스케줄러는 노드에 적용된 성능 프로필 설정과 관련하여 사용 가능한 노드 NUMA 리소스를 기반으로 워크로드를 배포합니다. NUMA 인식 배포와 워크로드의 성능 프로파일이 조합되면 성능을 극대화하는 방식으로 워크로드가 예약됩니다.

NUMA Resources Operator가 완전히 작동하려면 NUMAResourcesOperator 사용자 정의 리소스 및 NUMA 인식 보조 Pod 스케줄러를 배포해야 합니다.

9.3.1. NUMAResourcesOperator 사용자 정의 리소스 생성

NUMA Resources Operator를 설치한 경우 데몬 세트 및 API를 포함하여 NUMA 리소스 Operator 가 NUMA 인식 스케줄러를 지원하는 데 필요한 모든 클러스터 인프라를 설치하도록 지시하는 NUMAResourcesOperator CR(사용자 정의 리소스)을 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA Resources Operator를 설치합니다.

프로세스

  1. NUMAResourcesOperator 사용자 지정 리소스를 만듭니다.

    1. nrop.yaml 로 다음과 같은 최소한의 필수 YAML 파일 예제를 저장합니다.

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: "" 1
      1
      NUMA Resources Operator를 구성하려는 MachineConfigPool 과 일치해야 합니다. 예를 들어 통신 워크로드를 실행하는 데 예상되는 노드 집합을 지정하는 worker-cnf 라는 MachineConfigPool 을 생성할 수 있습니다.
    2. 다음 명령을 실행하여 NUMAResourcesOperator CR을 만듭니다.

      $ oc create -f nrop.yaml
      참고

      NUMAResourcesOperator 를 생성하면 해당 머신 구성 풀 및 영향을 받는 노드에서 재부팅이 트리거됩니다.

검증

  1. 다음 명령을 실행하여 NUMA Resources Operator가 성공적으로 배포되었는지 확인합니다.

    $ oc get numaresourcesoperators.nodetopology.openshift.io

    출력 예

    NAME                    AGE
    numaresourcesoperator   27s

  2. 몇 분 후에 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인합니다.

    $ oc get all -n openshift-numaresources

    출력 예

    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

9.3.2. NUMA 인식 보조 Pod 스케줄러 배포

NUMA Resources Operator를 설치한 후 NUMA 인식 보조 Pod 스케줄러를 배포하여 성능 향상을 위해 Pod 배치를 최적화하고 NUMA 기반 시스템에서 대기 시간을 줄입니다.

프로세스

  1. NUMA 인식 사용자 정의 Pod 스케줄러를 배포하는 NUMAResourcesScheduler 사용자 정의 리소스를 생성합니다.

    1. nro-scheduler.yaml 파일에 필요한 다음 최소 YAML을 저장합니다.

      apiVersion: nodetopology.openshift.io/v1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-rhel9:v4.14" 1
      1
      연결이 끊긴 환경에서 다음 작업 중 하나를 완료하여 이 이미지 확인을 구성해야 합니다.
      • ImageTagMirrorSet 사용자 정의 리소스(CR) 생성. 자세한 내용은 "추가 리소스" 섹션의 "이미지 레지스트리 저장소 미러링 구성"을 참조하십시오.
      • URL을 연결이 끊긴 레지스트리로 설정합니다.
    2. 다음 명령을 실행하여 NUMAResourcesScheduler CR을 만듭니다.

      $ oc create -f nro-scheduler.yaml
  2. 몇 초 후에 다음 명령을 실행하여 필요한 리소스가 성공적으로 배포되었는지 확인합니다.

    $ oc get all -n openshift-numaresources

    출력 예

    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
    pod/secondary-scheduler-847cb74f84-9whlm                1/1     Running   0          10m
    
    NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
    daemonset.apps/numaresourcesoperator-worker   3         3         3       3            3           node-role.kubernetes.io/worker=   98s
    
    NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
    deployment.apps/numaresources-controller-manager   1/1     1            1           12m
    deployment.apps/secondary-scheduler                1/1     1            1           10m
    
    NAME                                                          DESIRED   CURRENT   READY   AGE
    replicaset.apps/numaresources-controller-manager-7d9d84c58d   1         1         1       12m
    replicaset.apps/secondary-scheduler-847cb74f84                1         1         1       10m

9.3.3. 단일 NUMA 노드 정책 구성

NUMA Resources Operator는 클러스터에 단일 NUMA 노드 정책을 구성해야 합니다. 성능 프로필을 생성 및 적용하거나 KubeletConfig를 구성하면 두 가지 방법으로 이 작업을 수행할 수 있습니다.

참고

단일 NUMA 노드 정책을 구성하는 기본 방법은 성능 프로필을 적용하는 것입니다. PPC(Performance Profile Creator) 툴을 사용하여 성능 프로필을 생성할 수 있습니다. 클러스터에서 성능 프로필이 생성되면 KubeletConfigtuned 프로필과 같은 다른 튜닝 구성 요소가 자동으로 생성됩니다.

성능 프로필 생성에 대한 자세한 내용은 "추가 리소스" 섹션의 "성능 프로필 Creator 정보"를 참조하십시오.

9.3.4. 성능 프로파일의 예

이 예제 YAML은 PPC(Performance profile creator) 툴을 사용하여 생성된 성능 프로필을 보여줍니다.

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: performance
spec:
  cpu:
    isolated: "3"
    reserved: 0-2
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/worker: "" 1
  nodeSelector:
    node-role.kubernetes.io/worker: ""
  numa:
    topologyPolicy: single-numa-node 2
  realTimeKernel:
    enabled: true
  workloadHints:
    highPowerConsumption: true
    perPodPowerManagement: false
    realTime: true
1
NUMA Resources Operator를 구성하려는 MachineConfigPool 과 일치해야 합니다. 예를 들어 통신 워크로드를 실행하는 노드 집합을 지정하는 worker-cnf 라는 MachineConfigPool 을 생성할 수 있습니다.
2
topologyPolicysingle-numa-node 로 설정해야 합니다. PPC 툴을 실행할 때 topology-manager-policy 인수를 single-numa-node 로 설정하여 이 문제가 있는지 확인합니다.

9.3.5. KubeletConfig CRD 생성

단일 NUMA 노드 정책을 구성하는 권장 방법은 성능 프로필을 적용하는 것입니다. 또 다른 방법은 다음 절차에 표시된 대로 KubeletConfig CR(사용자 정의 리소스)을 생성하고 적용하는 것입니다.

프로세스

  1. 머신 프로필에 대한 Pod 승인 정책을 구성하는 KubeletConfig CR(사용자 정의 리소스)을 생성합니다.

    1. 다음 YAML을 nro-kubeletconfig.yaml 파일에 저장합니다.

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            pools.operator.machineconfiguration.openshift.io/worker: "" 1
        kubeletConfig:
          cpuManagerPolicy: "static" 2
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1" 3
          memoryManagerPolicy: "Static" 4
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 5
      1
      NUMAResourcesOperator CR의 machineConfigPoolSelector 와 일치하도록 이 레이블을 조정합니다.
      2
      cpuManagerPolicy 의 경우static 은 소문자 s 를 사용해야 합니다.
      3
      노드의 CPU에 따라 이를 조정합니다.
      4
      memoryManagerPolicy 의 경우정적 은 대문자 S 를 사용해야 합니다.
      5
      topologyManagerPolicysingle-numa-node 로 설정해야 합니다.
    2. 다음 명령을 실행하여 KubeletConfig CR을 생성합니다.

      $ oc create -f nro-kubeletconfig.yaml
      참고

      성능 프로필 또는 KubeletConfig 를 적용하면 노드 재부팅이 자동으로 트리거됩니다. 재부팅이 트리거되지 않은 경우 노드 그룹을 처리하는 KubeletConfig 의 레이블을 확인하여 문제를 해결할 수 있습니다.

9.3.6. NUMA 인식 스케줄러를 사용하여 워크로드 예약

topo-aware-scheduler 가 설치되면 NUMAResourcesOperatorNUMAResourcesScheduler CR이 적용되고 클러스터에 일치하는 성능 프로필 또는 kubeletconfig 가 적용되어 워크로드를 처리하는 데 필요한 최소 리소스를 지정하는 배포 CR을 사용하여 NUMA 인식 스케줄러로 워크로드를 예약할 수 있습니다.

다음 예제 배포에서는 샘플 워크로드에 대해 NUMA 인식 스케줄링을 사용합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 명령을 실행하여 클러스터에 배포된 NUMA 인식 스케줄러의 이름을 가져옵니다.

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    출력 예

    "topo-aware-scheduler"

  2. 스케줄러 이름이 topo-aware-schedulerDeployment CR을 생성합니다. 예를 들면 다음과 같습니다.

    1. 다음 YAML을 nro-deployment.yaml 파일에 저장합니다.

      apiVersion: apps/v1
      kind: Deployment
      metadata:
        name: numa-deployment-1
        namespace: openshift-numaresources
      spec:
        replicas: 1
        selector:
          matchLabels:
            app: test
        template:
          metadata:
            labels:
              app: test
          spec:
            schedulerName: topo-aware-scheduler 1
            containers:
            - name: ctnr
              image: quay.io/openshifttest/hello-openshift:openshift
              imagePullPolicy: IfNotPresent
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "10"
                requests:
                  memory: "100Mi"
                  cpu: "10"
            - name: ctnr2
              image: registry.access.redhat.com/rhel:latest
              imagePullPolicy: IfNotPresent
              command: ["/bin/sh", "-c"]
              args: [ "while true; do sleep 1h; done;" ]
              resources:
                limits:
                  memory: "100Mi"
                  cpu: "8"
                requests:
                  memory: "100Mi"
                  cpu: "8"
      1
      schedulerName 은 클러스터에 배포된 NUMA 인식 스케줄러의 이름(예: topo-aware-scheduler )과 일치해야 합니다.
    2. 다음 명령을 실행하여 Deployment CR을 생성합니다.

      $ oc create -f nro-deployment.yaml

검증

  1. 배포에 성공했는지 확인합니다.

    $ oc get pods -n openshift-numaresources

    출력 예

    NAME                                                READY   STATUS    RESTARTS   AGE
    numa-deployment-1-6c4f5bdb84-wgn6g                  2/2     Running   0          5m2s
    numaresources-controller-manager-7d9d84c58d-4v65j   1/1     Running   0          18m
    numaresourcesoperator-worker-7d96r                  2/2     Running   4          43m
    numaresourcesoperator-worker-crsht                  2/2     Running   2          43m
    numaresourcesoperator-worker-jp9mw                  2/2     Running   2          43m
    secondary-scheduler-847cb74f84-fpncj                1/1     Running   0          18m

  2. topo-aware-scheduler 에서 다음 명령을 실행하여 배포된 Pod를 예약하는지 확인합니다.

    $ oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources

    출력 예

    Events:
      Type    Reason          Age    From                  Message
      ----    ------          ----   ----                  -------
      Normal  Scheduled       4m45s  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-6c4f5bdb84-wgn6g to worker-1

    참고

    예약에 사용할 수 있는 것보다 많은 리소스를 요청하는 배포는 MinimumReplicasUnavailable 오류와 함께 실패합니다. 필요한 리소스를 사용할 수 있게 되면 배포가 성공합니다. Pod는 필요한 리소스를 사용할 수 있을 때까지 Pending 상태로 유지됩니다.

  3. 예상되는 할당된 리소스가 노드에 대해 나열되어 있는지 확인합니다.

    1. 다음 명령을 실행하여 배포 Pod를 실행 중인 노드를 식별합니다.

      $ oc get pods -n openshift-numaresources -o wide

      출력 예

      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>

    2. 배포 Pod를 실행 중인 해당 노드의 이름으로 다음 명령을 실행합니다.

      $ oc describe noderesourcetopologies.topology.node.k8s.io worker-1

      출력 예

      ...
      
      Zones:
        Costs:
          Name:   node-0
          Value:  10
          Name:   node-1
          Value:  21
        Name:     node-0
        Resources:
          Allocatable:  39
          Available:    21 1
          Capacity:     40
          Name:         cpu
          Allocatable:  6442450944
          Available:    6442450944
          Capacity:     6442450944
          Name:         hugepages-1Gi
          Allocatable:  134217728
          Available:    134217728
          Capacity:     134217728
          Name:         hugepages-2Mi
          Allocatable:  262415904768
          Available:    262206189568
          Capacity:     270146007040
          Name:         memory
        Type:           Node

      1
      보장된 pod에 할당된 리소스 때문에 사용 가능한 용량이 줄어듭니다.

      보장된 Pod에서 사용하는 리소스는 noderesourcetopologies.topology.node.k8s.io 아래에 나열된 사용 가능한 노드 리소스에서 차감됩니다.

  4. Best-effort 또는 Burstable QoS(qosClass)가 있는 Pod의 리소스 할당은 noderesourcetopologies.topology.node.k8s.io 의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 사용한 리소스가 노드 리소스 계산에 반영되지 않은 경우 Pod에 Guaranteed 가 있고 CPU 요청이 10진수 값이 아닌 정수 값이 있는지 확인합니다. 다음 명령을 실행하여 Pod에 보장된 qosClass 가 있는지 확인할 수 있습니다.

    $ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"

    출력 예

    Guaranteed

9.4. 선택 사항: NUMA 리소스 업데이트를 위한 폴링 작업 구성

nodeGroup 의 NUMA Resources Operator에서 제어하는 데몬은 리소스를 폴링하여 사용 가능한 NUMA 리소스에 대한 업데이트를 검색합니다. NUMAResourcesOperator CR(사용자 정의 리소스)에서 spec.nodeGroups 사양을 구성하여 이러한 데몬에 대한 폴링 작업을 미세 조정할 수 있습니다. 이를 통해 폴링 작업에 대한 고급 제어가 제공됩니다. 스케줄링 동작을 개선하고 최적의 스케줄링 결정을 해결하기 위해 이러한 사양을 구성합니다.

구성 옵션은 다음과 같습니다.

  • infoRefreshMode: kubelet을 폴링하기 위한 트리거 조건을 결정합니다. NUMA Resources Operator는 결과 정보를 API 서버에 보고합니다.
  • infoRefreshPeriod: 폴링 업데이트 사이의 기간을 결정합니다.
  • podsFingerprinting: 노드에서 실행되는 현재 Pod 세트에 대한 지정 시간 정보가 폴링 업데이트에서 노출되는지 여부를 결정합니다.

    참고

    podsFingerprinting 은 기본적으로 활성화되어 있습니다. podsFingerprintingNUMAResourcesScheduler CR의 cacheResyncPeriod 사양에 대한 요구 사항입니다. cacheResyncPeriod 사양은 노드에서 보류 중인 리소스를 모니터링하여 보다 정확한 리소스 가용성을 보고하는 데 도움이 됩니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA Resources Operator를 설치합니다.

프로세스

  • NUMAResourcesOperator CR에서 spec.nodeGroups 사양을 구성합니다.

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesOperator
    metadata:
      name: numaresourcesoperator
    spec:
      nodeGroups:
      - config:
          infoRefreshMode: Periodic 1
          infoRefreshPeriod: 10s 2
          podsFingerprinting: Enabled 3
        name: worker
    1
    유효한 값은 Periodic,Events,periodicAndEvents 입니다. Periodic 을 사용하여 infoRefreshPeriod 에 정의된 간격으로 kubelet을 폴링합니다. 이벤트를 사용하여 모든 Pod 라이프사이클 이벤트에서 kubelet을 폴링합니다. PeriodicAndEvents 를 사용하여 두 가지 방법을 모두 활성화합니다.
    2
    Periodic 또는 PeriodicAndEvents 새로 고침 모드의 폴링 간격을 정의합니다. 새로 고침 모드가 Events 인 경우 필드가 무시됩니다.
    3
    유효한 값은 enabled,DisabledEnabledExclusiveResources. NUMAResourcesSchedulercacheResyncPeriod 사양에 대한 요구 사항입니다.

검증

  1. NUMA Resources Operator를 배포한 후 다음 명령을 실행하여 노드 그룹 구성이 적용되었는지 확인합니다.

    $ oc get numaresop numaresourcesoperator -o json | jq '.status'

    출력 예

          ...
    
            "config": {
            "infoRefreshMode": "Periodic",
            "infoRefreshPeriod": "10s",
            "podsFingerprinting": "Enabled"
          },
          "name": "worker"
    
          ...

9.5. NUMA 인식 스케줄링 문제 해결

NUMA 인식 Pod 예약의 일반적인 문제를 해결하려면 다음 단계를 수행합니다.

사전 요구 사항

  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

프로세스

  1. 다음 명령을 실행하여 noderesourcetopologies CRD가 클러스터에 배포되었는지 확인합니다.

    $ oc get crd | grep noderesourcetopologies

    출력 예

    NAME                                                              CREATED AT
    noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

  2. 다음 명령을 실행하여 NUMA 인식 스케줄러 이름이 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인합니다.

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'

    출력 예

    topo-aware-scheduler

  3. NUMA 인식 가능 노드에 noderesourcetopologies CR이 적용되는지 확인합니다. 다음 명령을 실행합니다.

    $ oc get noderesourcetopologies.topology.node.k8s.io

    출력 예

    NAME                    AGE
    compute-0.example.com   17h
    compute-1.example.com   17h

    참고

    노드 수는 머신 구성 풀(mcp) 작업자 정의로 구성된 작업자 노드 수와 같아야 합니다.

  4. 다음 명령을 실행하여 예약 가능한 모든 노드에 대한 NUMA 영역 단위를 확인합니다.

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: topology.node.k8s.io/v1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:38Z"
        generation: 63760
        name: worker-0
        resourceVersion: "8450223"
        uid: 8b77be46-08c0-4074-927b-d49361471590
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones:
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources:
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262352048128"
          available: "262352048128"
          capacity: "270107316224"
          name: memory
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269231067136"
          available: "269231067136"
          capacity: "270573244416"
          name: memory
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        type: Node
    - apiVersion: topology.node.k8s.io/v1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:37Z"
        generation: 62061
        name: worker-1
        resourceVersion: "8450129"
        uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones: 1
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources: 2
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262391033856"
          available: "262391033856"
          capacity: "270146301952"
          name: memory
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269192085504"
          available: "269192085504"
          capacity: "270534262784"
          name: memory
        type: Node
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""

    1
    zones 아래의 각 스탠자는 단일 NUMA 영역의 리소스를 설명합니다.
    2
    리소스는 NUMA 영역 리소스의 현재 상태를 설명합니다. items.zones.resources.available 아래에 나열된 리소스가 보장된 각 Pod에 할당된 전용 NUMA 영역 리소스에 해당하는지 확인합니다.

9.5.1. 보다 정확한 리소스 가용성 보고

cacheResyncPeriod 사양을 활성화하여 노드에서 보류 중인 리소스를 모니터링하고 이 정보를 정의된 간격으로 스케줄러 캐시에서 동기화하여 NUMA 리소스 가용성을 보다 정확하게 보고할 수 있습니다. 또한 최적의 스케줄링 결정으로 인해 토폴로지 선호도 오류 오류를 최소화하는 데 도움이 됩니다. 간격이 낮으면 네트워크가 더 많이 로드됩니다. cacheResyncPeriod 사양은 기본적으로 비활성화되어 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.

    1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다.

      $ oc get NUMAResourcesScheduler

      출력 예

      NAME                     AGE
      numaresourcesscheduler   92m

    2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. nro-scheduler-cacheresync.yaml 파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을 Debug 로 변경합니다.

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesScheduler
    metadata:
      name: numaresourcesscheduler
    spec:
      imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.14"
      cacheResyncPeriod: "5s" 1
    1
    스케줄러 캐시의 동기화를 위해 간격 값을 초 단위로 입력합니다. 값 5s 는 대부분의 구현에 일반적인 값입니다.
  3. 다음 명령을 실행하여 업데이트된 NUMAResourcesScheduler 리소스를 만듭니다.

    $ oc create -f nro-scheduler-cacheresync.yaml

    출력 예

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

  1. NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.

      $ oc get crd | grep numaresourcesschedulers

      출력 예

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      출력 예

      NAME                     AGE
      numaresourcesscheduler   3h26m

  2. 스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-numaresources

      출력 예

      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

    2. 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      출력 예

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

9.5.2. NUMA 인식 스케줄러 로그 확인

로그를 검토하여 NUMA 인식 스케줄러의 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler 리소스의 spec.logLevel 필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal,DebugTrace 이며 Trace 는 가장 자세한 옵션입니다.

참고

보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 다시 배포합니다. 이 다운타임 동안 새 워크로드를 예약할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.

    1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다.

      $ oc get NUMAResourcesScheduler

      출력 예

      NAME                     AGE
      numaresourcesscheduler   90m

    2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. nro-scheduler-debug.yaml 파일에 다음 YAML을 저장합니다. 이 예에서는 로그 수준을 Debug 로 변경합니다.

    apiVersion: nodetopology.openshift.io/v1
    kind: NUMAResourcesScheduler
    metadata:
      name: numaresourcesscheduler
    spec:
      imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.14"
      logLevel: Debug
  3. 다음 명령을 실행하여 업데이트된 Debug logging NUMAResourcesScheduler 리소스를 만듭니다.

    $ oc create -f nro-scheduler-debug.yaml

    출력 예

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

  1. NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.

      $ oc get crd | grep numaresourcesschedulers

      출력 예

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

    2. 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      출력 예

      NAME                     AGE
      numaresourcesscheduler   3h26m

  2. 스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-numaresources

      출력 예

      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

    2. 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      출력 예

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

9.5.3. 리소스 토폴로지 내보내기 문제 해결

해당 resource-topology-exporter 로그를 검사하여 예기치 않은 결과가 발생하는 noderesourcetopologies 오브젝트의 문제를 해결합니다.

참고

해당 노드에서 클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름을 지정하는 것이 좋습니다. 예를 들어, 이름이 worker인 작업자 노드에는 worker 라는 해당 noderesourcetopologies 오브젝트가 있어야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. NUMA Resources Operator에서 관리하는 데몬 세트를 가져옵니다. 각 daemonset에는 NUMAResourcesOperator CR에 해당 nodeGroup 이 있습니다. 다음 명령을 실행합니다.

    $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

    출력 예

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

  2. 이전 단계의 name 에 대한 값을 사용하여 관심 있는 데몬 세트의 레이블을 가져옵니다.

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

    출력 예

    {"name":"resource-topology"}

  3. 다음 명령을 실행하여 resource-topology 레이블을 사용하여 Pod를 가져옵니다.

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

    출력 예

    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

  4. 문제 해결 중인 노드에 해당하는 작업자 Pod에서 실행 중인 resource-topology-exporter 컨테이너의 로그를 검사합니다. 다음 명령을 실행합니다.

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

    출력 예

    I0221 13:38:18.334140       1 main.go:206] using sysinfo:
    reservedCpus: 0,1
    reservedMemory:
      "0": 1178599424
    I0221 13:38:18.334370       1 main.go:67] === System information ===
    I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
    I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
    I0221 13:38:18.546750       1 main.go:72]
    cpus: allocatable "2-103"
    hugepages-1Gi:
      numa cell 0 -> 6
      numa cell 1 -> 1
    hugepages-2Mi:
      numa cell 0 -> 64
      numa cell 1 -> 128
    memory:
      numa cell 0 -> 45758Mi
      numa cell 1 -> 48372Mi

9.5.4. 누락된 리소스 토폴로지 내보내기 구성 맵 수정

클러스터 설정이 잘못 구성된 클러스터에 NUMA Resources Operator를 설치하는 경우 Operator가 active로 표시되지만 RTE(Resource topology exporter) 데몬 세트 Pod의 로그에 RTE의 구성이 누락되어 있음을 보여줍니다.

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

이 로그 메시지는 필요한 구성이 있는 kubeletconfig 가 클러스터에 제대로 적용되지 않아 RTE configmap 이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에 numaresourcesoperator-worker configmap CR (사용자 정의 리소스)이 없습니다.

$ 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

올바르게 구성된 클러스터에서 oc get configmapnumaresourcesoperator-worker configmap CR을 반환합니다.

사전 요구 사항

  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

프로세스

  1. 다음 명령을 사용하여 MachineConfigPool (mcp) 작업자 CR의 spec.machineConfigPoolSelector.matchLabels 값과 kubeletconfigmetadata.labels 의 값을 비교합니다.

    1. 다음 명령을 실행하여 kubeletconfig 레이블을 확인합니다.

      $ oc get kubeletconfig -o yaml

      출력 예

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled

    2. 다음 명령을 실행하여 mcp 레이블을 확인합니다.

      $ oc get mcp worker -o yaml

      출력 예

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled 레이블은 MachineConfigPool 오브젝트에 없습니다.

  2. 누락된 라벨을 포함하도록 MachineConfigPool CR을 편집합니다. 예를 들면 다음과 같습니다.

    $ oc edit mcp worker -o yaml

    출력 예

    labels:
      machineconfiguration.openshift.io/mco-built-in: ""
      pools.operator.machineconfiguration.openshift.io/worker: ""
      cnf-worker-tuning: enabled

  3. 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.

검증

  • 누락된 numaresourcesoperator-worker configmap CR이 적용되었는지 확인합니다.

    $ oc get configmap

    출력 예

    NAME                           DATA   AGE
    0e2a6bd3.openshift-kni.io      0      6d21h
    kube-root-ca.crt               1      6d21h
    numaresourcesoperator-worker   1      5m
    openshift-service-ca.crt       1      6d21h
    topo-aware-scheduler-config    1      6d18h

9.5.5. NUMA Resources Operator 데이터 수집

oc adm must-gather CLI 명령을 사용하여 NUMA Resources Operator와 관련된 기능 및 오브젝트를 포함하여 클러스터에 대한 정보를 수집할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  • must-gather 를 사용하여 NUMA Resources Operator 데이터를 수집하려면 NUMA Resources Operator must-gather 이미지를 지정해야 합니다.

    $ oc adm must-gather --image=registry.redhat.io/numaresources-must-gather/numaresources-must-gather-rhel9:v4.14

10장. 확장성 및 성능 최적화

10.1. 스토리지 최적화

스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.

10.1.1. 사용 가능한 영구 스토리지 옵션

OpenShift Container Platform 환경을 최적화할 수 있도록 영구 스토리지 옵션에 대해 알아보십시오.

표 10.1. 사용 가능한 스토리지 옵션
스토리지 유형설명

블록

  • 운영 체제(OS)에 블록 장치로 제공됩니다.
  • 스토리지에 대한 모든 권한이 필요하며 파일 시스템을 우회하여 파일의 낮은 수준에서 작동하는 애플리케이션에 적합합니다.
  • SAN(Storage Area Network)이라고도 합니다.
  • 공유가 불가능합니다. 즉, 한 번에 하나의 클라이언트만 이 유형의 끝점을 마운트할 수 있습니다.

AWS EBS 및 VMware vSphere는 OpenShift Container Platform에서 기본적으로 동적 PV(영구 볼륨) 프로비저닝을 지원합니다.

파일

  • OS에 마운트할 파일 시스템 내보내기로 제공됩니다.
  • NAS(Network Attached Storage)라고도 합니다.
  • 동시성, 대기 시간, 파일 잠금 메커니즘 및 기타 기능은 프로토콜, 구현, 벤더 및 스케일링에 따라 크게 다릅니다.

RHEL NFS, NetApp NFS [1] 및 Vendor NFS

개체

  • REST API 끝점을 통해 액세스할 수 있습니다.
  • OpenShift 이미지 레지스트리에서 사용할 구성 가능
  • 애플리케이션에서 해당 드라이버를 애플리케이션 및/또는 컨테이너에 빌드해야 합니다.

AWS S3

  1. NetApp NFS는 Trident 플러그인을 사용할 때 동적 PV 프로비저닝을 지원합니다.

10.1.3. 데이터 스토리지 관리

다음 표에는 OpenShift Container Platform 구성 요소가 데이터를 쓰는 기본 디렉터리가 요약되어 있습니다.

표 10.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가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다.

10.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 스토리지에 있는 디스크에서 읽기보다 훨씬 빠릅니다.

10.1.5. 추가 리소스

10.2. 라우팅 최적화

OpenShift Container Platform HAProxy 라우터는 성능을 최적화하도록 스케일링하거나 구성할 수 있습니다.

10.2.1. 기본 Ingress 컨트롤러(라우터) 성능

OpenShift Container Platform Ingress 컨트롤러 또는 라우터는 경로 및 인그레스를 사용하여 구성된 애플리케이션 및 서비스의 수신 트래픽의 수신 지점입니다.

초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.

  • HTTP 연결 유지/닫기 모드
  • 경로 유형
  • TLS 세션 재개 클라이언트 지원
  • 대상 경로당 동시 연결 수
  • 대상 경로 수
  • 백엔드 서버 페이지 크기
  • 기본 인프라(네트워크/SDN 솔루션, CPU 등)

특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.

HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

기본 Ingress 컨트롤러 구성은 spec.tuningOptions.threadCount 필드와 함께 4 로 설정되었습니다. 로드 밸런서 서비스와 호스트 네트워크라는 두 가지 끝점 게시 전략이 테스트되었습니다. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP 연결 유지를 사용하면 단일 HAProxy 라우터가 8kB의 작은 페이지 크기에서 1Gbit NIC를 포화할 수 있습니다.

최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.

애플리케이션 수애플리케이션 유형

5-10

정적 파일/웹 서버 또는 캐싱 프록시

100-1000

동적 콘텐츠를 생성하는 애플리케이션

일반적으로 HAProxy는 사용 중인 기술에 따라 최대 1000개의 애플리케이션에 대한 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.

Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.

Ingress 샤딩에 대한 자세한 내용은 경로 라벨을 사용하여 Ingress 컨트롤러 분할 구성 및 네임스페이스 라벨 을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하십시오.

시간 초과에 대한 스레드 및 Ingress 컨트롤러 구성 매개변수 설정에 제공된 정보를 사용하여 Ingress 컨트롤러 배포 및 Ingress 컨트롤러 사양의 기타 튜닝 구성 을 사용하여 Ingress 컨트롤러 배포를 수정할 수 있습니다.

10.2.2. Ingress 컨트롤러 활성, 준비 상태 및 시작 프로브 구성

클러스터 관리자는 OpenShift Container Platform Ingress 컨트롤러(라우터)에서 관리하는 라우터 배포를 위해 kubelet의 활성 상태, 준비 상태 및 시작 프로브에 대한 시간 초과 값을 구성할 수 있습니다. 라우터의 활성 상태 및 준비 상태 프로브는 기본 시간 제한 값 1초를 사용합니다. 이 값은 네트워킹 또는 런타임 성능이 심각하게 저하될 때 너무 짧습니다. 프로브 시간 초과로 인해 애플리케이션 연결을 중단하는 원치 않는 라우터가 다시 시작될 수 있습니다. 더 큰 시간 초과 값을 설정하는 기능은 불필요하고 원하지 않는 재시작 위험을 줄일 수 있습니다.

router 컨테이너의 livenessProbe,readinessProbestartupProbe 매개변수에서 timeoutSeconds 값을 업데이트할 수 있습니다.

매개변수설명

livenessProbe

livenessProbe 는 Pod가 종료되었는지 여부를 kubelet에 보고합니다.

readinessProbe

readinessProbe 는 Pod가 정상인지 또는 비정상적인지 여부를 보고합니다. 준비 상태 프로브에서 비정상 Pod를 보고할 때 kubelet은 Pod를 트래픽을 수락할 준비가 되지 않은 것으로 표시합니다. 결과적으로 해당 Pod의 끝점이 준비되지 않은 것으로 표시되고 이 상태는 kube-proxy로 전파됩니다. 로드 밸런서가 구성된 클라우드 플랫폼에서 kube-proxy는 클라우드 로드 밸런서와 통신하여 해당 Pod를 사용하여 노드에 트래픽을 보내지 않습니다.

startupProbe

startupProbe 는 kubelet이 라우터 활성 및 준비 상태 프로브 전송을 시작하기 전에 최대 2분 동안 초기화할 수 있도록 라우터 Pod를 제공합니다. 이 초기화 시간은 많은 경로 또는 끝점이 있는 라우터가 조기 재시작되지 않도록 할 수 있습니다.

중요

시간 제한 구성 옵션은 문제를 해결하는 데 사용할 수 있는 고급 튜닝 기술입니다. 그러나 이러한 문제는 결국 진단되고 프로브가 시간 초과되는 문제에 대해 지원 케이스 또는 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 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

10.2.3. HAProxy 재로드 간격 구성

경로와 연결된 경로 또는 끝점을 업데이트하면 OpenShift Container Platform 라우터에서 HAProxy 구성을 업데이트합니다. 그런 다음 HAProxy는 이러한 변경 사항을 적용하기 위해 업데이트된 구성을 다시 로드합니다. HAProxy가 다시 로드되면 업데이트된 구성을 사용하여 새 연결을 처리하는 새 프로세스가 생성됩니다.

HAProxy는 이러한 연결이 모두 종료될 때까지 기존 프로세스를 계속 실행하여 기존 연결을 처리합니다. 이전 프로세스에 수명이 긴 연결이 있는 경우 이러한 프로세스는 리소스를 누적하고 사용할 수 있습니다.

기본 최소 HAProxy 재로드 간격은 5초입니다. spec.tuningOptions.reloadInterval 필드를 사용하여 Ingress 컨트롤러를 구성하여 최소 다시 로드 간격을 더 오래 설정할 수 있습니다.

주의

최소 HAProxy 재로드 간격에 대해 큰 값을 설정하면 경로 및 엔드포인트에 대한 업데이트를 관찰하는 대기 시간이 발생할 수 있습니다. 위험을 줄이려면 업데이트에 허용되는 대기 시간보다 큰 값을 설정하지 마십시오. HAProxy 재로드 간격의 최대값은 120초입니다.

프로세스

  • 다음 명령을 실행하여 기본 Ingress 컨트롤러의 최소 HAProxy 재로드 간격을 15초로 변경합니다.

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'

10.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 사용량이 감소합니다.

10.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(전송 제어 프로토콜)에서 처리량에 도움이 됩니다.

OVN 및 Geneve의 경우 MTU는 NIC MTU보다 최소 100바이트 작아야 합니다.

참고

이 50바이트 오버레이 헤더는 OpenShift SDN 네트워크 플러그인과 관련이 있습니다. 기타 SDN 솔루션에서는 이 값이 더 크거나 작아야 할 수 있습니다.

10.3.3. IPsec 영향

노드 호스트의 암호화 및 암호 해독은 CPU를 사용하기 때문에 사용 중인 IP 보안 시스템에 관계없이 암호화를 사용할 때 노드의 처리량과 CPU 사용량 모두에서 성능에 영향을 미칩니다.

IPsec은 NIC에 도달하기 전에 IP 페이로드 수준에서 트래픽을 암호화하여 NIC 오프로드에 사용되는 필드를 보호합니다. 즉, IPSec가 활성화되면 일부 NIC 가속 기능을 사용할 수 없으며 처리량이 감소하고 CPU 사용량이 증가합니다.

10.3.4. 추가 리소스

10.4. 마운트 네임스페이스 캡슐화를 사용하여 CPU 사용량 최적화

마운트 네임스페이스 캡슐화를 사용하여 kubelet 및 CRI-O 프로세스의 프라이빗 네임스페이스를 제공하여 OpenShift Container Platform 클러스터에서 CPU 사용량을 최적화할 수 있습니다. 이렇게 하면 기능 차이가 없이 systemd에서 사용하는 클러스터 CPU 리소스가 줄어듭니다.

중요

마운트 네임스페이스 캡슐화는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

10.4.1. 마운트 네임스페이스 캡슐화

마운트 네임스페이스는 다른 네임스페이스의 프로세스에서 서로의 파일을 볼 수 없도록 마운트 지점을 분리하는 데 사용됩니다. 캡슐화는 Kubernetes 마운트 네임스페이스를 호스트 운영 체제에서 지속적으로 검사하지 않는 대체 위치로 이동하는 프로세스입니다.

호스트 운영 체제는 systemd를 사용하여 모든 마운트 네임스페이스를 지속적으로 검사합니다. 표준 Linux 마운트와 Kubernetes가 작동하는 데 사용하는 수많은 마운트 모두입니다. kubelet 및 CRI-O의 현재 구현은 모든 컨테이너 런타임 및 kubelet 마운트 지점에 최상위 네임스페이스를 사용합니다. 그러나 프라이빗 네임스페이스에서 이러한 컨테이너별 마운트 지점을 캡슐화하면 기능 차이가 없이 systemd 오버헤드가 줄어듭니다. CRI-O 및 kubelet 모두에 별도의 마운트 네임스페이스를 사용하면 systemd 또는 기타 호스트 운영 체제 상호 작용의 컨테이너별 마운트를 캡슐화할 수 있습니다.

이제 모든 OpenShift Container Platform 관리자가 주요 CPU 최적화를 수행할 수 있는 이 기능을 사용할 수 있습니다. Encapsulation은 권한이 없는 사용자가 검사한 위치에서 Kubernetes별 마운트 지점을 저장하여 보안을 개선할 수도 있습니다.

다음 다이어그램은 캡슐화 전후의 Kubernetes 설치를 보여줍니다. 두 시나리오 모두 양방향, host-to-container 및 none의 마운트 전파 설정이 있는 예제 컨테이너를 표시합니다.

캡슐화 전

여기에서는 단일 마운트 네임스페이스를 공유하는 systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임을 참조하십시오.

  • systemd, 호스트 운영 체제 프로세스, kubelet 및 컨테이너 런타임은 각각 모든 마운트 지점에 대한 액세스 및 가시성을 갖습니다.
  • 양방향 마운트 전파로 구성된 컨테이너 1은 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다. /run/a 와 같은 컨테이너 1에 있는 마운트는 systemd, 호스트 운영 체제 프로세스, kubelet, 컨테이너 런타임 및 호스트-컨테이너 또는 양방향 마운트 전파가 구성된 기타 컨테이너에 표시됩니다(컨테이너 2에서와 같이).
  • 컨테이너 2는 host-to-container 마운트 전파로 구성되며 systemd 및 호스트 마운트, kubelet 및 CRI-O 마운트에 액세스할 수 있습니다. /run/b 와 같은 컨테이너 2에서 시작된 마운트는 다른 컨텍스트에 표시되지 않습니다.
  • 마운트 전파 없이 구성된 컨테이너 3은 외부 마운트 지점을 확인할 수 없습니다. /run/c 와 같은 컨테이너 3에서 시작되는 마운트는 다른 컨텍스트에 표시되지 않습니다.

다음 다이어그램은 캡슐화 후 시스템 상태를 보여줍니다.

캡슐화 후
  • 기본 systemd 프로세스는 더 이상 Kubernetes별 마운트 지점의 불필요한 검색에 영향을 미치지 않습니다. systemd 관련 및 호스트 마운트 지점만 모니터링합니다.
  • 호스트 운영 체제 프로세스는 systemd 및 호스트 마운트 지점에만 액세스할 수 있습니다.
  • CRI-O 및 kubelet 모두에 별도의 마운트 네임스페이스를 사용하면 모든 컨테이너별 마운트를 systemd 또는 기타 호스트 운영 체제 상호 작용과 완전히 분리합니다.
  • /run/a 와 같이 생성되는 마운트는 더 이상 systemd 또는 호스트 운영 체제 프로세스에 표시되지 않는 경우를 제외하고 컨테이너 1의 동작은 변경되지 않습니다. kubelet, CRI-O 및 host-to-container 또는 양방향 마운트 전파가 구성된 기타 컨테이너(예: 컨테이너 2)에 계속 표시됩니다.
  • 컨테이너 2 및 컨테이너 3의 동작은 변경되지 않습니다.

10.4.2. 마운트 네임스페이스 캡슐화 구성

클러스터가 리소스 오버헤드로 실행되도록 마운트 네임스페이스 캡슐화를 구성할 수 있습니다.

참고

마운트 네임스페이스 캡슐화는 기술 프리뷰 기능이며 기본적으로 비활성화되어 있습니다. 이 기능을 사용하려면 수동으로 기능을 활성화해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 다음 YAML을 사용하여 mount_namespace_config.yaml 이라는 파일을 생성합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 99-kubens-master
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: kubens.service
    ---
    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: worker
      name: 99-kubens-worker
    spec:
      config:
        ignition:
          version: 3.2.0
        systemd:
          units:
          - enabled: true
            name: kubens.service
  2. 다음 명령을 실행하여 마운트 네임스페이스 MachineConfig CR을 적용합니다.

    $ oc apply -f mount_namespace_config.yaml

    출력 예

    machineconfig.machineconfiguration.openshift.io/99-kubens-master created
    machineconfig.machineconfiguration.openshift.io/99-kubens-worker created

  3. MachineConfig CR은 클러스터에 적용되는 데 최대 30분이 걸릴 수 있습니다. 다음 명령을 실행하여 MachineConfig CR의 상태를 확인할 수 있습니다.

    $ oc get mcp

    출력 예

    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

  4. 다음 명령을 실행한 후 MachineConfig CR이 모든 컨트롤 플레인 및 작업자 노드에 성공적으로 적용될 때까지 기다립니다.

    $ oc wait --for=condition=Updated mcp --all --timeout=30m

    출력 예

    machineconfigpool.machineconfiguration.openshift.io/master condition met
    machineconfigpool.machineconfiguration.openshift.io/worker condition met

검증

클러스터 호스트의 캡슐화를 확인하려면 다음 명령을 실행합니다.

  1. 클러스터 호스트에 대한 디버그 쉘을 엽니다.

    $ oc debug node/<node_name>
  2. chroot 세션을 엽니다.

    sh-4.4# chroot /host
  3. systemd 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/1/ns/mnt

    출력 예

    mnt:[4026531953]

  4. kubelet 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt

    출력 예

    mnt:[4026531840]

  5. CRI-O 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt

    출력 예

    mnt:[4026531840]

이러한 명령은 systemd, kubelet 및 컨테이너 런타임과 관련된 마운트 네임스페이스를 반환합니다. OpenShift Container Platform에서 컨테이너 런타임은 CRI-O입니다.

위 예제와 같이 systemd가 kubelet 및 CRI-O에 다른 마운트 네임스페이스에 있는 경우 Encapsulation이 적용됩니다. 3개의 프로세스가 모두 동일한 마운트 네임스페이스에 있는 경우 캡슐화는 적용되지 않습니다.

10.4.3. 캡슐화된 네임스페이스 검사

RHCOS(Red Hat Enterprise Linux CoreOS)에서 사용할 수 있는 kubensenter 스크립트를 사용하여 디버깅 또는 감사 목적으로 클러스터 호스트 운영 체제의 Kubernetes별 마운트 지점을 검사할 수 있습니다.

클러스터 호스트에 대한 SSH 쉘 세션은 기본 네임스페이스에 있습니다. SSH 쉘 프롬프트에서 Kubernetes별 마운트 지점을 검사하려면 kubensenter 스크립트를 root로 실행해야 합니다. kubensenter 스크립트는 마운트 캡슐화 상태를 알고 있으며 캡슐화가 활성화되지 않은 경우에도 실행하는 것이 안전합니다.

참고

oc debug 원격 쉘 세션은 기본적으로 Kubernetes 네임스페이스 내에서 시작됩니다. oc debug 를 사용할 때 마운트 지점을 검사하기 위해 kubensenter 를 실행할 필요가 없습니다.

캡슐화 기능이 활성화되지 않은 경우 kubensenter findmntfindmnt 명령은 oc debug 세션 또는 SSH 쉘 프롬프트에서 실행되는지 여부에 관계없이 동일한 출력을 반환합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 클러스터 호스트에 대한 SSH 액세스를 구성했습니다.

프로세스

  1. 클러스터 호스트에 대한 원격 SSH 쉘을 엽니다. 예를 들면 다음과 같습니다.

    $ ssh core@<node_name>
  2. 제공된 kubensenter 스크립트를 root 사용자로 사용하여 명령을 실행합니다. Kubernetes 네임스페이스 내에서 단일 명령을 실행하려면 명령과 kubensenter 스크립트에 인수를 제공합니다. 예를 들어 Kubernetes 네임스페이스 내에서 findmnt 명령을 실행하려면 다음 명령을 실행합니다.

    [core@control-plane-1 ~]$ sudo kubensenter findmnt

    출력 예

    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
    TARGET                                SOURCE                 FSTYPE     OPTIONS
    /                                     /dev/sda4[/ostree/deploy/rhcos/deploy/32074f0e8e5ec453e56f5a8a7bc9347eaa4172349ceab9c22b709d9d71a3f4b0.0]
    |                                                            xfs        rw,relatime,seclabel,attr2,inode64,logbufs=8,logbsize=32k,prjquota
                                          shm                    tmpfs
    ...

  3. Kubernetes 네임스페이스 내에서 새 대화형 쉘을 시작하려면 인수 없이 kubensenter 스크립트를 실행합니다.

    [core@control-plane-1 ~]$ sudo kubensenter

    출력 예

    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt

10.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

10.4.5. 추가 리소스

11장. 베어 메탈 호스트 관리

베어 메탈 클러스터에 OpenShift Container Platform을 설치할 때 클러스터에 있는 베어 메탈 호스트에 대한 machinemachineset CR(사용자 정의 리소스)을 사용하여 베어 메탈 노드를 프로비저닝하고 관리할 수 있습니다.

11.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에 지정된 대로 호스트에 해당하는 베어 메탈 노드를 프로비저닝합니다.

11.2. 베어 메탈 호스트 유지관리

OpenShift Container Platform 웹 콘솔에서 클러스터의 베어 메탈 호스트의 세부 정보를 유지 관리할 수 있습니다. 컴퓨팅베어 메탈 호스트로 이동하여 작업 드롭다운 메뉴에서 작업을 선택합니다. 여기에서 BMC 세부 정보, 호스트의 MAC 주소 부팅, 전원 관리 활성화 등의 항목을 관리할 수 있습니다. 네트워크 인터페이스의 세부 정보와 호스트에 대한 드라이브도 검토할 수 있습니다.

베어 메탈 호스트를 유지 관리 모드로 이동할 수 있습니다. 호스트를 유지 관리 모드로 이동할 때 스케줄러는 모든 관리 워크로드를 해당 베어 메탈 노드에서 이동합니다. 유지 관리 모드에서는 새 워크로드가 예약되지 않습니다.

웹 콘솔에서 베어 메탈 호스트를 프로비저닝 해제할 수 있습니다. 호스트 프로비저닝 해제는 다음 작업을 수행합니다.

  1. cluster.k8s.io/delete-machine: true를 사용하여 베어 메탈 호스트 CR에 주석을 답니다.
  2. 관련 컴퓨팅 머신 세트를 축소
참고

먼저 데몬 세트와 관리되지 않는 정적 Pod를 다른 노드로 이동하지 않고 호스트의 전원을 끄면 서비스가 중단되고 데이터가 손실될 수 있습니다.

11.2.1. 웹 콘솔을 사용하여 클러스터에 베어 메탈 호스트 추가

웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.

사전 요구 사항

  • 베어 메탈에 RHCOS 클러스터 설치
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 웹 콘솔에서 ComputeBare Metal Hosts로 이동합니다.
  2. Add HostNew with Dialog를 선택합니다.
  3. 새 베어 메탈 호스트의 고유 이름을 지정합니다.
  4. Boot MAC address를 설정합니다.
  5. Baseboard Management Console (BMC) Address를 설정합니다.
  6. 호스트의 BMC(Baseboard Management Controller)에 대한 사용자 인증 정보를 입력합니다.
  7. 생성 후 호스트 전원을 켜도록선택하고 Create를 선택합니다.
  8. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. ComputeMachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count을 선택하여 클러스터에서 머신 복제본 수를 늘립니다.
참고

oc scale 명령 및 적절한 베어 메탈 컴퓨팅 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

11.2.2. 웹 콘솔에서 YAML을 사용하여 클러스터에 베어 메탈 호스트 추가

베어 메탈 호스트를 설명하는 YAML 파일을 사용하여 웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.

사전 요구 사항

  • 클러스터에 사용할 RHCOS 컴퓨팅 머신을 베어메탈 인프라에 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 베어 메탈 호스트의 Secret CR을 생성합니다.

프로세스

  1. 웹 콘솔에서 ComputeBare Metal Hosts로 이동합니다.
  2. Add HostNew from YAML을 선택합니다.
  3. 아래 YAML을 복사하고 붙여넣고 호스트의 세부 정보로 관련 필드를 수정합니다.

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: <bare_metal_host_name>
    spec:
      online: true
      bmc:
        address: <bmc_address>
        credentialsName: <secret_credentials_name>  1
        disableCertificateVerification: True 2
      bootMACAddress: <host_boot_mac_address>
    1
    credentialsName은 유효한 Secret CR을 참조해야 합니다. baremetal-operatorcredentialsName에서 참조되는 유효한 Secret 없이 베어 메탈 호스트를 관리할 수 없습니다. 시크릿 및 시크릿 생성 방법에 대한 자세한 내용은 시크릿 이해 를 참조하십시오.
    2
    disableCertificateVerificationtrue 로 설정하면 클러스터와 BMC(Baseboard Management Controller) 간의 TLS 호스트 유효성 검사가 비활성화됩니다.
  4. Create를 선택하여 YAML을 저장하고 새 베어 메탈 호스트를 생성합니다.
  5. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. ComputeMachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count를 선택하여 클러스터의 머신 수를 늘립니다.

    참고

    oc scale 명령 및 적절한 베어 메탈 컴퓨팅 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

11.2.3. 사용 가능한 베어 메탈 호스트 수로 머신 자동 스케일링

사용 가능한 BareMetalHost 오브젝트 수와 일치하는 Machine 오브젝트 수를 자동으로 생성하려면 MachineSet 오브젝트에 metal3.io/autoscale-to-hosts 주석을 추가합니다.

사전 요구 사항

  • 클러스터에서 사용할 RHCOS 베어 메탈 컴퓨팅 머신을 설치하고 해당 BareMetalHost 오브젝트를 생성합니다.
  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. metal3.io/autoscale-to-hosts 주석을 추가하여 자동 스케일링을 구성할 컴퓨팅 머신 세트에 주석을 답니다. & lt;machineset >를 컴퓨팅 머신 세트의 이름으로 바꿉니다.

    $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'

    새로 확장된 머신이 시작될 때까지 기다립니다.

참고

BareMetalHost 오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가 BareMetalHost에서 변경되면 Machine 오브젝트가 생성된 MachineSet에 대해 BareMetalHost 오브젝트가 계속 계산됩니다.

11.2.4. 프로비저너 노드에서 베어 메탈 호스트 제거

특정 상황에서는 프로비저너 노드에서 베어 메탈 호스트를 일시적으로 제거해야 할 수 있습니다. 예를 들어 OpenShift Container Platform 관리 콘솔을 사용하거나 Machine Config Pool 업데이트로 베어 메탈 호스트 재부팅이 트리거되는 경우 OpenShift Container Platform은 통합된 iDrac(Remote Access Controller)에 로그인하여 작업 대기열 삭제를 발행합니다.

사용 가능한 BareMetalHost 오브젝트 수와 일치하는 Machine 오브젝트 수를 관리하지 않으려면 MachineSet 오브젝트에 baremetalhost.metal3.io/detached 주석을 추가합니다.

참고

이 주석은 Provisioned,ExternallyProvisioned 또는 Ready/Available 상태에 있는 BareMetalHost 오브젝트에만 적용됩니다.

사전 요구 사항

  • 클러스터에서 사용할 RHCOS 베어 메탈 컴퓨팅 머신을 설치하고 해당 BareMetalHost 오브젝트를 생성합니다.
  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. baremetalhost.metal3.io/detached 주석을 추가하여 프로비저너 노드에서 제거할 컴퓨팅 머신 세트에 주석을 답니다.

    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'

    새 머신이 시작될 때까지 기다립니다.

    참고

    BareMetalHost 오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가 BareMetalHost에서 변경되면 Machine 오브젝트가 생성된 MachineSet에 대해 BareMetalHost 오브젝트가 계속 계산됩니다.

  2. 프로비저닝 사용 사례에서 다음 명령을 사용하여 재부팅이 완료된 후 주석을 제거합니다.

    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'

12장. 베어 메탈 이벤트 릴레이를 사용하여 베어 메탈 이벤트 모니터링

중요

Bare Metal Event Relay는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

12.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 가능 장치에서만 작동합니다.

12.2. 베어 메탈 이벤트 작동 방식

Bare Metal Event Relay를 사용하면 베어 메탈 클러스터에서 실행되는 애플리케이션이 Redfish 하드웨어 변경 및 온도 임계값 위반, 디스크 손실, 정전 및 메모리 실패와 같은 Redfish 하드웨어 변경 및 장애에 빠르게 대응할 수 있습니다. 이러한 하드웨어 이벤트는 HTTP 전송 또는 AMQP 메커니즘을 사용하여 전달됩니다. 메시징 서비스의 대기 시간은 10~20밀리초입니다.

베어 메탈 이벤트 릴레이는 하드웨어 이벤트에 대한 게시-서브스크립션 서비스를 제공합니다. 애플리케이션은 REST API를 사용하여 이벤트를 구독할 수 있습니다. 베어 메탈 이벤트 릴레이는 Redfish OpenAPI v1.8 이상을 준수하는 하드웨어를 지원합니다.

12.2.1. 베어 메탈 이벤트 릴레이 데이터 흐름

다음 그림은 베어 메탈 이벤트 데이터 흐름의 예를 보여줍니다.

그림 12.1. 베어 메탈 이벤트 릴레이 데이터 흐름

베어 메탈 이벤트 데이터 흐름
12.2.1.1. Operator에서 관리하는 Pod

Operator는 사용자 정의 리소스를 사용하여 HardwareEvent CR을 사용하여 Bare Metal Event Relay 및 해당 구성 요소가 포함된 Pod를 관리합니다.

12.2.1.2. Bare Metal Event Relay

시작 시 베어 메탈 이벤트 릴레이는 Redfish API를 쿼리하고 사용자 지정 레지스트리를 포함한 모든 메시지 레지스트리를 다운로드합니다. 그런 다음 Bare Metal Event Relay가 Redfish 하드웨어에서 서브스크립션 이벤트를 수신하기 시작합니다.

Bare Metal Event Relay를 사용하면 베어 메탈 클러스터에서 실행되는 애플리케이션이 Redfish 하드웨어 변경 및 온도 임계값 위반, 디스크 손실, 정전 및 메모리 실패와 같은 Redfish 하드웨어 변경 및 장애에 빠르게 대응할 수 있습니다. 이벤트는 HardwareEvent CR을 사용하여 보고합니다.

12.2.1.3. 클라우드 네이티브 이벤트

CCNE(클라우드 네이티브 이벤트)는 이벤트 데이터 형식을 정의하기 위한 REST API 사양입니다.

12.2.1.4. CNCF CloudEvents

CloudEvents 는 이벤트 데이터 형식을 정의하기 위해 CCNCF(Cloud Native Computing Foundation)에서 개발한 벤더 중립 사양입니다.

12.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 지원 상태를 참조하십시오.

12.2.1.6. 클라우드 이벤트 프록시 사이드카

클라우드 이벤트 프록시 사이드카 컨테이너 이미지는 O-RAN API 사양을 기반으로 하며 하드웨어 이벤트에 대한 게시-구독 이벤트 프레임워크를 제공합니다.

12.2.2. Redfish 메시지 구문 분석 서비스

Redfish 이벤트를 처리하는 것 외에도 Bare Metal Event Relay는 Message 속성 없이 이벤트에 대한 메시지 구문 분석 기능을 제공합니다. 프록시는 시작될 때 하드웨어에서 벤더별 레지스트리를 포함하여 모든 Redfish 메시지 레지스트리를 다운로드합니다. 이벤트에 Message 속성이 포함되어 있지 않은 경우 프록시는 Redfish 메시지 레지스트리를 사용하여 MessageResolution 속성을 구성하고 이벤트를 클라우드 이벤트 프레임워크에 전달하기 전에 이벤트에 추가합니다. 이 서비스를 사용하면 Redfish 이벤트의 메시지 크기와 전송 대기 시간이 단축될 수 있습니다.

12.2.3. CLI를 사용하여 베어 메탈 이벤트 릴레이 설치

클러스터 관리자는 CLI를 사용하여 Bare Metal Event Relay Operator를 설치할 수 있습니다.

사전 요구 사항

  • BMC(RedFish-enabled Baseboard Management Controller)가 있는 노드를 사용하여 베어 메탈 하드웨어에 설치된 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 베어 메탈 이벤트 릴레이의 네임스페이스를 생성합니다.

    1. 다음 YAML을 베어 메탈-events-namespace.yaml 파일에 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-bare-metal-events
        labels:
          name: openshift-bare-metal-events
          openshift.io/cluster-monitoring: "true"
    2. Namespace CR을 생성합니다.

      $ oc create -f bare-metal-events-namespace.yaml
  2. Bare Metal Event Relay Operator에 대한 Operator 그룹을 생성합니다.

    1. 다음 YAML을 bare-metal-events-operatorgroup.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: bare-metal-event-relay-group
        namespace: openshift-bare-metal-events
      spec:
        targetNamespaces:
        - openshift-bare-metal-events
    2. OperatorGroup CR을 생성합니다.

      $ oc create -f bare-metal-events-operatorgroup.yaml
  3. 베어 메탈 이벤트 릴레이를 구독합니다.

    1. 다음 YAML을 bare-metal-events-sub.yaml 파일에 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: bare-metal-event-relay-subscription
        namespace: openshift-bare-metal-events
      spec:
        channel: "stable"
        name: bare-metal-event-relay
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. Subscription CR을 생성합니다.

      $ oc create -f bare-metal-events-sub.yaml

검증

Bare Metal Event Relay Operator가 설치되었는지 확인하려면 다음 명령을 실행합니다.

$ oc get csv -n openshift-bare-metal-events -o custom-columns=Name:.metadata.name,Phase:.status.phase

12.2.4. 웹 콘솔을 사용하여 베어 메탈 이벤트 릴레이 설치

클러스터 관리자는 웹 콘솔을 사용하여 Bare Metal Event Relay Operator를 설치할 수 있습니다.

사전 요구 사항

  • BMC(RedFish-enabled Baseboard Management Controller)가 있는 노드를 사용하여 베어 메탈 하드웨어에 설치된 클러스터입니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔을 사용하여 Bare Metal Event Relay를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 Bare Metal Event Relay 를 선택한 다음 설치를 클릭합니다.
    3. Operator 설치 페이지에서 네임스페이스 를 선택하거나 생성한 후 openshift-bare-metal-events 를 선택한 다음 설치를 클릭합니다.

검증

선택 사항: 다음 검사를 수행하여 Operator가 성공적으로 설치되었는지 확인할 수 있습니다.

  1. Operator설치된 Operator 페이지로 전환합니다.
  2. InstallSucceeded 상태로 프로젝트에 Bare Metal Event Relay 가 나열되어 있는지 확인합니다.

    참고

    설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제 해결을 수행합니다.

  • Operator설치된 Operator 페이지로 이동하고 Operator 서브스크립션설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
  • 워크로드Pod 페이지로 이동하여 프로젝트 네임스페이스에서 Pod 로그를 확인합니다.

12.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 권한이 있는 사용자로 로그인합니다.

프로세스

검증

  1. AMQ Interconnect Operator를 사용할 수 있고 필요한 Pod가 실행 중인지 확인합니다.

    $ oc get pods -n amq-interconnect

    출력 예

    NAME                                    READY   STATUS    RESTARTS   AGE
    amq-interconnect-645db76c76-k8ghs       1/1     Running   0          23h
    interconnect-operator-5cb5fc7cc-4v7qm   1/1     Running   0          23h

  2. 필요한 bare-metal-event-relay 베어 메탈 이벤트 생산자 Pod가 openshift-bare-metal-events 네임스페이스에서 실행 중인지 확인합니다.

    $ oc get pods -n openshift-bare-metal-events

    출력 예

    NAME                                                            READY   STATUS    RESTARTS   AGE
    hw-event-proxy-operator-controller-manager-74d5649b7c-dzgtl     2/2     Running   0          25s

12.4. 클러스터 노드의 Redfish BMC 베어 메탈 이벤트 구독

노드의 BMCEventSubscription CR(사용자 정의 리소스)을 생성하고 이벤트에 대한 HardwareEvent CR을 생성하고 BMC에 대한 Secret CR을 생성하여 클러스터의 노드에서 생성된 Redfish BMC 이벤트를 구독할 수 있습니다.

12.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 제조업체 설명서를 참조하십시오.

프로세스

  1. 다음 curl 명령을 실행하여 노드 하드웨어에 Redfish EventService 가 활성화되어 있는지 확인합니다.

    $ curl https://<bmc_ip_address>/redfish/v1/EventService --insecure -H 'Content-Type: application/json' -u "<bmc_username>:<password>"

    다음과 같습니다.

    bmc_ip_address
    Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

    출력 예

    {
       "@odata.context": "/redfish/v1/$metadata#EventService.EventService",
       "@odata.id": "/redfish/v1/EventService",
       "@odata.type": "#EventService.v1_0_2.EventService",
       "Actions": {
          "#EventService.SubmitTestEvent": {
             "EventType@Redfish.AllowableValues": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
             "target": "/redfish/v1/EventService/Actions/EventService.SubmitTestEvent"
          }
       },
       "DeliveryRetryAttempts": 3,
       "DeliveryRetryIntervalSeconds": 30,
       "Description": "Event Service represents the properties for the service",
       "EventTypesForSubscription": ["StatusChange", "ResourceUpdated", "ResourceAdded", "ResourceRemoved", "Alert"],
       "EventTypesForSubscription@odata.count": 5,
       "Id": "EventService",
       "Name": "Event Service",
       "ServiceEnabled": true,
       "Status": {
          "Health": "OK",
          "HealthRollup": "OK",
          "State": "Enabled"
       },
       "Subscriptions": {
          "@odata.id": "/redfish/v1/EventService/Subscriptions"
       }
    }

  2. 다음 명령을 실행하여 클러스터의 Bare Metal Event Relay 서비스 경로를 가져옵니다.

    $ oc get route -n openshift-bare-metal-events

    출력 예

    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

  3. BMCEventSubscription 리소스를 생성하여 Redfish 이벤트를 구독합니다.

    1. 다음 YAML을 bmc_sub.yaml 파일에 저장합니다.

      apiVersion: metal3.io/v1alpha1
      kind: BMCEventSubscription
      metadata:
        name: sub-01
        namespace: openshift-machine-api
      spec:
         hostName: <hostname> 1
         destination: <proxy_service_url> 2
         context: ''
      1
      Redfish 이벤트가 생성되는 작업자 노드의 이름 또는 UUID를 지정합니다.
      2
      베어 메탈 이벤트 프록시 서비스를 지정합니다(예: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook ).
    2. BMCEventSubscription CR을 생성합니다.

      $ oc create -f bmc_sub.yaml
  4. 선택 사항: BMC 이벤트 서브스크립션을 삭제하려면 다음 명령을 실행합니다.

    $ oc delete -f bmc_sub.yaml
  5. 선택 사항: BMCEventSubscription CR을 생성하지 않고 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

    다음과 같습니다.

    proxy_service_url
    베어 메탈 이벤트 프록시 서비스(예: https://hw-event-proxy-openshift-bare-metal-events.apps.compute-1.example.com/webhook )입니다.
    bmc_ip_address
    Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

    출력 예

    HTTP/1.1 201 Created
    Server: AMI MegaRAC Redfish Service
    Location: /redfish/v1/EventService/Subscriptions/1
    Allow: GET, POST
    Access-Control-Allow-Origin: *
    Access-Control-Expose-Headers: X-Auth-Token
    Access-Control-Allow-Headers: X-Auth-Token
    Access-Control-Allow-Credentials: true
    Cache-Control: no-cache, must-revalidate
    Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>; rel=describedby
    Link: <http://redfish.dmtf.org/schemas/v1/EventDestination.v1_6_0.json>
    Link: </redfish/v1/EventService/Subscriptions>; path=
    ETag: "1651135676"
    Content-Type: application/json; charset=UTF-8
    OData-Version: 4.0
    Content-Length: 614
    Date: Thu, 28 Apr 2022 08:47:57 GMT

12.4.2. curl을 사용하여 Redfish 베어 메탈 이벤트 서브스크립션 쿼리

일부 하드웨어 벤더는 Redfish 하드웨어 이벤트 서브스크립션의 양을 제한합니다. curl 을 사용하여 Redfish 이벤트 서브스크립션 수를 쿼리할 수 있습니다.

사전 요구 사항

  • BMC의 사용자 이름과 암호를 가져옵니다.
  • 클러스터에 Redfish 사용 BMC(Baseboard Management Controller)를 사용하여 베어 메탈 노드를 배포하고 BMC에서 Redfish 하드웨어 이벤트를 활성화합니다.

프로세스

  1. 다음 curl 명령을 실행하여 BMC의 현재 서브스크립션을 확인합니다.

    $ curl --globoff -H "Content-Type: application/json" -k -X GET --user <bmc_username>:<password> https://<bmc_ip_address>/redfish/v1/EventService/Subscriptions

    다음과 같습니다.

    bmc_ip_address
    Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

    출력 예

    % Total % Received % Xferd Average Speed Time Time Time Current
    Dload Upload Total Spent Left Speed
    100 435 100 435 0 0 399 0 0:00:01 0:00:01 --:--:-- 399
    {
      "@odata.context": "/redfish/v1/$metadata#EventDestinationCollection.EventDestinationCollection",
      "@odata.etag": ""
      1651137375 "",
      "@odata.id": "/redfish/v1/EventService/Subscriptions",
      "@odata.type": "#EventDestinationCollection.EventDestinationCollection",
      "Description": "Collection for Event Subscriptions",
      "Members": [
      {
        "@odata.id": "/redfish/v1/EventService/Subscriptions/1"
      }],
      "Members@odata.count": 1,
      "Name": "Event Subscriptions Collection"
    }

    이 예에서 단일 서브스크립션이 /redfish/v1/EventService/Subscriptions/1 로 구성되어 있습니다.

  2. 선택 사항: 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

    다음과 같습니다.

    bmc_ip_address
    Redfish 이벤트가 생성되는 BMC의 IP 주소입니다.

12.4.3. 베어 메탈 이벤트 및 Secret CR 생성

베어 메탈 이벤트 사용을 시작하려면 Redfish 하드웨어가 있는 호스트에 대한 HardwareEvent CR(사용자 정의 리소스)을 생성합니다. 하드웨어 이벤트 및 오류는 hw-event-proxy 로그에 보고됩니다.

사전 요구 사항

  • OpenShift Container Platform CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 베어 메탈 이벤트 릴레이를 설치했습니다.
  • BMC Redfish 하드웨어에 대한 BMCEventSubscription CR을 생성했습니다.

프로세스

  1. HardwareEvent CR(사용자 정의 리소스)을 생성합니다.

    참고

    여러 HardwareEvent 리소스가 허용되지 않습니다.

    1. 다음 YAML을 hw-event.yaml 파일에 저장합니다.

      apiVersion: "event.redhat-cne.org/v1alpha1"
      kind: "HardwareEvent"
      metadata:
        name: "hardware-event"
      spec:
        nodeSelector:
          node-role.kubernetes.io/hw-event: "" 1
        logLevel: "debug" 2
        msgParserTimeout: "10" 3
      1
      필수 항목입니다. nodeSelector 필드를 사용하여 지정된 레이블이 있는 노드를 대상으로 지정합니다(예: node-role.kubernetes.io/hw-event: "" ).
      참고

      OpenShift Container Platform 4.13 이상에서는 베어 메탈 이벤트에 HTTP 전송을 사용할 때 HardwareEvent 리소스에서 spec.transportHost 필드를 설정할 필요가 없습니다. 베어 메탈 이벤트에 AMQP 전송을 사용하는 경우에만 transportHost 를 설정합니다.

      2
      선택 사항: 기본값은 debug 입니다. hw-event-proxy 로그에서 로그 수준을 설정합니다. 다음과 같은 로그 수준을 사용할 수 있습니다. fatal,error,warning,info,debug,trace.
      3
      선택 사항: Message Parser의 시간 초과 값을 밀리초로 설정합니다. 메시지 구문 분석 요청이 시간 초과 내에 응답하지 않으면 원래 하드웨어 이벤트 메시지가 클라우드 네이티브 이벤트 프레임워크에 전달됩니다. 기본값은 10입니다.
    2. 클러스터에 HardwareEvent CR을 적용합니다.

      $ oc create -f hardware-event.yaml
  2. 하드웨어 이벤트 프록시가 베어 메탈 호스트의 Redfish 메시지 레지스트리에 액세스할 수 있는 BMC 사용자 이름 및 암호 Secret CR을 생성합니다.

    1. hw-event-bmc-secret.yaml 파일에 다음 YAML을 저장합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: redfish-basic-auth
      type: Opaque
      stringData: 1
        username: <bmc_username>
        password: <bmc_password>
        # BMC host DNS or IP address
        hostaddr: <bmc_host_ip_address>
      1
      stringData 아래에 다양한 항목의 일반 텍스트 값을 입력합니다.
    2. Secret CR을 생성합니다.

      $ oc create -f hw-event-bmc-secret.yaml

12.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: ocloudNotifications API의 상태를 반환합니다.
참고

9089 는 애플리케이션 Pod에 배포된 cloud-event-consumer 컨테이너의 기본 포트입니다. 필요에 따라 애플리케이션에 대해 다른 포트를 구성할 수 있습니다.

api/ocloudNotifications/v1/subscriptions
HTTP 방법

GET api/ocloudNotifications/v1/subscriptions

설명

서브스크립션 목록을 반환합니다. 서브스크립션이 존재하는 경우 200 OK 상태 코드가 서브스크립션 목록과 함께 반환됩니다.

API 응답 예

[
 {
  "id": "ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "endpointUri": "http://localhost:9089/api/ocloudNotifications/v1/dummy",
  "uriLocation": "http://localhost:8089/api/ocloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "resource": "/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
 }
]

HTTP 방법

POST api/ocloudNotifications/v1/subscriptions

설명

새 서브스크립션을 생성합니다. 서브스크립션이 성공적으로 생성되었거나 이미 존재하는 경우 201 Created 상태 코드가 반환됩니다.

표 12.1. 쿼리 매개변수
매개변수유형

subscription

data

페이로드 예

{
  "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>가 있는 서브스크립션 세부 정보를 반환합니다.

표 12.2. 쿼리 매개변수
매개변수유형

<subscription_id>

string

API 응답 예

{
  "id":"ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "endpointUri":"http://localhost:9089/api/ocloudNotifications/v1/dummy",
  "uriLocation":"http://localhost:8089/api/ocloudNotifications/v1/subscriptions/ca11ab76-86f9-428c-8d3a-666c24e34d32",
  "resource":"/cluster/node/openshift-worker-0.openshift.example.com/redfish/event"
}

api/ocloudNotifications/v1/health/
HTTP 방법

GET api/ocloudNotifications/v1/health/

설명

ocloudNotifications REST API의 상태를 반환합니다.

API 응답 예

OK

12.6. PTP 또는 베어 메탈 이벤트에 HTTP 전송을 사용하도록 소비자 애플리케이션 마이그레이션

이전에 PTP 또는 베어 메탈 이벤트 소비자 애플리케이션을 배포한 경우 HTTP 메시지 전송을 사용하도록 애플리케이션을 업데이트해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • PTP Operator 또는 Bare Metal Event Relay를 기본적으로 HTTP 전송을 사용하는 버전 4.13 이상으로 업데이트했습니다.

프로세스

  1. HTTP 전송을 사용하도록 이벤트 소비자 애플리케이션을 업데이트합니다. 클라우드 이벤트 사이드카 배포에 대한 http-event-publishers 변수를 설정합니다.

    예를 들어 PTP 이벤트가 구성된 클러스터에서 다음 YAML 스니펫에서는 클라우드 이벤트 사이드카 배포를 보여줍니다.

    containers:
      - name: cloud-event-sidecar
        image: cloud-event-sidecar
        args:
          - "--metrics-addr=127.0.0.1:9091"
          - "--store-path=/store"
          - "--transport-host=consumer-events-subscription-service.cloud-events.svc.cluster.local:9043"
          - "--http-event-publishers=ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043" 1
          - "--api-port=8089"
    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 으로 설정합니다.

  2. 이벤트 소비자 애플리케이션과 함께 consumer-events-subscription-service 서비스를 배포합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: Service
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        service.alpha.openshift.io/serving-cert-secret-name: sidecar-consumer-secret
      name: consumer-events-subscription-service
      namespace: cloud-events
      labels:
        app: consumer-service
    spec:
      ports:
        - name: sub-port
          port: 9043
      selector:
        app: consumer
      clusterIP: None
      sessionAffinity: None
      type: ClusterIP

13장. 대규모 페이지의 기능과 애플리케이션에서 대규모 페이지를 사용하는 방법

13.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의 애플리케이션이 사전 할당된 대규모 페이지를 할당하고 사용할 수 있습니다.

13.2. 앱에서 대규모 페이지를 사용하는 방법

노드에서 대규모 페이지 용량을 보고하려면 노드가 대규모 페이지를 사전 할당해야 합니다. 노드는 단일 크기의 대규모 페이지만 사전 할당할 수 있습니다.

대규모 페이지는 hugepages-<size> 리소스 이름으로 컨테이너 수준 리소스 요구사항에 따라 사용할 수 있습니다. 여기서 크기는 특정 노드에서 지원되는 정수 값이 사용된 가장 간단한 바이너리 표현입니다. 예를 들어 노드에서 2,048KiB 페이지 크기를 지원하는 경우 예약 가능한 리소스 hugepages-2Mi를 공개합니다. CPU 또는 메모리와 달리 대규모 페이지는 초과 커밋을 지원하지 않습니다.

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
hugepages의 메모리 양은 할당할 정확한 양으로 지정하십시오. 이 값을 hugepages의 메모리 양과 페이지 크기를 곱한 값으로 지정하지 마십시오. 예를 들어 대규모 페이지 크기가 2MB이고 애플리케이션에 100MB의 대규모 페이지 지원 RAM을 사용하려면 50개의 대규모 페이지를 할당합니다. OpenShift Container Platform에서 해당 계산을 처리합니다. 위의 예에서와 같이 100MB를 직접 지정할 수 있습니다.

특정 크기의 대규모 페이지 할당

일부 플랫폼에서는 여러 대규모 페이지 크기를 지원합니다. 특정 크기의 대규모 페이지를 할당하려면 대규모 페이지 부팅 명령 매개변수 앞에 대규모 페이지 크기 선택 매개변수 hugepagesz=<size>를 지정합니다. <size> 값은 바이트 단위로 지정해야 하며 스케일링 접미사 [kKmMgG]를 선택적으로 사용할 수 있습니다. 기본 대규모 페이지 크기는 default_hugepagesz=<size> 부팅 매개변수로 정의할 수 있습니다.

대규모 페이지 요구사항

  • 대규모 페이지 요청은 제한과 같아야 합니다. 제한은 지정되었으나 요청은 지정되지 않은 경우 제한이 기본값입니다.
  • 대규모 페이지는 Pod 범위에서 격리됩니다. 컨테이너 격리는 향후 반복에서 계획됩니다.
  • 대규모 페이지에서 지원하는 EmptyDir 볼륨은 Pod 요청보다 더 많은 대규모 페이지 메모리를 사용하면 안 됩니다.
  • SHM_HUGETLBshmget()를 통해 대규모 페이지를 사용하는 애플리케이션은 proc/sys/vm/hugetlb_shm_group과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.

13.3. Downward API를 사용하여 Huge Page 리소스 사용

Downward API를 사용하여 컨테이너에서 사용하는 Huge Page 리소스에 대한 정보를 삽입할 수 있습니다.

리소스 할당을 환경 변수, 볼륨 플러그인 또는 둘 다로 삽입할 수 있습니다. 컨테이너에서 개발하고 실행하는 애플리케이션은 지정된 볼륨에서의 환경 변수 또는 파일을 읽고 사용할 수 있는 리소스를 확인할 수 있습니다.

프로세스

  1. 다음 예와 유사한 hugepages-volume-pod.yaml 파일을 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: hugepages-volume-
      labels:
        app: hugepages-example
    spec:
      containers:
      - securityContext:
          capabilities:
            add: [ "IPC_LOCK" ]
        image: rhel7:latest
        command:
        - sleep
        - inf
        name: example
        volumeMounts:
        - mountPath: /dev/hugepages
          name: hugepage
        - mountPath: /etc/podinfo
          name: podinfo
        resources:
          limits:
            hugepages-1Gi: 2Gi
            memory: "1Gi"
            cpu: "1"
          requests:
            hugepages-1Gi: 2Gi
        env:
        - name: REQUESTS_HUGEPAGES_1GI <.>
          valueFrom:
            resourceFieldRef:
              containerName: example
              resource: requests.hugepages-1Gi
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
      - name: podinfo
        downwardAPI:
          items:
            - path: "hugepages_1G_request" <.>
              resourceFieldRef:
                containerName: example
                resource: requests.hugepages-1Gi
                divisor: 1Gi

    <.> requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 REQUESTS_HUGEPAGES_1GI 환경 변수로 표시하도록 지정합니다. <.>는 requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 파일 /etc/podinfo/hugepages_1G_request로 표시하도록 지정합니다.

  2. volume-pod.yaml 파일에서 Pod를 생성합니다.

    $ oc create -f hugepages-volume-pod.yaml

검증

  1. REQUESTS_HUGEPAGES_1GI 환경 변수 값을 확인합니다.

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
         -- env | grep REQUESTS_HUGEPAGES_1GI

    출력 예

    REQUESTS_HUGEPAGES_1GI=2147483648

  2. /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

    출력 예

    2

13.4. 부팅 시 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. 대규모 페이지 예약은 부팅 시 예약하는 방법과 런타임 시 예약하는 방법 두 가지가 있습니다. 부팅 시 예약은 메모리가 아직 많이 조각화되어 있지 않으므로 성공할 가능성이 높습니다. Node Tuning Operator는 현재 특정 노드에서 대규모 페이지에 대한 부팅 시 할당을 지원합니다.

프로세스

노드 재부팅을 최소화하려면 다음 단계를 순서대로 수행해야 합니다.

  1. 동일한 대규모 페이지 설정이 필요한 모든 노드에 하나의 레이블을 지정합니다.

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
  2. 다음 콘텐츠로 파일을 생성하고 이름을 hugepages-tuned-boottime.yaml로 지정합니다.

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      name: hugepages 1
      namespace: openshift-cluster-node-tuning-operator
    spec:
      profile: 2
      - data: |
          [main]
          summary=Boot time configuration for hugepages
          include=openshift-node
          [bootloader]
          cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 3
        name: openshift-node-hugepages
    
      recommend:
      - machineConfigLabels: 4
          machineconfiguration.openshift.io/role: "worker-hp"
        priority: 30
        profile: openshift-node-hugepages
    1
    Tuned 리소스의 namehugepages로 설정합니다.
    2
    대규모 페이지를 할당할 profile 섹션을 설정합니다.
    3
    일부 플랫폼에서는 다양한 크기의 대규모 페이지를 지원하므로 매개변수 순서가 중요합니다.
    4
    머신 구성 풀 기반 일치를 활성화합니다.
  3. Tuned hugepages 오브젝트를 생성합니다.

    $ oc create -f hugepages-tuned-boottime.yaml
  4. 다음 콘텐츠로 파일을 생성하고 이름을 hugepages-mcp.yaml로 지정합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: worker-hp
      labels:
        worker-hp: ""
    spec:
      machineConfigSelector:
        matchExpressions:
          - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker-hp: ""
  5. 머신 구성 풀을 생성합니다.

    $ oc create -f hugepages-mcp.yaml

조각화되지 않은 메모리가 충분한 경우 worker-hp 머신 구성 풀의 모든 노드에 50개의 2Mi 대규모 페이지가 할당되어 있어야 합니다.

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
참고

TuneD 부트로더 플러그인은 RHCOS(Red Hat Enterprise Linux CoreOS) 작업자 노드만 지원합니다.

13.5. 투명한 대규모 페이지 비활성화

THP(Transparent Huge Pages)는 대규모 페이지를 생성, 관리 및 사용하는 대부분의 측면을 자동화하려고 합니다. THP는 대규모 페이지를 자동으로 관리하므로 모든 유형의 워크로드에 대해 항상 최적으로 처리되는 것은 아닙니다. THP는 많은 애플리케이션이 자체적으로 대규모 페이지를 처리하므로 성능 회귀를 유발할 수 있습니다. 따라서 THP를 비활성화하는 것이 좋습니다. 다음 단계에서는 Node Tuning Operator(NTO)를 사용하여 THP를 비활성화하는 방법을 설명합니다.

프로세스

  1. 다음 콘텐츠를 사용하여 파일을 생성하고 이름을 thp-disable-tuned.yaml 로 지정합니다.

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      name: thp-workers-profile
      namespace: openshift-cluster-node-tuning-operator
    spec:
      profile:
      - data: |
          [main]
          summary=Custom tuned profile for OpenShift to turn off THP on worker nodes
          include=openshift-node
    
          [vm]
          transparent_hugepages=never
        name: openshift-thp-never-worker
    
      recommend:
      - match:
        - label: node-role.kubernetes.io/worker
        priority: 25
        profile: openshift-thp-never-worker
  2. Tuned 오브젝트를 생성합니다.

    $ oc create -f thp-disable-tuned.yaml
  3. 활성 프로필 목록을 확인합니다.

    $ oc get profile -n openshift-cluster-node-tuning-operator

검증

  • 노드 중 하나에 로그인하고 일반 THP 검사를 수행하여 노드가 프로필을 성공적으로 적용했는지 확인합니다.

    $ cat /sys/kernel/mm/transparent_hugepage/enabled

    출력 예

    always madvise [never]

14장. 짧은 대기 시간 튜닝

14.1. 클러스터 노드에 대한 짧은 대기 시간 튜닝 이해

엣지 컴퓨팅은 대기 시간 및 혼잡 문제를 줄이고 통신 및 5G 네트워크 애플리케이션의 애플리케이션 성능을 개선하는 데 중요한 역할을 합니다. 5G의 네트워크 성능 요구 사항을 충족하기 위해서는 대기 시간이 가장 낮은 네트워크 아키텍처를 유지하는 것이 중요합니다. 4G 기술에 비해 평균 대기 시간은 50ms이고 5G는 1ms 이하의 대기 시간에 도달할 수 있습니다. 이렇게 대기 시간이 감소하면 무선 처리량이 10배 증가합니다.

14.1.1. 짧은 대기 시간 정보

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를 분리하여 워크로드를 실행할 수 있습니다.

중요

OpenShift Container Platform 4.14에서는 클러스터에 성능 프로필을 적용하면 클러스터의 모든 노드가 재부팅됩니다. 이 재부팅에는 성능 프로필의 대상이 아닌 컨트롤 플레인 노드 및 작업자 노드가 포함됩니다. 이 릴리스에서는 RHEL 9과 일치하는 Linux 제어 그룹 버전 2(cgroup v2)를 사용하므로 OpenShift Container Platform 4.14에서 알려진 문제입니다. 성능 프로파일과 관련된 짧은 대기 시간 튜닝 기능은 cgroup v2를 지원하지 않으므로 노드가 재부팅되어 cgroup v1 구성으로 다시 전환합니다.

클러스터의 모든 노드를 cgroups v2 구성으로 되돌리려면 Node 리소스를 편집해야 합니다. (OCPBUGS-16976)

참고

Telco에서 PerformanceProfile 을 사용하여 짧은 대기 시간, 실시간 및 DPDK(Data Plane Development Kit) 워크로드를 사용하는 클러스터는 cgroup v2 지원 부족으로 인해 cgroups v1로 자동으로 되돌립니다. PerformanceProfile 을 사용하는 경우 cgroup v2를 활성화하는 것은 지원되지 않습니다.

OpenShift Container Platform은 다양한 산업 환경의 요구 사항을 충족하기 위해 PerformanceProfile 을 조정할 수 있는 Node Tuning Operator에 대한 워크로드 힌트도 지원합니다. 워크로드 힌트는 highPowerConsumption (확장된 전력 소비 비용에서 낮은 대기 시간) 및 realTime (하이선 대기 시간에 제공되는 우선 순위)에 사용할 수 있습니다. 이러한 힌트에 대한 true/false 설정의 조합을 사용하여 애플리케이션별 워크로드 프로필 및 요구 사항을 처리할 수 있습니다.

워크로드 힌트는 산업 부문 설정에 대한 성능의 미세 조정을 단순화합니다. "one size fits all" 접근 방식 대신 워크로드 힌트는 우선 순위 배치와 같은 사용 패턴을 제공할 수 있습니다.

  • 짧은 대기 시간
  • 실시간 기능
  • 효율적인 전원 사용

이상적으로 이전에 나열된 모든 항목의 우선 순위가 지정됩니다. 그러나 이러한 항목 중 일부는 다른 항목의 비용이 부과됩니다. Node Tuning Operator는 이제 워크로드 기대치를 인식하고 워크로드의 요구 사항을 보다 효과적으로 충족할 수 있습니다. 이제 클러스터 관리자가 워크로드가 중단되는 사용 사례를 지정할 수 있습니다. Node Tuning Operator는 PerformanceProfile 을 사용하여 워크로드에 대한 성능 설정을 미세 조정합니다.

애플리케이션이 작동하는 환경에는 해당 동작에 영향을 미칩니다. 엄격한 대기 시간 요구 사항이 없는 일반적인 데이터 센터의 경우 일부 고성능 워크로드 Pod에 대해 CPU 파티셔닝을 활성화하는 최소 기본 튜닝만 필요합니다. 대기 시간이 더 높은 데이터 센터와 워크로드의 경우 전력 소비를 최적화하기 위해 여전히 조치를 취할 수 있습니다. 가장 복잡한 경우는 제조 장치 및 소프트웨어 정의 라디오와 같은 대기 시간에 민감한 장비에 가까운 클러스터입니다. 이러한 마지막 배포 클래스를 종종 Far edge라고 합니다. Far edge 배포의 경우 매우 낮은 대기 시간은 최고의 우선 순위이며 전원 관리를 통해 달성됩니다.

14.1.2. 짧은 대기 시간과 실시간 애플리케이션의 하이퍼 스레딩 정보

하이퍼 스레딩은 물리적 CPU 프로세서 코어가 두 개의 논리 코어로 작동하여 두 개의 독립 스레드를 동시에 실행할 수 있는 Intel 프로세서 기술입니다. 하이퍼 스레딩을 사용하면 병렬 처리가 도움이 되는 특정 워크로드 유형에 대해 시스템 처리량을 개선할 수 있습니다. 기본 OpenShift Container Platform 구성에서는 Hyper-Threading이 활성화되어야 합니다.

통신 애플리케이션의 경우 가능한 한 대기 시간을 최소화하도록 애플리케이션 인프라를 설계하는 것이 중요합니다. 하이퍼 스레딩은 성능 속도를 저하시킬 수 있으며 짧은 대기 시간이 필요한 컴퓨팅 집약적인 워크로드의 처리량에 부정적인 영향을 미칠 수 있습니다. 하이퍼 스레딩을 비활성화하면 예측 가능한 성능이 보장되고 이러한 워크로드의 처리 시간이 줄어들 수 있습니다.

참고

OpenShift Container Platform을 실행하는 하드웨어에 따라 하이퍼 스레딩 구현 및 구성이 다릅니다. 해당 하드웨어와 관련된 Hyper-Threading 구현에 대한 자세한 내용은 관련 호스트 하드웨어 튜닝 정보를 참조하십시오. 하이퍼 스레딩을 비활성화하면 클러스터 코어당 비용이 증가할 수 있습니다.

14.2. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝

클러스터 성능 프로필을 사용하여 짧은 대기 시간을 위해 노드를 조정합니다. 인프라 및 애플리케이션 컨테이너의 CPU를 제한하고, 대규모 페이지, 하이퍼 스레딩을 구성하고, 대기 시간에 민감한 프로세스를 위해 CPU 파티션을 구성할 수 있습니다.

14.2.1. 성능 프로파일 작성

PPC(Performance Profile Creator) 툴을 사용하여 클러스터 성능 프로필을 생성할 수 있습니다. PPC는 Node Tuning Operator의 기능입니다.

PPC는 사용자 제공 구성과 클러스터에 대한 정보를 결합하여 하드웨어, 토폴로지 및 사용 사례에 적합한 성능 프로필을 생성합니다.

참고

성능 프로필은 클러스터가 기본 하드웨어 리소스에 직접 액세스할 수 있는 베어 메탈 환경에만 적용됩니다. 단일 노드 OpenShift 및 다중 노드 클러스터 모두에 대해 성능 프로필을 구성할 수 있습니다.

다음은 클러스터에서 성능 프로필을 생성하고 적용하기 위한 고급 워크플로입니다.

  • 성능 구성으로 대상으로 지정할 노드의 MCP(머신 구성 풀)를 생성합니다. 단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나뿐이므로 마스터 MCP를 사용해야 합니다.
  • must-gather 명령을 사용하여 클러스터에 대한 정보를 수집합니다.
  • PPC 툴을 사용하여 다음 방법 중 하나를 사용하여 성능 프로필을 생성합니다.

    • Podman을 사용하여 PPC 툴을 실행합니다.
    • 래퍼 스크립트를 사용하여 PPC 툴을 실행합니다.
  • 사용 사례에 대한 성능 프로필을 구성하고 클러스터에 성능 프로필을 적용합니다.
참고

Telco에서 PerformanceProfile 을 사용하여 짧은 대기 시간, 실시간 및 DPDK(Data Plane Development Kit) 워크로드를 사용하는 클러스터는 cgroup v2 지원 부족으로 인해 cgroups v1로 자동으로 되돌립니다. PerformanceProfile 을 사용하는 경우 cgroup v2를 활성화하는 것은 지원되지 않습니다.

14.2.1.1. 성능 프로파일 작성툴 정보

PPC(Performance Profile Creator)는 Node Tuning Operator와 함께 제공되는 명령줄 툴로, 클러스터에 대한 성능 프로필을 생성하는 데 도움이 될 수 있습니다.

처음에 PPC 툴을 사용하여 must-gather 데이터를 처리하여 다음 정보를 포함하여 클러스터의 주요 성능 구성을 표시할 수 있습니다.

  • 할당된 CPU ID로 NUMA 셀 파티셔닝
  • 하이퍼 스레딩 노드 구성

이 정보를 사용하여 성능 프로필을 구성할 수 있습니다.

PPC 실행

PPC 툴에 대한 성능 구성 인수를 지정하여 하드웨어, 토폴로지 및 사용 사례에 적합한 제안된 성능 프로필을 생성합니다.

다음 방법 중 하나를 사용하여 PPC를 실행할 수 있습니다.

  • Podman을 사용하여 PPC 실행
  • 래퍼 스크립트를 사용하여 PPC 실행
참고

래퍼 스크립트를 사용하면 일부 작업은 더 세분화된 Podman 작업을 실행 가능한 스크립트로 추상화합니다. 예를 들어 래퍼 스크립트는 필요한 컨테이너 이미지 가져오기 및 실행, 디렉터리를 컨테이너에 마운트하고 Podman을 통해 컨테이너에 직접 매개 변수를 제공하는 등의 작업을 처리합니다. 두 방법 모두 동일한 결과를 얻을 수 있습니다.

14.2.1.2. 성능 튜닝을 위해 노드를 대상으로 하는 머신 구성 풀 생성

다중 노드 클러스터의 경우 MCP(Machine config pool)를 정의하여 성능 프로필로 구성할 대상 노드를 식별할 수 있습니다.

단일 노드 OpenShift 클러스터에서는 클러스터에 노드가 하나뿐이므로 마스터 MCP를 사용해야 합니다. 단일 노드 OpenShift 클러스터에 대해 별도의 MCP를 생성할 필요가 없습니다.

사전 요구 사항

  • cluster-admin 역할 액세스 권한이 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 다음 명령을 실행하여 구성의 대상 노드에 레이블을 지정합니다.

    $ oc label node <node_name> node-role.kubernetes.io/worker-cnf="" 1
    1
    & lt;node_name >을 노드 이름으로 바꿉니다. 이 예제에서는 worker-cnf 레이블을 적용합니다.
  2. 대상 노드가 포함된 MachineConfigPool 리소스를 생성합니다.

    1. MachineConfigPool 리소스를 정의하는 YAML 파일을 생성합니다.

      mcp-worker-cnf.yaml 파일 예

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        name: worker-cnf 1
        labels:
          machineconfiguration.openshift.io/role: worker-cnf 2
      spec:
        machineConfigSelector:
          matchExpressions:
            - {
                 key: machineconfiguration.openshift.io/role,
                 operator: In,
                 values: [worker, worker-cnf],
              }
        paused: false
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker-cnf: "" 3

      1
      MachineConfigPool 리소스의 이름을 지정합니다.
      2
      머신 구성 풀의 고유한 라벨을 지정합니다.
      3
      사용자가 정의한 대상 레이블이 있는 노드를 지정합니다.
    2. 다음 명령을 실행하여 MachineConfigPool 리소스를 적용합니다.

      $ oc apply -f mcp-worker-cnf.yaml

      출력 예

      machineconfigpool.machineconfiguration.openshift.io/worker-cnf created

검증

  • 다음 명령을 실행하여 클러스터의 머신 구성 풀을 확인합니다.

    $ oc get mcp

    출력 예

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-58433c7c3c1b4ed5ffef95234d451490       True      False      False      3              3                   3                     0                      6h46m
    worker       rendered-worker-168f52b168f151e4f853259729b6azc4       True      False      False      2              2                   2                     0                      6h46m
    worker-cnf   rendered-worker-cnf-168f52b168f151e4f853259729b6azc4   True      False      False      1              1                   1                     0                      73s

14.2.1.3. PPC용 클러스터에 대한 데이터 수집

PPC(Performance Profile creator) 툴에는 must-gather 데이터가 필요합니다. 클러스터 관리자는 must-gather 명령을 실행하여 클러스터에 대한 정보를 캡처합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • 성능 프로필을 사용하여 구성할 대상 MCP를 확인했습니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 명령을 실행하여 클러스터 정보를 수집합니다.

    $ oc adm must-gather

    이 명령은 must-gather.local.1971646453781853027 과 유사한 이름 형식을 사용하여 must-gather 데이터를 사용하여 must-gather 데이터를 사용하여 폴더를 생성합니다.

  3. 선택 사항: must-gather 디렉터리에서 압축 파일을 생성합니다.

    $ tar cvaf must-gather.tar.gz <must_gather_folder> 1
    1
    must-gather 데이터 폴더의 이름으로 바꿉니다.
    참고

    Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.

추가 리소스

14.2.1.4. Podman을 사용하여 Performance Profile Creator 실행

클러스터 관리자는 PPC(Performance Profile Creator)와 함께 Podman을 사용하여 성능 프로필을 생성할 수 있습니다.

PPC 인수에 대한 자세한 내용은 "Performance Profile Creator arguments" 섹션을 참조하십시오.

중요

PPC는 클러스터의 must-gather 데이터를 사용하여 성능 프로필을 생성합니다. 성능 구성을 대상으로 하는 노드 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 must-gather 데이터를 다시 생성해야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • podman 및 OpenShift CLI(oc)를 설치했습니다.
  • Node Tuning Operator 이미지에 액세스할 수 있습니다.
  • 구성을 위한 대상 노드가 포함된 머신 구성 풀을 확인했습니다.
  • 클러스터의 must-gather 데이터에 액세스할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 머신 구성 풀을 확인합니다.

    $ oc get mcp

    출력 예

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-58433c8c3c0b4ed5feef95434d455490       True      False      False      3              3                   3                     0                      8h
    worker       rendered-worker-668f56a164f151e4a853229729b6adc4       True      False      False      2              2                   2                     0                      8h
    worker-cnf   rendered-worker-cnf-668f56a164f151e4a853229729b6adc4   True      False      False      1              1                   1                     0                      79m

  2. 다음 명령을 실행하여 registry.redhat.io 에 인증하려면 Podman을 사용합니다.

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  3. 선택 사항: 다음 명령을 실행하여 PPC 툴에 대한 도움말을 표시합니다.

    $ podman run --rm --entrypoint performance-profile-creator registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 -h

    출력 예

    A tool that automates creation of Performance Profiles
    
    Usage:
      performance-profile-creator [flags]
    
    Flags:
          --disable-ht                        Disable Hyperthreading
      -h, --help                              help for performance-profile-creator
          --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
          --mcp-name string                   MCP name corresponding to the target machines (required)
          --must-gather-dir-path string       Must gather directory path (default "must-gather")
          --offlined-cpu-count int            Number of offlined CPUs
          --per-pod-power-management          Enable Per Pod Power Management
          --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
          --profile-name string               Name of the performance profile to be created (default "performance")
          --reserved-cpu-count int            Number of reserved CPUs (required)
          --rt-kernel                         Enable Real Time Kernel (required)
          --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
          --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
          --user-level-networking             Run with User level Networking(DPDK) enabled

  4. 클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여 로그 인수와 함께 PPC 툴을 실행합니다.

    $ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 --info log --must-gather-dir-path /must-gather
    • --ENTRYPOINT performance-profile-creatorpodman 의 새 진입점으로 성능 프로파일 작성기를 정의합니다.
    • -v <path_to_must_gather >는 다음 구성 요소 중 하나에 대한 경로를 지정합니다.

      • must-gather 데이터가 포함된 디렉터리입니다.
      • must-gather 압축 해제된 .tar 파일이 포함된 기존 디렉터리입니다.
    • --info log 는 출력 형식의 값을 지정합니다.

      출력 예

      level=info msg="Cluster info:"
      level=info msg="MCP 'master' nodes:"
      level=info msg=---
      level=info msg="MCP 'worker' nodes:"
      level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---
      level=info msg="MCP 'worker-cnf' nodes:"
      level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---

  5. 다음 명령을 실행하여 성능 프로필을 생성합니다. 예에서는 샘플 PPC 인수 및 값을 사용합니다.

    $ podman run --entrypoint performance-profile-creator -v <path_to_must_gather>:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --must-gather-dir-path /must-gather --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml
    • -v <path_to_must_gather >는 다음 구성 요소 중 하나에 대한 경로를 지정합니다.

      • must-gather 데이터가 포함된 디렉터리입니다.
      • must-gather 압축 해제된 .tar 파일이 포함된 디렉터리입니다.
    • --mCP-name=worker-cnfworker-=cnf 머신 구성 풀을 지정합니다.
    • --reserved-cpu-count=1 은 예약된 CPU 1개를 지정합니다.
    • --RT-kernel=true 는 실시간 커널을 활성화합니다.
    • --split-reserved-cpus-across-numa=false 는 NUMA 노드 간에 예약된 CPU 분할을 비활성화합니다.
    • --power-consumption-mode=ultra-low-latency 는 전력 소비 증가 시 대기 시간을 최소화합니다.
    • --offlined-cpu-count=1 은 오프라인 CPU 1개를 지정합니다.

      참고

      이 예제의 mcp-name 인수는 oc get mcp 명령의 출력에 따라 worker-cnf로 설정됩니다. 단일 노드 OpenShift의 경우 --mcp-name=master 를 사용합니다.

      출력 예

      level=info msg="Nodes targeted by worker-cnf MCP are: [worker-2]"
      level=info msg="NUMA cell(s): 1"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg="1 reserved CPUs allocated: 0 "
      level=info msg="2 isolated CPUs allocated: 2-3"
      level=info msg="Additional Kernel Args based on configuration: []"

  6. 다음 명령을 실행하여 생성된 YAML 파일을 검토합니다.

    $ cat my-performance-profile.yaml

    출력 예

    ---
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      cpu:
        isolated: 2-3
        offlined: "1"
        reserved: "0"
      machineConfigPoolSelector:
        machineconfiguration.openshift.io/role: worker-cnf
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numa:
        topologyPolicy: restricted
      realTimeKernel:
        enabled: true
      workloadHints:
        highPowerConsumption: true
        perPodPowerManagement: false
        realTime: true

  7. 생성된 프로필을 적용합니다.

    $ oc apply -f my-performance-profile.yaml

    출력 예

    performanceprofile.performance.openshift.io/performance created

14.2.1.5. Performance Profile Creator 래퍼 스크립트 실행

래퍼 스크립트는 PPC(Performance Profile Creator) 툴을 사용하여 성능 프로필을 생성하는 프로세스를 간소화합니다. 이 스크립트는 필요한 컨테이너 이미지 가져오기 및 실행, 디렉터리를 컨테이너에 마운트하고 Podman을 통해 컨테이너에 직접 매개변수를 제공하는 등의 작업을 처리합니다.

Performance Profile Creator 인수에 대한 자세한 내용은 "Performance Profile Creator arguments" 섹션을 참조하십시오.

중요

PPC는 클러스터의 must-gather 데이터를 사용하여 성능 프로필을 생성합니다. 성능 구성을 대상으로 하는 노드 레이블을 다시 지정하는 등 클러스터를 변경하는 경우 PPC를 다시 실행하기 전에 must-gather 데이터를 다시 생성해야 합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • podman 및 OpenShift CLI(oc)를 설치했습니다.
  • Node Tuning Operator 이미지에 액세스할 수 있습니다.
  • 구성을 위한 대상 노드가 포함된 머신 구성 풀을 확인했습니다.
  • must-gather tarball에 액세스합니다.

프로세스

  1. 예를 들어 다음과 같이 run-perf-profile-creator.sh라는 이름의 파일을 로컬 시스템에 생성합니다

    $ vi run-perf-profile-creator.sh
  2. 다음 코드를 파일에 붙여넣습니다.

    #!/bin/bash
    
    readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman}
    readonly CURRENT_SCRIPT=$(basename "$0")
    readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator"
    readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists"
    readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull"
    readonly MUST_GATHER_VOL="/must-gather"
    
    NTO_IMG="registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14"
    MG_TARBALL=""
    DATA_DIR=""
    
    usage() {
      print "Wrapper usage:"
      print "  ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]"
      print ""
      print "Options:"
      print "   -h                 help for ${CURRENT_SCRIPT}"
      print "   -p                 Node Tuning Operator image"
      print "   -t                 path to a must-gather tarball"
    
      ${IMG_EXISTS_CMD} "${NTO_IMG}" && ${CMD} "${NTO_IMG}" -h
    }
    
    function cleanup {
      [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}"
    }
    trap cleanup EXIT
    
    exit_error() {
      print "error: $*"
      usage
      exit 1
    }
    
    print() {
      echo  "$*" >&2
    }
    
    check_requirements() {
      ${IMG_EXISTS_CMD} "${NTO_IMG}" || ${IMG_PULL_CMD} "${NTO_IMG}" || \
          exit_error "Node Tuning Operator image not found"
    
      [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory"
      [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found"
    
      DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory"
      tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball"
      chmod a+rx "${DATA_DIR}"
    
      return 0
    }
    
    main() {
      while getopts ':hp:t:' OPT; do
        case "${OPT}" in
          h)
            usage
            exit 0
            ;;
          p)
            NTO_IMG="${OPTARG}"
            ;;
          t)
            MG_TARBALL="${OPTARG}"
            ;;
          ?)
            exit_error "invalid argument: ${OPTARG}"
            ;;
        esac
      done
      shift $((OPTIND - 1))
    
      check_requirements || exit 1
    
      ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${NTO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}"
      echo "" 1>&2
    }
    
    main "$@"
  3. 이 스크립트에 모든 사용자에 대한 실행 권한을 추가합니다.

    $ chmod a+x run-perf-profile-creator.sh
  4. 다음 명령을 실행하여 registry.redhat.io 에 인증하려면 Podman을 사용합니다.

    $ podman login registry.redhat.io
    Username: <user_name>
    Password: <password>
  5. 선택 사항: 다음 명령을 실행하여 PPC 툴에 대한 도움말을 표시합니다.

    $ ./run-perf-profile-creator.sh -h

    출력 예

    Wrapper usage:
      run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags]
    
    Options:
       -h                 help for run-perf-profile-creator.sh
       -p                 Node Tuning Operator image
       -t                 path to a must-gather tarball
    A tool that automates creation of Performance Profiles
    
    Usage:
      performance-profile-creator [flags]
    
    Flags:
          --disable-ht                        Disable Hyperthreading
      -h, --help                              help for performance-profile-creator
          --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
          --mcp-name string                   MCP name corresponding to the target machines (required)
          --must-gather-dir-path string       Must gather directory path (default "must-gather")
          --offlined-cpu-count int            Number of offlined CPUs
          --per-pod-power-management          Enable Per Pod Power Management
          --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
          --profile-name string               Name of the performance profile to be created (default "performance")
          --reserved-cpu-count int            Number of reserved CPUs (required)
          --rt-kernel                         Enable Real Time Kernel (required)
          --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
          --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
          --user-level-networking             Run with User level Networking(DPDK) enabled

    참고

    선택적으로 -p 옵션을 사용하여 Node Tuning Operator 이미지의 경로를 설정할 수 있습니다. 경로를 설정하지 않으면 래퍼 스크립트는 기본 이미지 registry.redhat.io/openshift4/ose-cluster-node-tuning-rhel9-operator:v4.14 를 사용합니다.

  6. 클러스터에 대한 정보를 표시하려면 다음 명령을 실행하여 로그 인수와 함께 PPC 툴을 실행합니다.

    $ ./run-perf-profile-creator.sh -t /<path_to_must_gather_dir>/must-gather.tar.gz -- --info=log
    • -t /<path_to_must_gather_dir>/must-gather.tar.gz 는 must-gather tarball을 포함하는 디렉터리의 경로를 지정합니다. 이는 래퍼 스크립트에 필요한 인수입니다.

      출력 예

      level=info msg="Cluster info:"
      level=info msg="MCP 'master' nodes:"
      level=info msg=---
      level=info msg="MCP 'worker' nodes:"
      level=info msg="Node: host.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg="Node: host1.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---
      level=info msg="MCP 'worker-cnf' nodes:"
      level=info msg="Node: host2.example.com (NUMA cells: 1, HT: true)"
      level=info msg="NUMA cell 0 : [0 1 2 3]"
      level=info msg="CPU(s): 4"
      level=info msg=---

  7. 다음 명령을 실행하여 성능 프로필을 생성합니다.

    $ ./run-perf-profile-creator.sh -t /path-to-must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=1 --rt-kernel=true --split-reserved-cpus-across-numa=false --power-consumption-mode=ultra-low-latency --offlined-cpu-count=1 > my-performance-profile.yaml

    이 예에서는 샘플 PPC 인수 및 값을 사용합니다.

    • --mCP-name=worker-cnfworker-=cnf 머신 구성 풀을 지정합니다.
    • --reserved-cpu-count=1 은 예약된 CPU 1개를 지정합니다.
    • --RT-kernel=true 는 실시간 커널을 활성화합니다.
    • --split-reserved-cpus-across-numa=false 는 NUMA 노드 간에 예약된 CPU 분할을 비활성화합니다.
    • --power-consumption-mode=ultra-low-latency 는 전력 소비 증가 시 대기 시간을 최소화합니다.
    • --offlined-cpu-count=1 은 오프라인 CPU 1개를 지정합니다.

      참고

      이 예제의 mcp-name 인수는 oc get mcp 명령의 출력에 따라 worker-cnf로 설정됩니다. 단일 노드 OpenShift의 경우 --mcp-name=master 를 사용합니다.

  8. 다음 명령을 실행하여 생성된 YAML 파일을 검토합니다.

    $ cat my-performance-profile.yaml

    출력 예

    ---
    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      cpu:
        isolated: 2-3
        offlined: "1"
        reserved: "0"
      machineConfigPoolSelector:
        machineconfiguration.openshift.io/role: worker-cnf
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numa:
        topologyPolicy: restricted
      realTimeKernel:
        enabled: true
      workloadHints:
        highPowerConsumption: true
        perPodPowerManagement: false
        realTime: true

  9. 생성된 프로필을 적용합니다.

    $ oc apply -f my-performance-profile.yaml

    출력 예

    performanceprofile.performance.openshift.io/performance created

14.2.1.6. Performance Profile Creator 인수
표 14.1. 필요한 Performance Profile Creator 인수
인수설명

mcp-name

MCP의 이름(예: 대상 머신에 해당하는 worker-cnf )입니다.

must-gather-dir-path

의 경로는 디렉터리를 수집해야 합니다.

이 인수는 Podman을 사용하여 PPC 툴을 실행하는 경우에만 필요합니다. 래퍼 스크립트와 함께 PPC를 사용하는 경우 이 인수를 사용하지 마십시오. 대신 래퍼 스크립트에 -t 옵션을 사용하여 must-gather tarball의 디렉터리 경로를 지정합니다.

reserved-cpu-count

예약된 CPU 수입니다. 0보다 큰 자연수를 사용합니다.

rt-kernel

실시간 커널을 활성화합니다.

가능한 값: true 또는 false.

표 14.2. 선택적 Performance Profile Creator 인수
인수설명

disable-ht

하이퍼 스레딩을 비활성화합니다.

가능한 값: true 또는 false.

기본값: false

주의

이 인수가 true 로 설정된 경우 BIOS에서 Hyper-Threading을 비활성화해서는 안 됩니다. 하이퍼 스레딩 비활성화는 커널 명령줄 인수를 사용하여 수행됩니다.

info

이는 클러스터 정보를 캡처합니다. 이 인수에는 must-gather-dir-path 인수도 필요합니다. 다른 인수가 설정되면 무시됩니다.

가능한 값은 다음과 같습니다.

  • log
  • JSON

기본값: log.

offlined-cpu-count

오프라인 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]

power-consumption-mode

전력 소비 모드입니다.

가능한 값은 다음과 같습니다.

  • Default: CPU 파티셔닝을 통해서만 수행되었습니다.
  • low-latency: 대기 시간을 개선하기 위한 향상된 조치
  • Ultra-Low-latency: 전원 관리를 통해 최적의 대기 시간에 제공되는 우선 순위입니다.

기본값: default.

per-pod-power-management

Pod 전원 관리당 활성화. Ultra-Low-latency를 전력 소비 모드로 구성한 경우에는 이 인수를 사용할 수 없습니다.

가능한 값: true 또는 false.

기본값: false

profile-name

생성할 성능 프로파일의 이름입니다.

기본값: performance.

split-reserved-cpus-across-numa

NUMA 노드에서 예약된 CPU를 분할합니다.

가능한 값: true 또는 false.

기본값: false

topology-manager-policy

생성할 성능 프로필의 Kubelet Topology Manager 정책입니다.

가능한 값은 다음과 같습니다.

  • single-numa-node
  • best-effort
  • restricted

기본값: restricted.

user-level-networking

DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.

가능한 값: true 또는 false.

기본값: false

14.2.1.7. 성능 프로필 참조

다음 참조 성능 프로필을 기반으로 사용하여 고유한 사용자 지정 프로필을 개발할 수 있습니다.

14.2.1.7.1. OpenStack에서 OVS-DPDK를 사용하는 클러스터의 성능 프로필 템플릿

RHOSP(Red Hat OpenStack Platform)에서 OVS-DPDK(Data Plane Development Kit)를 사용하여 Open vSwitch를 사용하는 클러스터의 머신 성능을 최대화하려면 성능 프로필을 사용할 수 있습니다.

다음 성능 프로필 템플릿을 사용하여 배포에 대한 프로필을 생성할 수 있습니다.

OVS-DPDK를 사용하는 클러스터의 성능 프로필 템플릿

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: cnf-performanceprofile
spec:
  additionalKernelArgs:
    - nmi_watchdog=0
    - audit=0
    - mce=off
    - processor.max_cstate=1
    - idle=poll
    - intel_idle.max_cstate=0
    - default_hugepagesz=1GB
    - hugepagesz=1G
    - intel_iommu=on
  cpu:
    isolated: <CPU_ISOLATED>
    reserved: <CPU_RESERVED>
  hugepages:
    defaultHugepagesSize: 1G
    pages:
      - count: <HUGEPAGES_COUNT>
        node: 0
        size: 1G
  nodeSelector:
    node-role.kubernetes.io/worker: ''
  realTimeKernel:
    enabled: false
    globallyDisableIrqLoadBalancing: true

CPU_ISOLATED,CPU_RESERVEDHUGEPAGES_COUNT 키에 대한 구성에 적합한 값을 삽입합니다.

14.2.1.7.2. Telco RAN DU 참조 성능 프로파일

다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 Telco RAN DU 워크로드를 호스팅합니다.

Telco RAN DU 참조 성능 프로파일

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

14.2.1.7.3. Telco 코어 참조 성능 프로파일

다음 성능 프로필은 상용 하드웨어에서 OpenShift Container Platform 클러스터에 대한 노드 수준 성능 설정을 구성하여 통신 핵심 워크로드를 호스팅합니다.

Telco 코어 참조 성능 프로파일

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

14.2.2. 지원되는 성능 프로필 API 버전

Node Tuning Operator는 성능 프로필 apiVersion 필드에 대해 v2,v1, v1alpha1 을 지원합니다. v1 및 v1alpha1 API는 동일합니다. v2 API에는 기본값인 false 값을 사용하여 선택적 부울 필드 loballyDisableIrqLoadBalancing이 포함됩니다.

장치 인터럽트 처리를 사용하기 위해 성능 프로파일을 업그레이드

Node Tuning Operator 성능 프로파일 CRD(사용자 정의 리소스 정의)를 v1 또는 v1alpha1에서 v2로 업그레이드하는 경우 기존 프로필에서 globallyDisableIrqLoadBalancingtrue 로 설정됩니다.

참고

globallyDisableIrqLoadBalancing 은 Isolated CPU 세트에 대해 IRQ 로드 밸런싱이 비활성화됩니다. 옵션이 true 로 설정되면 Isolated CPU 세트에 대한 IRQ 로드 밸런싱이 비활성화됩니다. 옵션을 false 로 설정하면 모든 CPU에서 IRQ를 분산할 수 있습니다.

Node Tuning Operator API를 v1alpha1에서 v1로 업그레이드

Node Tuning Operator API 버전을 v1alpha1에서 v1로 업그레이드할 때 "None" 변환 전략을 사용하여 v1alpha1 성능 프로파일이 즉시 변환되고 API 버전 v1을 사용하여 Node Tuning Operator에 제공됩니다.

Node Tuning Operator API를 v1alpha1 또는 v1에서 v2로 업그레이드

이전 Node Tuning Operator API 버전에서 업그레이드할 때 기존 v1 및 v1alpha1 성능 프로파일은 true 값이 truegloballyDisableIrqLoadBalancing 필드를 삽입하는 변환 Webhook를 사용하여 변환됩니다.

14.2.3. 워크로드 힌트를 사용하여 노드 전력 소비 및 실시간 처리 구성

프로세스

  • PPC( Performance Profile Creator) 툴을 사용하여 환경 하드웨어 및 토폴로지에 적합한 PerformanceProfile을 생성합니다. 다음 표에서는 PPC 툴과 관련된 power-consumption-mode 플래그 및 적용된 워크로드 팁에 대해 설정된 가능한 값을 설명합니다.
표 14.3. 대기 시간에 전력 소비 및 실시간 설정 조합의 영향
Performance Profile creator 설정환경설명

Default

workloadHints:
highPowerConsumption: false
realTime: false

대기 시간 요구 사항이 없는 처리량 클러스터

CPU 파티셔닝을 통해서만 성능 달성.

low-latency

workloadHints:
highPowerConsumption: false
realTime: true

지역 데이터 센터

전력 관리, 대기 시간 및 처리량 간의 손상 등 에너지 절약과 대기 시간이 단축되는 것이 좋습니다.

Ultra-low-latency

workloadHints:
highPowerConsumption: true
realTime: true

원거리 엣지 클러스터, 대기 시간 중요한 워크로드

전력 소비 증가의 비용으로 절대 최소 대기 시간 및 최대 결정론에 최적화되어 있습니다.

Pod별 전원 관리

workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

심각 및 중요하지 않은 워크로드

Pod당 전원 관리를 허용합니다.

예제

다음 구성은 일반적으로 telco RAN DU 배포에서 사용됩니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: workload-hints
    spec:
      ...
      workloadHints:
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: false 1
1
시스템 대기 시간에 영향을 줄 수 있는 일부 디버깅 및 모니터링 기능을 비활성화합니다.
참고

성능 프로파일에서 realTime 워크로드 힌트 플래그가 true 로 설정된 경우 고정 CPU가 있는 보장된 모든 Pod에 cpu-quota.crio.io: disable 주석을 추가합니다. 이 주석은 Pod 내에서 프로세스 성능이 저하되지 않도록 하는 데 필요합니다. realTime 워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true 입니다.

전력 소비와 실시간 설정의 조합이 대기 시간에 미치는 영향에 대한 자세한 내용은 워크로드 팁 이해를 참조하십시오.

14.2.4. 공동 배치된 높은 우선 순위 워크로드 및 낮은 우선 순위 워크로드를 실행하는 노드에 대한 전원 저장 구성

우선 순위가 높은 워크로드가 높은 노드의 대기 시간 또는 처리량에 영향을 미치지 않고 우선 순위가 높은 워크로드가 낮은 노드에 대한 전원을 절약할 수 있습니다. 워크로드 자체를 수정하지 않고도 전력 절감이 가능합니다.

중요

이 기능은 Intel Ice Lake 이상 세대의 Intel CPU에서 지원됩니다. 프로세서의 기능은 높은 우선 순위 워크로드의 대기 시간 및 처리량에 영향을 미칠 수 있습니다.

사전 요구 사항

  • BIOS에서 C-states 및 운영 체제를 활성화했습니다.

프로세스

  1. per-pod-power-management 인수가 true 로 설정된 PerformanceProfile 을 생성합니다.

    $ podman run --entrypoint performance-profile-creator -v \
    /must-gather:/must-gather:z registry.redhat.io/openshift4/ose-cluster-node-tuning-operator:v4.14 \
    --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true \
    --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node \
    --must-gather-dir-path /must-gather --power-consumption-mode=low-latency \ 1
    --per-pod-power-management=true > my-performance-profile.yaml
    1
    per-pod-power-management 인수가 true 로 설정된 경우 power-consumption-mode 인수는 default 또는 low-latency 여야 합니다.

    perPodPowerManagement가 있는 PerformanceProfile 의 예

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
         name: performance
    spec:
        [.....]
        workloadHints:
            realTime: true
            highPowerConsumption: false
            perPodPowerManagement: true

  2. PerformanceProfile CR(사용자 정의 리소스)에서 기본 cpufreq governor를 추가 커널 인수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
         name: performance
    spec:
        ...
        additionalKernelArgs:
        - cpufreq.default_governor=schedutil 1
    1
    그러나 schedutil governor를 사용하는 것이 좋습니다. 그러나 온디맨드 또는 전원 세이저와 같은 다른 governor를 사용할 수 있습니다.
  3. TunedPerformancePatch CR에서 최대 CPU 빈도를 설정합니다.

    spec:
      profile:
      - data: |
          [sysfs]
          /sys/devices/system/cpu/intel_pstate/max_perf_pct = <x> 1
    1
    max_perf_pctcpufreq 드라이버가 지원되는 최대 cpu 빈도의 백분율로 설정할 수 있는 최대 빈도를 제어합니다. 이 값은 모든 CPU에 적용됩니다. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든 CPU를 모든 코어 frequency로 제한하는 백분율로 사용할 수 있습니다. 모든 코어의 frequency는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.

14.2.5. 인프라 및 애플리케이션 컨테이너의 CPU 제한

일반 하우스키핑 및 워크로드 작업에서는 대기 시간에 민감한 프로세스에 영향을 줄 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하여 컨텍스트 스위치와 대기 시간이 급증할 수 있습니다. CPU를 파티셔닝하면 noisy 프로세스에서 서로 분리하여 대기 시간에 민감한 프로세스를 방해하지 않습니다. 다음 표에서는 Node Tuning Operator를 사용하여 노드를 조정한 후 CPU에서 프로세스가 실행되는 방법을 설명합니다.

표 14.4. 프로세스의 CPU 할당
프로세스 유형세부 정보

BurstableBestEffort Pod

대기 시간이 짧은 워크로드가 실행 중인 경우를 제외하고 모든 CPU에서 실행

인프라 Pod

대기 시간이 짧은 워크로드가 실행 중인 경우를 제외하고 모든 CPU에서 실행

인터럽트

예약된 CPU로 리디렉션(OpenShift Container Platform 4.7 이상에서 선택 사항)

커널 프로세스

예약된 CPU에 핀

대기 시간에 민감한 워크로드 Pod

격리된 풀에서 특정 전용 CPU 세트에 고정

OS 프로세스/systemd 서비스

예약된 CPU에 핀

모든 QoS 프로세스 유형, Burstable,BestEffort 또는 Guaranteed 의 Pod의 노드에 있는 코어의 할당 가능한 용량은 격리된 풀의 용량과 동일합니다. 예약된 풀의 용량은 클러스터 및 운영 체제 하우스키핑 작업에서 사용할 수 있는 노드의 총 코어 용량에서 제거됩니다.

예시 1

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어와 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장된 Pod에 25개의 코어를 할당하고 BestEffort 또는 Burstable Pod의 경우 25개의 코어를 할당합니다. 이는 격리된 풀의 용량과 일치합니다.

예시 2

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어와 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS 보장된 Pod에 50개의 코어를 할당하고 BestEffort 또는 Burstable Pod의 코어 1개를 할당합니다. 이렇게 하면 격리된 풀의 용량을 하나의 코어로 초과합니다. CPU 용량이 부족하여 Pod 예약이 실패합니다.

사용할 정확한 파티셔닝 패턴은 하드웨어, 워크로드 특성 및 예상되는 시스템 로드와 같은 여러 요인에 따라 다릅니다. 일부 샘플 사용 사례는 다음과 같습니다.

  • 대기 시간에 민감한 워크로드가 NIC(네트워크 인터페이스 컨트롤러)와 같은 특정 하드웨어를 사용하는 경우 격리된 풀의 CPU가 이 하드웨어에 최대한 가까운지 확인합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
  • 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따라 들어오는 모든 패킷 인터럽트를 처리하기 위해 충분히 크기의 예비 풀을 할당합니다. 4.14 이상 버전에서 워크로드는 선택적으로 민감한 것으로 레이블을 지정할 수 있습니다.

예약 및 격리된 파티션에 사용해야 하는 특정 CPU에 대한 결정에는 자세한 분석과 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요소가 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 다릅니다.

중요

예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

하우스키핑 작업과 워크로드가 서로 방해하지 않도록 하려면 성능 프로필의 spec 섹션에 두 개의 CPU 그룹을 지정합니다.

  • isolated - 애플리케이션 컨테이너 워크로드에 대한 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다.
  • reserved - 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다. 예약된 그룹의 스레드는 종종 사용 중입니다. 예약된 그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은 격리된 그룹에서 실행됩니다.

프로세스

  1. 환경의 하드웨어 및 토폴로지에 적합한 성능 프로필을 만듭니다.
  2. 인프라 및 애플리케이션 컨테이너에 대해 reservedisolated하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: infra-cpus
    spec:
      cpu:
        reserved: "0-4,9" 1
        isolated: "5-8" 2
      nodeSelector: 3
        node-role.kubernetes.io/worker: ""
    1
    클러스터 및 운영 체제 하우스키핑 작업을 수행하기 위해 인프라 컨테이너의 CPU를 지정합니다.
    2
    애플리케이션 컨테이너가 워크로드를 실행하는 CPU를 지정합니다.
    3
    선택 사항: 노드 선택기를 지정하여 특정 노드에 성능 프로파일을 적용합니다.

14.2.6. 클러스터의 하이퍼 스레딩 구성

OpenShift Container Platform 클러스터에 대한 Hyper-Threading을 구성하려면 성능 프로필의 CPU 스레드를 예약 또는 분리된 CPU 풀에 대해 구성된 동일한 코어로 설정합니다.

참고

성능 프로필을 구성하고 호스트의 Hyper-Threading 구성을 변경하는 경우 PerformanceProfile YAML에서 CPU isolatedreserved 필드를 새 구성과 일치하도록 업데이트해야 합니다.

주의

이전에 활성화된 호스트 Hyper-Threading 구성을 비활성화하면 PerformanceProfile YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 구성할 호스트의 모든 CPU에서 실행중인 스레드를 확인합니다.

    클러스터에 로그인하고 다음 명령을 실행하여 호스트 CPU에서 실행중인 스레드를 볼 수 있습니다.

    $ lscpu --all --extended

    출력 예

    CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
    0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
    4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

    이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.

    또는 특정 물리적 CPU 코어(아래 예제에서cpu0) 에 설정된 스레드를 보려면 쉘 프롬프트를 열고 다음을 실행합니다.

    $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

    출력 예

    0-4

  2. PerformanceProfile YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어 논리 코어 CPU0 및 CPU4를 isolated 로, 논리 코어 CPU1을 CPU3으로, CPU5를 예약된 CPU7으로 설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

    ...
      cpu:
        isolated: 0,4
        reserved: 1-3,5-7
    ...
    참고

    예약 및 격리된 CPU 풀은 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

중요

Hyper-Threading은 대부분의 Intel 프로세서에서 기본적으로 활성화되어 있습니다. Hyper-Threading을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.

하이퍼 스레딩을 활성화하면 모든 보장된 Pod에서 동시 멀티 스레딩(SMT) 수준의 여러 개를 사용하여 Pod가 실패할 수 있는 "noisy neighbor" 상황을 방지해야 합니다. 자세한 내용은 정적 정책 옵션을 참조하십시오.

14.2.6.1. 짧은 대기 시간 애플리케이션의 하이퍼 스레딩 비활성화

대기 시간이 짧은 처리를 위해 클러스터를 구성할 때 클러스터를 배포하기 전에 Hyper-Threading을 비활성화할지 여부를 고려하십시오. 하이퍼 스레딩을 비활성화하려면 다음 단계를 수행합니다.

  1. 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
  2. nosmt를 추가 커널 인수로 설정합니다. 다음 성능 프로파일 예에서는 이 설정에 대해 설명합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: example-performanceprofile
    spec:
      additionalKernelArgs:
        - nmi_watchdog=0
        - audit=0
        - mce=off
        - processor.max_cstate=1
        - idle=poll
        - intel_idle.max_cstate=0
        - nosmt
      cpu:
        isolated: 2-3
        reserved: 0-1
      hugepages:
        defaultHugepagesSize: 1G
        pages:
          - count: 2
            node: 0
            size: 1G
      nodeSelector:
        node-role.kubernetes.io/performance: ''
      realTimeKernel:
        enabled: true
    참고

    예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

14.2.7. 보장된 pod 분리 CPU의 장치 중단 처리 관리

Node Tuning Operator는 호스트 CPU를 Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 예약된 CPU와 워크로드를 실행하기 위해 애플리케이션 컨테이너의 분리된 CPU로 나누어 호스트 CPU를 관리할 수 있습니다. 이를 통해 대기 시간이 짧은 워크로드의 CPU를 분리된 상태로 설정할 수 있습니다.

장치 중단은 보장된 pod가 실행 중인 CPU를 제외하고 CPU의 과부하를 방지하기 위해 모든 분리된 CPU와 예약된 CPU 간에 균형을 유지합니다. pod에 관련 주석이 설정되어 있으면 보장된 Pod CPU가 장치 인터럽트를 처리하지 못합니다.

새로운 성능 프로파일 필드 globallyDisableIrqLoadBalancing은 장치 중단을 처리할지 여부를 관리하는 데 사용할 수 있습니다. 특정 워크로드의 경우 예약된 CPU가 장치 인터럽트를 처리하기에 충분하지 않으며, 이러한 이유로 장치 인터럽트는 분리된 CPU에서 전역적으로 비활성화되지 않습니다. 기본적으로 Node Tuning Operator는 분리된 CPU에서 장치 인터럽트를 비활성화하지 않습니다.

14.2.7.1. 노드의 유효한 IRQ 선호도 설정 찾기

일부 IRQ 컨트롤러는 IRQ 선호도 설정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 노출합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다.

다음은 IRQ 선호도 설정에 대한 지원이 부족한 드라이버 및 하드웨어의 예입니다. 목록은 전혀 완전하지 않습니다.

  • megaraid_sas와 같은 일부 RAID 컨트롤러 드라이버
  • 많은 비휘발성 메모리 표현(NVMe) 드라이버
  • 마더보드(LOM) 네트워크 컨트롤러의 일부 LAN
  • 드라이버는 managed_irqs사용
참고

IRQ 선호도 설정을 지원하지 않는 이유는 프로세서 유형, IRQ 컨트롤러 또는 마더보드의 회로 연결과 같은 요인과 연관될 수 있습니다.

IRQ의 유효 선호도가 격리된 CPU로 설정된 경우 IRQ 선호도 설정을 지원하지 않는 일부 하드웨어 또는 드라이버의 서명일 수 있습니다. 효과적인 선호도를 찾으려면 호스트에 로그인하고 다음 명령을 실행합니다.

$ find /proc/irq -name effective_affinity -printf "%p: " -exec cat {} \;

출력 예

/proc/irq/0/effective_affinity: 1
/proc/irq/1/effective_affinity: 8
/proc/irq/2/effective_affinity: 0
/proc/irq/3/effective_affinity: 1
/proc/irq/4/effective_affinity: 2
/proc/irq/5/effective_affinity: 1
/proc/irq/6/effective_affinity: 1
/proc/irq/7/effective_affinity: 1
/proc/irq/8/effective_affinity: 1
/proc/irq/9/effective_affinity: 2
/proc/irq/10/effective_affinity: 1
/proc/irq/11/effective_affinity: 1
/proc/irq/12/effective_affinity: 4
/proc/irq/13/effective_affinity: 1
/proc/irq/14/effective_affinity: 1
/proc/irq/15/effective_affinity: 1
/proc/irq/24/effective_affinity: 2
/proc/irq/25/effective_affinity: 4
/proc/irq/26/effective_affinity: 2
/proc/irq/27/effective_affinity: 1
/proc/irq/28/effective_affinity: 8
/proc/irq/29/effective_affinity: 4
/proc/irq/30/effective_affinity: 4
/proc/irq/31/effective_affinity: 8
/proc/irq/32/effective_affinity: 8
/proc/irq/33/effective_affinity: 1
/proc/irq/34/effective_affinity: 2

일부 드라이버는 커널 및 사용자 공간에 의해 내부적으로 관리되는 managed_irqs 를 사용합니다. 사용자 공간은 선호도를 변경할 수 없습니다. 경우에 따라 이러한 IRQ가 분리된 CPU에 할당될 수 있습니다. managed_irqs 에 대한 자세한 내용은 분리된 CPU를 대상으로 하는 경우에도 관리 인터럽트의 유사성을 변경할 수 없습니다.

14.2.7.2. IRQ 동적 로드 밸런싱을 위한 노드 구성

IRQ(장치 인터럽트 요청)를 수신할 수 있는 코어를 제어하도록 IRQ 동적 로드 밸런싱 클러스터 노드를 구성합니다.

사전 요구 사항

  • 코어 격리의 경우 모든 서버 하드웨어 구성 요소에서 IRQ 선호도를 지원해야 합니다. 서버의 하드웨어 구성 요소가 IRQ 선호도를 지원하는지 확인하려면 서버의 하드웨어 사양을 보거나 하드웨어 공급자에게 문의하십시오.

프로세스

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
  2. performance.openshift.io/v2를 사용하도록 성능 프로파일의 apiVersion을 설정합니다.
  3. globallyDisableIrqLoadBalancing 필드를 삭제제거하거나 false로 설정합니다.
  4. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 CPU를 예약하는 프로파일을 보여줍니다. isolated CPU 세트에서 실행되는 Pod에 대해 IRQ 로드 밸런싱이 활성화됩니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: dynamic-irq-profile
    spec:
      cpu:
        isolated: 2-5
        reserved: 0-1
    ...
    참고

    예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

  5. 전용 CPU를 사용하는 pod를 생성하고 irq-load-balancing.crio.iocpu-quota.crio.io 주석을 disable로 설정합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dynamic-irq-pod
      annotations:
         irq-load-balancing.crio.io: "disable"
         cpu-quota.crio.io: "disable"
    spec:
      containers:
      - name: dynamic-irq-pod
        image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.14"
        command: ["sleep", "10h"]
        resources:
          requests:
            cpu: 2
            memory: "200M"
          limits:
            cpu: 2
            memory: "200M"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      runtimeClassName: performance-dynamic-irq-profile
    ...
  6. performance-<profile_name> 형식으로 pod runtimeClassName을 입력합니다. 여기서<profile_name>은 PerformanceProfile YAML의 name입니다 (예: performance- dynamic-irq-profile).
  7. 노드 선택기를 cnf-worker 을 대상으로 설정합니다.
  8. Pod가 올바르게 실행되고 있는지 확인합니다. 상태가 running이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.

    $ oc get pod -o wide

    예상 출력

    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>

  9. IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.

    $ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

    예상 출력

    Cpus_allowed_list:  2-3

  10. 노드 구성이 올바르게 적용되었는지 확인합니다. 노드에 로그인하여 구성을 확인합니다.

    $ oc debug node/<node-name>

    예상 출력

    Starting pod/<node-name>-debug ...
    To use host binaries, run `chroot /host`
    
    Pod IP: <ip-address>
    If you don't see a command prompt, try pressing enter.
    
    sh-4.4#

  11. 노드 파일 시스템을 사용할 수 있는지 확인합니다.

    sh-4.4# chroot /host

    예상 출력

    sh-4.4#

  12. 기본 시스템 CPU 선호도 마스크에 dynamic-irq-pod CPU (예: CPU 2 및 3)가 포함되지 않도록 합니다.

    $ cat /proc/irq/default_smp_affinity

    출력 예

    33

  13. IRQ가 dynamic-irq-pod CPU에서 실행되도록 구성되어 있지 않은지 확인합니다.

    find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    출력 예

    /proc/irq/0/smp_affinity_list: 0-5
    /proc/irq/1/smp_affinity_list: 5
    /proc/irq/2/smp_affinity_list: 0-5
    /proc/irq/3/smp_affinity_list: 0-5
    /proc/irq/4/smp_affinity_list: 0
    /proc/irq/5/smp_affinity_list: 0-5
    /proc/irq/6/smp_affinity_list: 0-5
    /proc/irq/7/smp_affinity_list: 0-5
    /proc/irq/8/smp_affinity_list: 4
    /proc/irq/9/smp_affinity_list: 4
    /proc/irq/10/smp_affinity_list: 0-5
    /proc/irq/11/smp_affinity_list: 0
    /proc/irq/12/smp_affinity_list: 1
    /proc/irq/13/smp_affinity_list: 0-5
    /proc/irq/14/smp_affinity_list: 1
    /proc/irq/15/smp_affinity_list: 0
    /proc/irq/24/smp_affinity_list: 1
    /proc/irq/25/smp_affinity_list: 1
    /proc/irq/26/smp_affinity_list: 1
    /proc/irq/27/smp_affinity_list: 5
    /proc/irq/28/smp_affinity_list: 1
    /proc/irq/29/smp_affinity_list: 0
    /proc/irq/30/smp_affinity_list: 0-5

14.2.8. 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Node Tuning Operator를 사용하여 특정 노드에 대규모 페이지를 할당합니다.

OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Node Tuning Operator는 성능 프로필을 사용하여 이 작업을 더 쉽게 수행할 수 있는 방법을 제공합니다.

예를 들어 성능 프로필의 hugepages pages 섹션에서 size, countnode(선택사항)로 된 여러 블록을 지정할 수 있습니다.

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 1
1
node는 대규모 페이지가 할당된 NUMA 노드입니다. node를 생략하면 페이지가 모든 NUMA 노드에 균등하게 분산됩니다.
참고

관련 머신 구성 풀 상태에 업데이트가 완료된 것으로 나타날 때까지 기다립니다.

대규모 페이지를 할당하기 위해 수행해야 하는 구성 단계는 이것이 전부입니다.

검증

  • 구성을 검증하려면 노드의 /proc/meminfo 파일을 참조하십시오.

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo

    출력 예

    AnonHugePages:    ###### ##
    ShmemHugePages:        0 kB
    HugePages_Total:       2
    HugePages_Free:        2
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       #### ##
    Hugetlb:            #### ##

  • oc describe를 사용하여 새 크기를 보고합니다.

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    출력 예

                                       hugepages-1g=true
     hugepages-###:  ###
     hugepages-###:  ###

14.2.8.1. 여러 대규모 페이지 크기 할당

동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.

예를 들어 1G2M 크기를 정의할 수 있으며 Node Tuning Operator는 다음과 같이 노드에서 크기를 둘 다 구성합니다.

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

14.2.9. Node Tuning Operator를 사용하여 NIC 대기열 감소

Node Tuning Operator를 사용하면 성능 향상을 위해 NIC 대기열을 줄일 수 있습니다. 성능 프로필을 사용하여 조정되므로 다양한 네트워크 장치에 대한 대기열을 사용자 지정할 수 있습니다.

14.2.9.1. 성능 프로파일을 사용하여 NIC 큐 조정

성능 프로파일을 사용하면 각 네트워크 장치의 대기열 수를 조정할 수 있습니다.

지원되는 네트워크 장치는 다음과 같습니다.

  • 비가상 네트워크 장치
  • 멀티 큐(채널)를 지원하는 네트워크 장치

지원되지 않는 네트워크 장치는 다음과 같습니다.

  • Pure Software 네트워크 인터페이스
  • 블록 장치
  • Intel DPDK 가상 기능

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. cluster-admin 권한이 있는 사용자로 Node Tuning Operator를 실행하는 OpenShift Container Platform 클러스터에 로그인합니다.
  2. 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.
  3. 생성된 성능 프로파일을 편집합니다.

    $ oc edit -f <your_profile_name>.yaml
  4. spec 필드를 net 오브젝트로 채웁니다. 오브젝트 목록에는 다음 두 개의 필드가 포함될 수 있습니다.

    • userLevelNetworking은 부울 플래그로 지정된 필수 필드입니다. userLevelNetworkingtrue인 경우 지원되는 모든 장치에 대해 대기열 수가 예약된 CPU 수로 설정됩니다. 기본값은 false입니다.
    • devices는 예약된 CPU 수로 큐를 설정할 장치 목록을 지정하는 선택적 필드입니다. 장치 목록이 비어 있으면 구성이 모든 네트워크 장치에 적용됩니다. 구성은 다음과 같습니다.

      • interfacename: 이 필드는 인터페이스 이름을 지정하고, 양수 또는 음수일 수 있는 쉘 스타일 와일드카드를 지원합니다.

        • 와일드카드 구문의 예는 다음과 같습니다. <string> .*
        • 음수 규칙 앞에는 느낌표가 붙습니다. 제외된 목록이 아닌 모든 장치에 넷 큐 변경 사항을 적용하려면 !<device>를 사용합니다(예: !eno1).
      • vendorID: 접두사가 0x인 16비트 16진수로 표시되는 네트워크 장치 공급업체 ID입니다.
      • deviceID: 0x 접두사가 있는 16비트 16진수로 표시되는 네트워크 장치 ID(모델)입니다.

        참고

        deviceID가 지정되어 있는 경우 vendorID도 정의해야 합니다. 장치 항목 interfaceName, vendorID, vendorIDdeviceID의 쌍에 지정된 모든 장치 식별자와 일치하는 장치는 네트워크 장치로 간주됩니다. 그러면 이 네트워크 장치의 네트워크 대기열 수가 예약된 CPU 수로 설정됩니다.

        두 개 이상의 장치가 지정되면 네트워크 대기열 수가 해당 장치 중 하나와 일치하는 모든 네트워크 장치로 설정됩니다.

  5. 다음 예제 성능 프로필을 사용하여 대기열 수를 모든 장치에 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  6. 다음 예제 성능 프로필을 사용하여 정의된 장치 식별자와 일치하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "eth0"
        - interfaceName: "eth1"
        - vendorID: "0x1af4"
          deviceID: "0x1000"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  7. 다음 예제 성능 프로필을 사용하여 인터페이스 이름 eth로 시작하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "eth*"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  8. 이 예제 성능 프로필을 사용하여 이름이 eno1 이외의 인터페이스가 있는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "!eno1"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  9. 인터페이스 이름 eth0, 0x1af4vendorID0x1000deviceID는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다. 성능 프로파일 예는 다음과 같습니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,55-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: "eth0"
        - vendorID: "0x1af4"
          deviceID: "0x1000"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  10. 업데이트된 성능 프로필을 적용합니다.

    $ oc apply -f <your_profile_name>.yaml

추가 리소스

14.2.9.2. 대기열 상태 확인

이 섹션에서는 다양한 성능 프로필과 변경 사항이 적용되었는지 확인하는 방법에 대한 여러 예시가 있습니다.

예시 1

이 예에서 네트워크 대기열 수는 지원되는 모든 장치에 대해 예약된 CPU 수(2)로 설정됩니다.

성능 프로필의 관련 섹션은 다음과 같습니다.

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...
  • 다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.

    참고

    성능 프로필이 적용된 노드에서 이 명령을 실행합니다.

    $ ethtool -l <device>
  • 프로필을 적용하기 전에 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4

  • 프로필이 적용된 후 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 1

1
결합된 채널은 지원되는 모든 장치에 대해 예약된 CPU의 총 수가 2임을 보여줍니다. 이는 성능 프로필에 구성된 항목과 일치합니다.

예시 2

이 예에서 네트워크 대기열 수는 특정 vendorID가 있는 지원되는 모든 네트워크 장치에 대해 예약된 CPU 수(2)로 설정됩니다.

성능 프로필의 관련 섹션은 다음과 같습니다.

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...
  • 다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.

    참고

    성능 프로필이 적용된 노드에서 이 명령을 실행합니다.

    $ ethtool -l <device>
  • 프로필이 적용된 후 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 1

1
vendorID=0x1af4를 사용하는 지원되는 모든 장치에 대해 예약된 CPU의 총 수는 2입니다. 예를 들어 vendorID=0x1af4가 있는 다른 네트워크 장치 ens2가 별도로 존재하는 경우 총 네트워크 대기열 수는 2입니다. 이는 성능 프로필에 구성된 항목과 일치합니다.

예시 3

이 예에서 네트워크 대기열 수는 정의된 장치 식별자와 일치하는 지원되는 모든 네트워크 장치에 대해 예약된 CPU 수(2)로 설정됩니다.

udevadm info는 장치에 대한 자세한 보고서를 제공합니다. 이 예에서 장치는 다음과 같습니다.

# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...
# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...
  • interfaceNameeth0인 장치 및 다음 성능 프로필이 있는 vendorID=0x1af4가 있는 모든 장치에 대해 네트워크 대기열을 2로 설정합니다.

    apiVersion: performance.openshift.io/v2
    metadata:
      name: performance
    spec:
      kind: PerformanceProfile
        spec:
          cpu:
            reserved: 0-1  #total = 2
            isolated: 2-8
          net:
            userLevelNetworking: true
            devices:
            - interfaceName = eth0
            - vendorID = 0x1af4
    ...
  • 프로필이 적용된 후 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 1

    1
    vendorID=0x1af4를 사용하는 지원되는 모든 장치에 대해 예약된 CPU의 총 개수가 2로 설정됩니다. 예를 들어 vendorID=0x1af4가 있는 다른 네트워크 장치 ens2가 있는 경우 총 네트워크 대기열도 2로 설정됩니다. 마찬가지로 interfaceNameeth0인 장치에는 총 네트워크 대기열이 2로 설정됩니다.
14.2.9.3. NIC 대기열 조정과 관련된 로깅

할당된 장치를 자세히 설명하는 로그 메시지는 각 Tuned 데몬 로그에 기록됩니다. /var/log/tuned/tuned.log 파일에 다음 메시지가 기록될 수 있습니다.

  • 성공적으로 할당된 장치를 자세히 설명하는 INFO 메시지가 기록됩니다.

    INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
  • 장치를 할당할 수 없는 경우 WARNING 메시지가 기록됩니다.

    WARNING  tuned.plugins.base: instance net_test: no matching devices available

14.3. 실시간 및 짧은 대기 시간 워크로드 프로비저닝

많은 조직에서는 특히 금융 및 통신 업계에서 고성능 컴퓨팅과 낮은 예측 가능한 대기 시간이 필요합니다.

OpenShift Container Platform에서는 Node Tuning Operator에서 자동 튜닝을 구현하여 대기 시간이 짧은 성능과 OpenShift Container Platform 애플리케이션의 응답 시간을 일관되게 유지할 수 있습니다. 성능 프로필 구성을 사용하여 이러한 변경을 수행합니다. 커널을 kernel-rt로 업데이트하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하고, 사용되지 않는 CPU를 비활성화하여 전력 소비를 줄일 수 있습니다.

참고

애플리케이션을 작성할 때 RHEL for Real Time 프로세스 및 스레드에 설명된 일반적인 권장 사항을 따르십시오.

14.3.1. 실시간 기능이 있는 작업자에 짧은 대기 시간 워크로드 예약

실시간 기능을 구성하는 성능 프로필이 적용되는 작업자 노드에 대기 시간이 짧은 워크로드를 예약할 수 있습니다.

참고

특정 노드에 워크로드를 예약하려면 Pod CR(사용자 정의 리소스)의 라벨 선택기를 사용합니다. 라벨 선택기는 Node Tuning Operator에 의해 짧은 대기 시간을 위해 구성된 머신 구성 풀에 연결된 노드와 일치해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 대기 시간이 짧은 워크로드를 위해 작업자 노드를 조정하는 클러스터에 성능 프로필을 적용했습니다.

프로세스

  1. 대기 시간이 짧은 워크로드에 대한 Pod CR을 생성하고 클러스터에 적용합니다. 예를 들면 다음과 같습니다.

    실시간 처리를 사용하도록 구성된 Pod 사양의 예

    apiVersion: v1
    kind: Pod
    metadata:
      name: dynamic-low-latency-pod
      annotations:
        cpu-quota.crio.io: "disable" 1
        cpu-load-balancing.crio.io: "disable" 2
        irq-load-balancing.crio.io: "disable" 3
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: dynamic-low-latency-pod
        image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.14"
        command: ["sleep", "10h"]
        resources:
          requests:
            cpu: 2
            memory: "200M"
          limits:
            cpu: 2
            memory: "200M"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: [ALL]
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: "" 4
      runtimeClassName: performance-dynamic-low-latency-profile 5
    # ...

    1
    Pod 런타임 시 CPU를 완전히 공정 스케줄러(CFS) 할당량을 비활성화합니다.
    2
    CPU 부하 분산을 비활성화합니다.
    3
    노드에서 Pod를 중단하지 않도록 설정합니다.
    4
    nodeSelector 레이블은 Node CR에 지정한 라벨과 일치해야 합니다.
    5
    runtimeClassName 은 클러스터에 구성된 성능 프로필의 이름과 일치해야 합니다.
  2. performance-<profile_name> 형식으로 Pod runtimeClassName 을 입력합니다. 여기서 <profile_name>은 PerformanceProfile YAML의 이름입니다. 이전 예에서 이름은 performance-dynamic-low-latency-profile 입니다.
  3. Pod가 올바르게 실행되고 있는지 확인합니다. 상태가 running이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.

    $ oc get pod -o wide

    예상 출력

    NAME                     READY   STATUS    RESTARTS   AGE     IP           NODE
    dynamic-low-latency-pod  1/1     Running   0          5h33m   10.131.0.10  cnf-worker.example.com

  4. IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.

    $ oc exec -it dynamic-low-latency-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

    예상 출력

    Cpus_allowed_list:  2-3

검증

노드 구성이 올바르게 적용되었는지 확인합니다.

  1. 노드에 로그인하여 구성을 확인합니다.

    $ oc debug node/<node-name>
  2. 노드 파일 시스템을 사용할 수 있는지 확인합니다.

    sh-4.4# chroot /host

    예상 출력

    sh-4.4#

  3. 기본 시스템 CPU 선호도 마스크에 dynamic-Low-latency-pod CPU(예: CPU 2 및 3)가 포함되어 있지 않은지 확인합니다.

    sh-4.4# cat /proc/irq/default_smp_affinity

    출력 예

    33

  4. IRQ가 dynamic-low-latency-pod CPU에서 실행되도록 구성되어 있지 않은지 확인합니다.

    sh-4.4# find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    출력 예

    /proc/irq/0/smp_affinity_list: 0-5
    /proc/irq/1/smp_affinity_list: 5
    /proc/irq/2/smp_affinity_list: 0-5
    /proc/irq/3/smp_affinity_list: 0-5
    /proc/irq/4/smp_affinity_list: 0
    /proc/irq/5/smp_affinity_list: 0-5
    /proc/irq/6/smp_affinity_list: 0-5
    /proc/irq/7/smp_affinity_list: 0-5
    /proc/irq/8/smp_affinity_list: 4
    /proc/irq/9/smp_affinity_list: 4
    /proc/irq/10/smp_affinity_list: 0-5
    /proc/irq/11/smp_affinity_list: 0
    /proc/irq/12/smp_affinity_list: 1
    /proc/irq/13/smp_affinity_list: 0-5
    /proc/irq/14/smp_affinity_list: 1
    /proc/irq/15/smp_affinity_list: 0
    /proc/irq/24/smp_affinity_list: 1
    /proc/irq/25/smp_affinity_list: 1
    /proc/irq/26/smp_affinity_list: 1
    /proc/irq/27/smp_affinity_list: 5
    /proc/irq/28/smp_affinity_list: 1
    /proc/irq/29/smp_affinity_list: 0
    /proc/irq/30/smp_affinity_list: 0-5

주의

짧은 대기 시간을 위해 노드를 튜닝하면 보장된 CPU가 필요한 애플리케이션과 함께 실행 프로브를 사용하면 대기 시간이 급증할 수 있습니다. 대안으로 올바르게 구성된 네트워크 프로브 세트와 같은 다른 프로브를 사용합니다.

14.3.2. 보장된 QoS 클래스를 사용하여 Pod 생성

QoS 클래스가 Guaranteed로 지정된 Pod를 생성하는 경우 다음 사항에 유의하십시오.

  • Pod의 모든 컨테이너에는 메모리 제한과 메모리 요청이 있어야 하며 동일해야 합니다.
  • Pod의 모든 컨테이너에는 CPU 제한과 CPU 요청이 있어야 하며 동일해야 합니다.

다음 예에서는 컨테이너가 하나인 Pod의 구성 파일을 보여줍니다. 이 컨테이너에는 메모리 제한과 메모리 요청이 있으며 둘 다 200MiB입니다. 이 컨테이너에는 CPU 제한과 CPU 요청이 있으며 둘 다 CPU 1개입니다.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  securityContext:
    runAsNonRoot: true
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: [ALL]
  1. Pod를 생성합니다.

    $ oc  apply -f qos-pod.yaml --namespace=qos-example
  2. Pod에 대한 자세한 정보를 봅니다.

    $ oc get pod qos-demo --namespace=qos-example --output=yaml

    출력 예

    spec:
      containers:
        ...
    status:
      qosClass: Guaranteed

    참고

    컨테이너에 메모리 제한을 지정하고 메모리 요청을 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로 컨테이너의 CPU 제한을 지정하고 CPU 요청을 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.

14.3.3. Pod에서 CPU 로드 밸런싱 비활성화

CPU 부하 분산을 비활성화하거나 활성화하는 기능은 CRI-O 수준에서 구현됩니다. CRI-O 아래의 코드는 다음 요구사항이 충족되는 경우에만 CPU 부하 분산을 비활성화하거나 활성화합니다.

  • Pod는 performance-<profile-name> 런타임 클래스를 사용해야 합니다. 다음과 같이 성능 프로필의 상태를 보고 적절한 이름을 가져올 수 있습니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    ...
    status:
      ...
      runtimeClass: performance-manual

Node Tuning Operator는 관련 노드 아래에 고성능 런타임 처리기 구성 스니펫을 생성하고 클러스터 아래에 고성능 런타임 클래스를 생성합니다. CPU 부하 분산 구성 기능을 활성화하는 것을 제외하고는 기본 런타임 처리기와 동일한 콘텐츠가 있습니다.

Pod에 대해 CPU 부하 분산을 비활성화하려면 Pod 사양에 다음 필드가 포함되어야 합니다.

apiVersion: v1
kind: Pod
metadata:
  #...
  annotations:
    #...
    cpu-load-balancing.crio.io: "disable"
    #...
  #...
spec:
  #...
  runtimeClassName: performance-<profile_name>
  #...
참고

CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 그렇지 않은 경우 CPU 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.

14.3.4. 우선순위가 높은 Pod의 전원 저장 모드 비활성화

워크로드가 실행되는 노드에 대한 절전을 구성할 때 우선 순위가 높은 워크로드가 영향을 받지 않도록 Pod를 구성할 수 있습니다.

절전 구성으로 노드를 구성할 때 Pod 수준에서 성능 구성으로 높은 우선 순위 워크로드를 구성해야 합니다. 즉, 구성이 Pod에서 사용하는 모든 코어에 적용됩니다.

Pod 수준에서 P-state 및 C-state를 비활성화하면 최상의 성능과 짧은 대기 시간을 위해 높은 우선 순위의 워크로드를 구성할 수 있습니다.

표 14.5. 우선 순위가 높은 워크로드 구성
주석가능한 값설명

cpu-c-states.crio.io:

  • "enable"
  • "disable"
  • "max_latency:microseconds"

이 주석을 사용하면 각 CPU에 대해 C-state를 활성화하거나 비활성화할 수 있습니다. 또는 C 상태에 대해 최대 대기 시간을 microseconds로 지정할 수도 있습니다. 예를 들어 cpu-c-states.crio.io:"max_latency:10" 을 설정하여 최대 대기 시간이 10microseconds인 C-states를 활성화합니다. Pod에 최상의 성능을 제공하려면 값을 "비활성화" 로 설정합니다.

cpu-freq-governor.crio.io:

지원되는 모든 cpufreq governor.

각 CPU에 cpufreq governor를 설정합니다. 높은 우선 순위의 워크로드에는 "performance" governor를 사용하는 것이 좋습니다.

사전 요구 사항

  • 우선 순위가 높은 워크로드 Pod가 예약된 노드의 성능 프로필에 절전을 구성했습니다.

프로세스

  1. 우선순위가 높은 워크로드 Pod에 필요한 주석을 추가합니다. 주석은 기본 설정을 재정의합니다.

    우선순위가 높은 워크로드 주석의 예

    apiVersion: v1
    kind: Pod
    metadata:
      #...
      annotations:
        #...
        cpu-c-states.crio.io: "disable"
        cpu-freq-governor.crio.io: "performance"
        #...
      #...
    spec:
      #...
      runtimeClassName: performance-<profile_name>
      #...

  2. Pod를 다시 시작하여 주석을 적용합니다.

14.3.5. CPU CFS 할당량 비활성화

고정 Pod의 CPU 제한을 제거하려면 cpu-quota.crio.io: "disable" 주석이 있는 Pod를 생성합니다. 이 주석은 Pod가 실행될 때 CPU를 완전히 공정 스케줄러(CFS) 할당량을 비활성화합니다.

cpu-quota.crio.io 가 비활성화된 Pod 사양의 예

apiVersion: v1
kind: Pod
metadata:
  annotations:
      cpu-quota.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
#...

참고

CPU 관리자 정적 정책이 활성화된 경우 CPU CFS 할당량과 전체 CPU를 사용하는 보장된 QoS가 있는 Pod에만 CPU CFS 할당량을 비활성화합니다. 예를 들어 CPU 고정 컨테이너가 포함된 Pod입니다. 그렇지 않으면 CPU CFS 할당량을 비활성화하면 클러스터의 다른 컨테이너 성능에 영향을 미칠 수 있습니다.

14.3.6. 고정된 컨테이너가 실행 중인 CPU에 대한 인터럽트 처리 비활성화

워크로드의 대기 시간을 단축하기 위해 일부 컨테이너에서는 장치 인터럽트를 처리하지 않도록 고정된 CPU가 필요합니다. pod 주석 irq-load-balancing.crio.io 는 고정된 컨테이너가 실행 중인 CPU에서 장치 인터럽트가 처리되었는지 여부를 정의하는 데 사용됩니다. CRI-O를 설정하면 Pod 컨테이너가 실행 중인 장치 인터럽트를 비활성화합니다.

개별 Pod에 속하는 컨테이너가 고정된 CPU의 인터럽트 처리를 비활성화하려면 성능 프로필에서 globallyDisableIrqLoadBalancingfalse 로 설정되어 있는지 확인합니다. 그런 다음 Pod 사양에서 irq-load-balancing.crio.io Pod 주석을 비활성화하도록 설정합니다.

다음 Pod 사양에는 이 주석이 포함되어 있습니다.

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

14.4. 짧은 대기 시간 노드 튜닝 상태 디버깅

PerformanceProfile CR(사용자 정의 리소스) 상태 필드를 사용하여 튜닝 상태를 보고하고 클러스터 노드에서 대기 시간 문제를 디버깅합니다.

14.4.1. 짧은 대기 시간 CNF 튜닝 상태 디버깅

PerformanceProfile CR(사용자 정의 리소스)에는 튜닝 상태를 보고하고 대기 시간 성능 저하 문제를 디버깅하기 위한 상태 필드가 있습니다. 이러한 필드는 상태를 보고하여 Operator 조정 기능의 상태에 대해 설명합니다.

일반적으로 성능 프로필에 연결된 머신 구성 풀의 상태가 성능 저하 상태이면 PerformanceProfile이 성능 저하 상태가 되는 문제가 발생할 수 있습니다. 이 경우 머신 구성 풀에서 실패 메시지를 발행합니다.

Node Tuning Operator에는 performanceProfile.spec.status.Conditions 상태 필드가 포함되어 있습니다.

Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Status 필드에는 성능 프로필의 상태를 나타내는 Type 값을 지정하는 Conditions가 포함되어 있습니다.

Available
모든 머신 구성 및 Tuned 프로필이 성공적으로 생성되었으며 구성 요소에서 처리해야 하는 클러스터에 사용할 수 있습니다(NTO, MCO, Kubelet).
Upgradeable
Operator에서 유지보수하는 리소스가 업그레이드하기에 안전한 상태인지를 나타냅니다.
Progressing
성능 프로필의 배포 프로세스가 시작되었음을 나타냅니다.
Degraded

다음과 같은 경우 오류를 표시합니다.

  • 성능 프로필 검증에 실패했습니다.
  • 모든 관련 구성 요소 생성이 성공적으로 완료되지 않았습니다.

이러한 각 유형에는 다음 필드가 포함되어 있습니다.

상태
특정 유형의 상태(true 또는 false)입니다.
Timestamp
트랜잭션 타임스탬프입니다.
Reason string
머신에서 읽을 수 있는 이유입니다.
Message string
상태 및 오류 세부 정보(있는 경우)를 설명하는 사람이 읽을 수 있는 이유입니다.
14.4.1.1. 머신 구성 풀

성능 프로필 및 생성된 제품은 연관 MCP(머신 구성 풀)에 따라 노드에 적용됩니다. MCP에는 rt-kernel의 커널 인수, kube 구성, 대규모 페이지 할당 및 배포를 포함하는 성능 프로필로 생성된 머신 구성 적용 진행에 대한 중요한 정보가 있습니다. Performance Profile 컨트롤러는 MCP의 변경 사항을 모니터링하고 그에 따라 성능 프로필 상태를 업데이트합니다.

MCP가 성능 프로필 상태로 반환하는 유일한 조건은 MCP가 Degraded 인 경우이며, 이로 인해 performanceProfile.status.condition.Degraded = true 입니다.

예제

다음은 생성된 연관 머신 구성 풀(worker-cnf)이 있는 성능 프로필의 예입니다.

  1. 연관 머신 구성 풀이 성능 저하 상태입니다.

    # oc get mcp

    출력 예

    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

  2. MCP의 describe 섹션은 이유를 보여줍니다.

    # oc describe mcp worker-cnf

    출력 예

      Message:               Node node-worker-cnf is reporting: "prepping update:
      machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not
      found"
        Reason:                1 nodes are reporting degraded status on sync

  3. degraded = true로 표시된 성능 프로필 status 필드 아래에도 성능 저하 상태가 표시되어야 합니다.

    # oc describe performanceprofiles performance

    출력 예

    Message: Machine config pool worker-cnf Degraded Reason: 1 nodes are reporting degraded status on sync.
    Machine config pool worker-cnf Degraded Message: Node yquinn-q8s5v-w-b-z5lqn.c.openshift-gce-devel.internal is
    reporting: "prepping update: machineconfig.machineconfiguration.openshift.io
    \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found".    Reason:  MCPDegraded
       Status:  True
       Type:    Degraded

14.4.2. Red Hat 지원을 받기 위한 짧은 대기 시간 튜닝 디버깅 데이터 수집

지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.

must-gather 툴을 사용하면 노드 튜닝과 NUMA 토폴로지, 짧은 대기 시간 설정으로 인한 문제를 디버깅하는 데 필요한 다른 정보를 비롯하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 짧은 대기 시간 튜닝 둘 다에 대한 진단 정보를 제공하십시오.

14.4.2.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 다음과 같이 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터 정보를 수집합니다.

  • 리소스 정의
  • 감사 로그
  • 서비스 로그

--image 인수를 포함하여 명령을 실행하는 경우 이미지를 하나 이상 지정할 수 있습니다. 이미지를 지정하면 툴에서 해당 기능 또는 제품과 관련된 데이터를 수집합니다. oc adm must-gather를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 디렉터리에 생성됩니다.

14.4.2.2. 짧은 대기 시간 튜닝 데이터 수집

oc adm must-gather CLI 명령을 사용하여 다음과 같은 짧은 대기 시간 튜닝과 연관된 기능 및 오브젝트를 포함한 클러스터 정보를 수집합니다.

  • Node Tuning Operator 네임스페이스 및 하위 오브젝트입니다.
  • MachineConfigPool 및 연관 MachineConfig 오브젝트.
  • Node Tuning Operator 및 연관 Tuned 오브젝트.
  • Linux 커널 명령줄 옵션.
  • CPU 및 NUMA 토폴로지.
  • 기본 PCI 장치 정보 및 NUMA 위치.

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • OpenShift Container Platform CLI(oc)가 설치되어 있어야 합니다.

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. 다음 명령을 실행하여 디버깅 정보를 수집합니다.

    $ oc adm must-gather

    출력 예

    [must-gather      ] OUT Using must-gather plug-in image: quay.io/openshift-release
    When opening a support case, bugzilla, or issue please include the following summary data along with any other requested information:
    ClusterID: 829er0fa-1ad8-4e59-a46e-2644921b7eb6
    ClusterVersion: Stable at "<cluster_version>"
    ClusterOperators:
    	All healthy and stable
    
    
    [must-gather      ] OUT namespace/openshift-must-gather-8fh4x created
    [must-gather      ] OUT clusterrolebinding.rbac.authorization.k8s.io/must-gather-rhlgc created
    [must-gather-5564g] POD 2023-07-17T10:17:37.610340849Z Gathering data for ns/openshift-cluster-version...
    [must-gather-5564g] POD 2023-07-17T10:17:38.786591298Z Gathering data for ns/default...
    [must-gather-5564g] POD 2023-07-17T10:17:39.117418660Z Gathering data for ns/openshift...
    [must-gather-5564g] POD 2023-07-17T10:17:39.447592859Z Gathering data for ns/kube-system...
    [must-gather-5564g] POD 2023-07-17T10:17:39.803381143Z Gathering data for ns/openshift-etcd...
    
    ...
    
    Reprinting Cluster State:
    When opening a support case, bugzilla, or issue please include the following summary data along with any other requested information:
    ClusterID: 829er0fa-1ad8-4e59-a46e-2644921b7eb6
    ClusterVersion: Stable at "<cluster_version>"
    ClusterOperators:
    	All healthy and stable

  3. 작업 디렉터리에 생성된 must-gather 디렉터리의 압축 파일을 생성합니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

    $ tar cvaf must-gather.tar.gz must-gather-local.54213423446277122891
    1
    must-gather-local.5421342344627712289//must-gather 툴에서 생성한 디렉터리 이름으로 교체합니다.
    참고

    데이터를 지원 케이스에 첨부하거나 성능 프로파일을 생성할 때 Performance Profile Creator 래퍼 스크립트와 함께 사용할 압축 파일을 만듭니다.

  4. Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.

14.5. 플랫폼 확인을 위한 대기 시간 테스트 수행

CNF(클라우드 네이티브 네트워크 기능) 테스트 이미지를 사용하여 CNF 워크로드 실행에 필요한 모든 구성 요소가 설치된 CNF 지원 OpenShift Container Platform 클러스터에서 대기 시간 테스트를 실행할 수 있습니다. 대기 시간 테스트를 실행하여 워크로드에 대한 노드 튜닝의 유효성을 검사합니다.

cnf-tests 컨테이너 이미지는 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.14 에서 사용할 수 있습니다.

중요

cnf-tests 이미지에는 현재 Red Hat에서 지원하지 않는 여러 테스트도 포함되어 있습니다. 대기 시간 테스트만 Red Hat에서 지원됩니다.

14.5.1. 대기 시간 테스트 실행을 위한 사전 요구 사항

대기 시간 테스트를 실행하려면 클러스터가 다음 요구 사항을 충족해야 합니다.

  1. Node Tuning Operator를 사용하여 성능 프로필을 구성했습니다.
  2. 클러스터에서 필요한 모든 CNF 구성을 적용했습니다.
  3. 클러스터에 기존 MachineConfigPool CR이 적용되어 있습니다. 기본 작업자 풀은 worker-cnf 입니다.

14.5.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.5.3. 대기 시간 측정

cnf-tests 이미지는 세 가지 툴을 사용하여 시스템의 대기 시간을 측정합니다.

  • hwlatdetect
  • cyclictest
  • oslat

각 툴에는 특정 용도가 있습니다. 안정적인 테스트 결과를 얻으려면 도구를 순서대로 사용하십시오.

hwlatdetect
베어 메탈 하드웨어에서 수행할 수 있는 기준을 측정합니다. 다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고한 대기 시간이 운영 체제 튜닝을 통해 하드웨어 대기 시간 급증을 수정할 수 없기 때문에 필요한 임계값을 충족하는지 확인합니다.
cyclictest
hwlatdetect 가 검증을 통과한 후 실시간 커널 스케줄러 대기 시간을 확인합니다. cyclictest 툴은 반복된 타이머를 스케줄링하고 원하는 트리거 시간과 실제 트리거 시간 간의 차이를 측정합니다. 차이점은 인터럽트 또는 프로세스 우선순위로 인한 튜닝의 기본 문제를 찾을 수 있습니다. 툴은 실시간 커널에서 실행해야 합니다.
oslat
CPU 집약적인 DPDK 애플리케이션과 유사하게 작동하며 CPU 과도한 데이터 처리를 시뮬레이션하는 사용량이 많은 루프에 대한 모든 중단 및 중단을 측정합니다.

테스트에서는 다음과 같은 환경 변수를 도입합니다.

표 14.6. 대기 시간 테스트 환경 변수
환경 변수설명

LATENCY_TEST_DELAY

테스트 실행을 시작한 후 시간(초)을 지정합니다. 변수를 사용하여 CPU 관리자 조정 루프가 기본 CPU 풀을 업데이트할 수 있도록 허용할 수 있습니다. 기본값은 0입니다.

LATENCY_TEST_CPUS

대기 시간 테스트를 실행하는 Pod에서 사용하는 CPU 수를 지정합니다. 변수를 설정하지 않으면 기본 구성에 모든 분리된 CPU가 포함됩니다.

LATENCY_TEST_RUNTIME

대기 시간 테스트를 실행해야 하는 시간(초)을 지정합니다. 기본값은 300초입니다.

참고

대기 시간 테스트가 완료되기 전에 Ginkgo 2.0 테스트 모음이 시간 초과되지 않도록 하려면 -ginkgo.timeout 플래그를 LATENCY_TEST_RUNTIME + 2분보다 큰 값으로 설정합니다. 또한 LATENCY_TEST_DELAY 값을 설정하는 경우 -ginkgo.timeoutLATENCY_TEST_RUNTIME + LATENCY_TEST_DELAY + 2분보다 큰 값으로 설정해야 합니다. Ginkgo 2.0 테스트 모음의 기본 시간 초과 값은 1시간입니다.

HWLATDETECT_MAXIMUM_LATENCY

워크로드 및 운영 체제에 대해 마이크로초 단위로 허용되는 최대 하드웨어 대기 시간을 지정합니다. HWLATDETECT_MAXIMUM_LATENCY 또는 MAXIMUM_LATENCY 값을 설정하지 않으면 툴 자체에서 기본 예상 임계값(20 Cryostat)과 실제 최대 대기 시간을 비교합니다. 그런 다음 테스트가 실패하거나 그에 따라 성공합니다.

CYCLICTEST_MAXIMUM_LATENCY

cyclictest 실행 중에 발생하는 모든 스레드가 예상하는 최대 대기 시간을 지정합니다. CYCLICTEST_MAXIMUM_LATENCY 또는 MAXIMUM_LATENCY 의 값을 설정하지 않으면 이 툴은 예상 값과 실제 최대 대기 시간의 비교를 건너뜁니다.

OSLAT_MAXIMUM_LATENCY

oslat 테스트 결과에 대해 마이크로초 단위로 허용되는 최대 대기 시간을 지정합니다. OSLAT_MAXIMUM_LATENCY 또는 MAXIMUM_LATENCY 값을 설정하지 않으면 이 툴은 예상 값과 실제 최대 대기 시간의 비교를 건너뜁니다.

MAXIMUM_LATENCY

마이크로초 단위로 허용되는 최대 대기 시간을 지정하는 통합 변수입니다. 사용 가능한 모든 대기 시간 툴에 적용됩니다.

LATENCY_TEST_RUN

테스트를 실행할지 여부를 나타내는 부울 매개 변수입니다. LATENCY_TEST_RUN 은 기본적으로 false 로 설정됩니다. 대기 시간 테스트를 실행하려면 이 값을 true 로 설정합니다.

참고

대기 시간 툴과 관련된 변수가 통합 변수보다 우선합니다. 예를 들어 OSLAT_MAXIMUM_LATENCY 가 30 마이크로초로 설정되고 MAXIMUM_LATENCY 가 10 마이크로초로 설정된 경우 oslat 테스트는 최대 허용 가능한 대기 시간으로 30 마이크로초의 최대 허용 대기 시간으로 실행됩니다.

14.5.4. 대기 시간 테스트 실행

클러스터 대기 시간 테스트를 실행하여 CNF(클라우드 네이티브 네트워크 기능) 워크로드에 대한 노드 튜닝을 검증합니다.

중요

DISCOVERY_MODE=true 세트를 사용하여 항상 대기 시간 테스트를 실행합니다. 그렇지 않으면 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

root가 아니거나 권한이 없는 사용자로 podman 명령을 실행하는 경우 마운트 경로가 권한 거부 오류로 인해 실패할 수 있습니다. podman 명령이 작동하도록 하려면 볼륨 생성에 :Z 를 추가합니다(예: -v $(pwd)/:/kubeconfig:Z. 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

프로세스

  1. kubeconfig 파일이 포함된 디렉터리에서 쉘 프롬프트를 엽니다.

    현재 디렉터리에 kubeconfig 파일과 볼륨을 통해 마운트된 관련 $KUBECONFIG 환경 변수가 테스트 이미지를 제공합니다. 이렇게 하면 실행 중인 컨테이너에서 컨테이너 내부에서 kubeconfig 파일을 사용할 수 있습니다.

  2. 다음 명령을 입력하여 대기 시간 테스트를 실행합니다.

    $ 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.14 \
    /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test" --ginkgo.timeout="24h"
  3. 선택 사항: Append -ginkgo.dryRun 을 실행하여 시험 실행 모드에서 대기 시간 테스트를 실행합니다. 이 기능은 테스트 실행 상태를 확인하는 데 유용합니다.
  4. 선택 사항: Append -ginkgo.v 가 증가된 상세 정보 표시로 테스트를 실행합니다.
  5. 선택 사항: 특정 성능 프로필에 대해 대기 시간 테스트를 실행하려면 다음 명령을 실행하여 적절한 값을 대체합니다.

    $ 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.14 \
    /usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

    다음과 같습니다.

    <performance_profile>
    대기 시간 테스트를 실행할 성능 프로필의 이름입니다.
  6. 선택 사항: 대기 시간 테스트가 완료되기 전에 Ginkgo 2.0 테스트 모음이 시간 초과되지 않도록 하려면 Append --ginkgo.timeout="24h" 플래그가 있습니다.

    중요

    유효한 대기 시간 테스트 결과의 경우 최소 12시간 동안 테스트를 실행합니다.

14.5.4.1. hwlatdetect 실행

hwlatdetect 툴은 RHEL(Red Hat Enterprise Linux) 9.x의 일반 서브스크립션과 함께 rt-kernel 패키지에서 사용할 수 있습니다.

중요

DISCOVERY_MODE=true 세트를 사용하여 항상 대기 시간 테스트를 실행합니다. 그렇지 않으면 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

root가 아니거나 권한이 없는 사용자로 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.14 \
    /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect" --ginkgo.timeout="24h"

    hwlatdetect 테스트는 10분(600초) 동안 실행됩니다. 관찰된 최대 대기 시간이 MAXIMUM_LATENCY (20 Cryostat)보다 작으면 테스트가 성공적으로 실행됩니다.

    결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

    중요

    유효한 결과를 위해 테스트는 최소 12시간 동안 실행되어야 합니다.

    실패 출력 예

    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect
    I0908 15:25:20.023712      27 request.go:601] Waited for 1.046586367s due to client-side throttling, not priority and fairness, request: GET:https://api.hlxcl6.lab.eng.tlv2.redhat.com:6443/apis/imageregistry.operator.openshift.io/v1?timeout=32s
    Running Suite: CNF Features e2e integration tests
    =================================================
    Random Seed: 1662650718
    Will run 1 of 194 specs
    
    [...]
    
    • Failure [283.574 seconds]
    [performance] Latency Test
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
      with the hwlatdetect image
      /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:228
        should succeed [It]
        /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:236
    
        Log file created at: 2022/09/08 15:25:27
        Running on machine: hwlatdetect-b6n4n
        Binary: Built with gc go1.17.12 for linux/amd64
        Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
        I0908 15:25:27.160620       1 node.go:39] Environment information: /proc/cmdline: BOOT_IMAGE=(hd1,gpt3)/ostree/rhcos-c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/vmlinuz-4.18.0-372.19.1.el8_6.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=metal ostree=/ostree/boot.1/rhcos/c6491e1eedf6c1f12ef7b95e14ee720bf48359750ac900b7863c625769ef5fb9/0 ip=dhcp root=UUID=5f80c283-f6e6-4a27-9b47-a287157483b2 rw rootflags=prjquota boot=UUID=773bf59a-bafd-48fc-9a87-f62252d739d3 skew_tick=1 nohz=on rcu_nocbs=0-3 tuned.non_isolcpus=0000ffff,ffffffff,fffffff0 systemd.cpu_affinity=4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79 intel_iommu=on iommu=pt isolcpus=managed_irq,0-3 nohz_full=0-3 tsc=nowatchdog nosoftlockup nmi_watchdog=0 mce=off skew_tick=1 rcutree.kthread_prio=11 + +
        I0908 15:25:27.160830       1 node.go:46] Environment information: kernel version 4.18.0-372.19.1.el8_6.x86_64
        I0908 15:25:27.160857       1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 100 --window 10000000us --width 950000us]
        F0908 15:27:10.603523       1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect:  test duration 100 seconds
           detector: tracer
           parameters:
                Latency threshold: 1us 1
                Sample window:     10000000us
                Sample width:      950000us
             Non-sampling period:  9050000us
                Output File:       None
    
        Starting test
        test finished
        Max Latency: 326us 2
        Samples recorded: 5
        Samples exceeding threshold: 5
        ts: 1662650739.017274507, inner:6, outer:6
        ts: 1662650749.257272414, inner:14, outer:326
        ts: 1662650779.977272835, inner:314, outer:12
        ts: 1662650800.457272384, inner:3, outer:9
        ts: 1662650810.697273520, inner:3, outer:2
    
    [...]
    
    JUnit report was created: /junit.xml/cnftests-junit.xml
    
    
    Summarizing 1 Failure:
    
    [Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:476
    
    Ran 1 of 194 Specs in 365.797 seconds
    FAIL! -- 0 Passed | 1 Failed | 0 Pending | 193 Skipped
    --- FAIL: TestTest (366.08s)
    FAIL

    1
    MAXIMUM_LATENCY 또는 HWLATDETECT_MAXIMUM_LATENCY 환경 변수를 사용하여 대기 시간 임계값을 구성할 수 있습니다.
    2
    테스트 중에 측정된 최대 대기 시간 값입니다.
hwlatdetect 테스트 결과 예

다음 유형의 결과를 캡처할 수 있습니다.

  • 테스트 전체에서 수행된 변경 사항에 영향을 미치는 기록을 생성하기 위해 각 실행 후에 수집된 대략적인 결과.
  • 최상의 결과 및 구성 설정과 함께 대략적인 테스트 세트입니다.

좋은 결과의 예

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

hwlatdetect 툴은 샘플이 지정된 임계값을 초과하는 경우에만 출력을 제공합니다.

잘못된 결과의 예

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

hwlatdetect 의 출력은 여러 샘플이 임계값을 초과했음을 보여줍니다. 그러나 동일한 출력은 다음 요인에 따라 다른 결과를 나타낼 수 있습니다.

  • 테스트 기간
  • CPU 코어 수
  • 호스트 펌웨어 설정
주의

다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고한 대기 시간이 필요한 임계값을 충족하는지 확인합니다. 하드웨어에 의해 도입된 대기 시간을 수정하려면 시스템 벤더 지원에 문의해야 할 수 있습니다.

모든 대기 시간 급증이 하드웨어와 관련된 것은 아닙니다. 워크로드 요구 사항을 충족하도록 호스트 펌웨어를 조정해야 합니다. 자세한 내용은 시스템 튜닝의 펌웨어 매개변수 설정을 참조하십시오.

14.5.4.2. cyclictest 실행

cyclictest 툴은 지정된 CPU에서 실시간 커널 스케줄러 대기 시간을 측정합니다.

중요

DISCOVERY_MODE=true 세트를 사용하여 항상 대기 시간 테스트를 실행합니다. 그렇지 않으면 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

root가 아니거나 권한이 없는 사용자로 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.14 \
    /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest" --ginkgo.timeout="24h"

    명령은 10분(600초) 동안 cyclictest 툴을 실행합니다. 관찰된 최대 대기 시간이 MAXIMUM_LATENCY 보다 작으면 테스트가 성공적으로 실행됩니다(이 예에서는 20 Cryostat). 20 Cryostat 이상으로 급증하는 대기 시간은 일반적으로 telco RAN 워크로드에는 허용되지 않습니다.

    결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

    중요

    유효한 결과를 위해 테스트는 최소 12시간 동안 실행되어야 합니다.

    실패 출력 예

    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=cyclictest
    I0908 13:01:59.193776      27 request.go:601] Waited for 1.046228824s due to client-side throttling, not priority and fairness, request: GET:https://api.compute-1.example.com:6443/apis/packages.operators.coreos.com/v1?timeout=32s
    Running Suite: CNF Features e2e integration tests
    =================================================
    Random Seed: 1662642118
    Will run 1 of 194 specs
    
    [...]
    
    Summarizing 1 Failure:
    
    [Fail] [performance] Latency Test with the cyclictest image [It] should succeed
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:220
    
    Ran 1 of 194 Specs in 161.151 seconds
    FAIL! -- 0 Passed | 1 Failed | 0 Pending | 193 Skipped
    --- FAIL: TestTest (161.48s)
    FAIL

cyclictest 결과 예

동일한 출력은 워크로드마다 다른 결과를 나타낼 수 있습니다. 예를 들어 4G DU 워크로드에는 최대 18 Cryostats의 급증이 허용되지만 5G DU 워크로드에서는 허용되지 않습니다.

좋은 결과의 예

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

잘못된 결과의 예

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

14.5.4.3. oslat 실행

oslat 테스트는 CPU 집약적인 DPDK 애플리케이션을 시뮬레이션하고 모든 중단 및 중단을 측정하여 클러스터가 CPU 과도한 데이터 처리를 처리하는 방법을 테스트합니다.

중요

DISCOVERY_MODE=true 세트를 사용하여 항상 대기 시간 테스트를 실행합니다. 그렇지 않으면 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

root가 아니거나 권한이 없는 사용자로 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.14 \
    /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat" --ginkgo.timeout="24h"

    LATENCY_TEST_CPUSoslat 명령으로 테스트할 CPU 목록을 지정합니다.

    명령은 10분(600초) 동안 oslat 툴을 실행합니다. 관찰된 최대 대기 시간이 MAXIMUM_LATENCY (20 Cryostat)보다 작으면 테스트가 성공적으로 실행됩니다.

    결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

    중요

    유효한 결과를 위해 테스트는 최소 12시간 동안 실행되어야 합니다.

    실패 출력 예

    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=oslat
    I0908 12:51:55.999393      27 request.go:601] Waited for 1.044848101s due to client-side throttling, not priority and fairness, request: GET:https://compute-1.example.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s
    Running Suite: CNF Features e2e integration tests
    =================================================
    Random Seed: 1662641514
    Will run 1 of 194 specs
    
    [...]
    
    • Failure [77.833 seconds]
    [performance] Latency Test
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:62
      with the oslat image
      /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:128
        should succeed [It]
        /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:153
    
        The current latency 304 is bigger than the expected one 1 : 1
    
    [...]
    
    Summarizing 1 Failure:
    
    [Fail] [performance] Latency Test with the oslat image [It] should succeed
    /remote-source/app/vendor/github.com/openshift/cluster-node-tuning-operator/test/e2e/performanceprofile/functests/4_latency/latency.go:177
    
    Ran 1 of 194 Specs in 161.091 seconds
    FAIL! -- 0 Passed | 1 Failed | 0 Pending | 193 Skipped
    --- FAIL: TestTest (161.42s)
    FAIL

    1
    이 예에서 측정된 대기 시간은 허용되는 최대값을 벗어납니다.

14.5.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.14 \
    /usr/bin/test-run.sh --report <report_folder_path> \
    -ginkgo.focus="\[performance\]\ Latency\ Test"

    다음과 같습니다.

    <report_folder_path>
    보고서가 생성되는 폴더의 경로입니다.Is the path to the folder where the report is generated.

14.5.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.14 \
    /usr/bin/test-run.sh --junit <junit_folder_path> \
    -ginkgo.focus="\[performance\]\ Latency\ Test"

    다음과 같습니다.

    <junit_folder_path>
    junit 보고서가 생성되는 폴더의 경로입니다.

14.5.7. 단일 노드 OpenShift 클러스터에서 대기 시간 테스트 실행

단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행할 수 있습니다.

중요

DISCOVERY_MODE=true 세트를 사용하여 항상 대기 시간 테스트를 실행합니다. 그렇지 않으면 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

root가 아니거나 권한이 없는 사용자로 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.14 \
    /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test" --ginkgo.timeout="24h"
    참고

    master가 노드가 속한 유일한 시스템 풀이므로 ROLE_WORKER_CNF=master 가 필요합니다. 대기 시간 테스트에 필요한 MachineConfigPool 설정에 대한 자세한 내용은 "대기 시간 테스트를 실행하는 사전 요구 사항"을 참조하십시오.

    테스트 모음을 실행한 후에는 모든 무위 리소스가 정리됩니다.

14.5.8. 연결이 끊긴 클러스터에서 대기 시간 테스트 실행

CNF 테스트 이미지는 외부 레지스트리에 연결할 수 없는 연결이 끊긴 클러스터에서 테스트를 실행할 수 있습니다. 여기에는 다음 두 단계가 필요합니다.

  1. cnf-tests 이미지를 사용자 정의 연결이 끊긴 레지스트리에 미러링합니다.
  2. 사용자 정의 연결이 끊긴 레지스트리의 이미지를 사용하도록 테스트에 지시합니다.
클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링

oc 에서 테스트 이미지를 로컬 레지스트리에 미러링 하는 데 필요한 입력을 제공하기 위해 이미지에 미러 실행 파일이 제공됩니다.

  1. 클러스터 및 registry.redhat.io 에 액세스할 수 있는 중간 머신에서 이 명령을 실행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.14 \
    /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

    다음과 같습니다.

    <disconnected_registry>
    구성한 연결이 끊긴 미러 레지스트리입니다(예: my.local.registry:5000/ ).
  2. 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.14" \
    /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test" --ginkgo.timeout="24h"
사용자 정의 레지스트리의 이미지를 사용하도록 테스트 구성

CNF_TESTS_IMAGEIMAGE_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.14 /usr/bin/test-run.sh --ginkgo.timeout="24h"

    다음과 같습니다.

    <custom_image_registry>
    사용자 지정 이미지 레지스트리입니다(예: custom.registry:5000/ ).
    <custom_cnf-tests_image>
    사용자 지정 cnf-tests 이미지입니다(예: custom-cnf-tests-image:latest ).
클러스터 OpenShift 이미지 레지스트리에 이미지 미러링

OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 내장 컨테이너 이미지 레지스트리를 제공합니다.

프로세스

  1. 경로를 통해 레지스트리를 공개하여 레지스트리에 대한 외부 액세스 권한을 얻습니다.

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. 다음 명령을 실행하여 레지스트리 끝점을 가져옵니다.

    $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
  3. 이미지를 공개하는 데 사용할 네임스페이스를 생성합니다.

    $ oc create ns cnftests
  4. 테스트에 사용되는 모든 네임스페이스에서 이미지 스트림을 사용할 수 있도록 합니다. 테스트 네임스페이스가 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:performance-addon-operators-testing:default --namespace=cnftests
  5. 다음 명령을 실행하여 Docker 보안 이름 및 인증 토큰을 검색합니다.

    $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
    $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')
  6. dockerauth.json 파일을 생성합니다. 예를 들면 다음과 같습니다.

    $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json
  7. 이미지 미러링을 수행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:4.14 \
    /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
    -a=$(pwd)/dockerauth.json -f -
  8. 테스트를 실행합니다.

    $ 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" --ginkgo.timeout="24h"
다른 테스트 이미지 세트 미러링

필요한 경우 대기 시간 테스트에 미러링된 기본 업스트림 이미지를 변경할 수 있습니다.

프로세스

  1. mirror 명령은 기본적으로 업스트림 이미지를 미러링하려고 합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다.

    [
        {
            "registry": "public.registry.io:5000",
            "image": "imageforcnftests:4.14"
        }
    ]
  2. 파일을 mirror 명령에 전달합니다. 예를 들어 images.json 으로 로컬로 저장하십시오. 다음 명령을 사용하면 로컬 경로가 컨테이너 내 /kubeconfig에 마운트되어 mirror 명령에 전달될 수 있습니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.14 /usr/bin/mirror \
    --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
    |  oc image mirror -f -

14.5.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.14 \
    oc get nodes

    이 명령이 작동하지 않으면 DNS, MTU 크기 또는 방화벽 액세스 전반에 걸쳐 발생하는 오류가 발생할 수 있습니다.

15장. 작업자 대기 시간 프로필을 사용하여 대기 시간이 많은 환경에서 클러스터 안정성 개선

클러스터 관리자가 플랫폼 확인을 위해 대기 시간 테스트를 수행한 경우 대기 시간이 긴 경우 안정성을 보장하기 위해 클러스터의 작동을 조정해야 할 수 있습니다. 클러스터 관리자는 파일에 기록된 하나의 매개 변수만 변경해야 합니다. 이 매개변수는 감독자 프로세스가 상태를 읽고 클러스터의 상태를 해석하는 방법에 영향을 미치는 매개변수 4개를 제어합니다. 하나의 매개변수만 변경하면 지원 가능한 방식으로 클러스터 튜닝이 제공됩니다.

Kubelet 프로세스는 클러스터 상태를 모니터링하기 위한 시작점을 제공합니다. Kubelet 은 OpenShift Container Platform 클러스터의 모든 노드에 대한 상태 값을 설정합니다. Kubernetes Controller Manager(kube 컨트롤러)는 기본적으로 10초마다 상태 값을 읽습니다. kube 컨트롤러에서 노드 상태 값을 읽을 수 없는 경우 구성된 기간이 지난 후 해당 노드와의 연결이 끊어집니다. 기본 동작은 다음과 같습니다.

  1. 컨트롤 플레인의 노드 컨트롤러는 노드 상태를 Unhealthy 로 업데이트하고 노드 Ready 조건 'Unknown'을 표시합니다.
  2. 스케줄러는 이에 대한 응답으로 해당 노드에 대한 Pod 예약을 중지합니다.
  3. 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-secondsdefault-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-secondsdefault-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-secondsdefault-unreachable-toleration-seconds 설정)가 제거됩니다.

프로필Component매개변수현재의

Default

kubelet

node-status-update-frequency

10s

kubelet Controller Manager

node-monitor-grace-period

40s

Kubernetes API Server Operator

default-not-ready-toleration-seconds

300s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

300s

중간 규모의 작업자 대기 시간 프로파일

네트워크 대기 시간이 평상시보다 약간 높은 경우 MediumUpdateAverageReaction 프로필을 사용합니다.

MediumUpdateAverageReaction 프로필은 kubelet 업데이트 빈도를 20초로 줄이고 Kubernetes 컨트롤러 관리자가 해당 업데이트를 2분으로 기다리는 기간을 변경합니다. 해당 노드의 Pod 제거 기간은 60초로 단축됩니다. Pod에 tolerationSeconds 매개변수가 있는 경우 제거는 해당 매개변수에서 지정한 기간 동안 대기합니다.

Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 2분 정도 기다립니다. 다른 분 후에 제거 프로세스가 시작됩니다.

프로필Component매개변수현재의

MediumUpdateAverageReaction

kubelet

node-status-update-frequency

20s

kubelet Controller Manager

node-monitor-grace-period

2m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

작업자 대기 시간이 짧은 프로필

네트워크 대기 시간이 매우 높은 경우 LowUpdateSlowReaction 프로필을 사용합니다.

LowUpdateSlowReaction 프로필은 kubelet 업데이트 빈도를 1분으로 줄이고 Kubernetes 컨트롤러 관리자가 해당 업데이트를 5분으로 기다리는 기간을 변경합니다. 해당 노드의 Pod 제거 기간은 60초로 단축됩니다. Pod에 tolerationSeconds 매개변수가 있는 경우 제거는 해당 매개변수에서 지정한 기간 동안 대기합니다.

Kubernetes 컨트롤러 관리자는 노드의 비정상적인 것으로 간주하기 위해 5분 정도 기다립니다. 다른 분 후에 제거 프로세스가 시작됩니다.

프로필Component매개변수현재의

LowUpdateSlowReaction

kubelet

node-status-update-frequency

1m

kubelet Controller Manager

node-monitor-grace-period

5m

Kubernetes API Server Operator

default-not-ready-toleration-seconds

60s

Kubernetes API Server Operator

default-unreachable-toleration-seconds

60s

15.2. 클러스터 생성 시 작업자 대기 시간 프로필 구현

중요

설치 프로그램의 구성을 편집하려면 먼저 openshift-install create manifests 명령을 사용하여 기본 노드 매니페스트 및 기타 매니페스트 YAML 파일을 생성해야 합니다. 이 파일 구조는 workerLatencyProfile을 추가하기 전에 존재해야 합니다. 설치 중인 플랫폼에는 다양한 요구 사항이 있을 수 있습니다. 특정 플랫폼에 대한 설명서의 설치 섹션을 참조하십시오.

workerLatencyProfile 은 다음 순서로 매니페스트에 추가해야 합니다.

  1. 설치에 적합한 폴더 이름을 사용하여 클러스터를 빌드하는 데 필요한 매니페스트를 생성합니다.
  2. YAML 파일을 생성하여 config.node 를 정의합니다. 파일은 manifests 디렉터리에 있어야 합니다.
  3. 매니페스트에 workerLatencyProfile 을 처음 정의할 때 클러스터 생성 시 기본,mediumUpdateAverageReaction 또는 LowUpdateSlowReaction.

검증

  • 다음은 매니페스트 파일의 spec.workerLatencyProfile Default 값을 보여주는 매니페스트 생성 예제입니다.

    $ openshift-install create manifests --dir=<cluster-install-dir>
  • 매니페스트를 편집하고 값을 추가합니다. 이 예제에서는 vi 를 사용하여 "Default" workerLatencyProfile 값이 추가된 매니페스트 파일 예제를 표시합니다.

    $ vi <cluster-install-dir>/manifests/config-node-default-profile.yaml

    출력 예

    apiVersion: config.openshift.io/v1
    kind: Node
    metadata:
    name: cluster
    spec:
    workerLatencyProfile: "Default"

15.3. 작업자 대기 시간 프로필 사용 및 변경

네트워크 대기 시간을 처리하기 위해 작업자 대기 시간 프로필을 변경하려면 node.config 오브젝트를 편집하여 프로필 이름을 추가합니다. 대기 시간이 증가하거나 감소하면 언제든지 프로필을 변경할 수 있습니다.

한 번에 하나의 작업자 대기 시간 프로필을 이동해야 합니다. 예를 들어 Default 프로필에서 LowUpdateSlowReaction 작업자 대기 시간 프로파일로 직접 이동할 수 없습니다. 기본 작업자 대기 시간 프로필에서 먼저 MediumUpdateAverageReaction 프로필로 이동한 다음 LowUpdateSlowReaction 으로 이동해야 합니다. 마찬가지로 Default 프로필로 돌아갈 때 먼저 low 프로필에서 medium 프로필로 이동한 다음 Default 로 이동해야 합니다.

참고

OpenShift Container Platform 클러스터를 설치할 때 작업자 대기 시간 프로필을 구성할 수도 있습니다.

프로세스

기본 작업자 대기 시간 프로필에서 이동하려면 다음을 수행합니다.

  1. 중간 작업자 대기 시간 프로필로 이동합니다.

    1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster
    2. spec.workerLatencyProfile: MediumUpdateAverageReaction:

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: MediumUpdateAverageReaction 1
      
      # ...

      1
      중간 작업자 대기 시간을 지정합니다.

      변경 사항이 적용되므로 각 작업자 노드의 예약이 비활성화됩니다.

  2. 선택 사항: 낮은 작업자 대기 시간 프로필로 이동합니다.

    1. node.config 오브젝트를 편집합니다.

      $ oc edit nodes.config/cluster
    2. spec.workerLatencyProfile 값을 LowUpdateSlowReaction:으로 변경합니다.

      node.config 오브젝트의 예

      apiVersion: config.openshift.io/v1
      kind: Node
      metadata:
        annotations:
          include.release.openshift.io/ibm-cloud-managed: "true"
          include.release.openshift.io/self-managed-high-availability: "true"
          include.release.openshift.io/single-node-developer: "true"
          release.openshift.io/create-only: "true"
        creationTimestamp: "2022-07-08T16:02:51Z"
        generation: 1
        name: cluster
        ownerReferences:
        - apiVersion: config.openshift.io/v1
          kind: ClusterVersion
          name: version
          uid: 36282574-bf9f-409e-a6cd-3032939293eb
        resourceVersion: "1865"
        uid: 0c0f7a4c-4307-4187-b591-6155695ac85b
      spec:
        workerLatencyProfile: LowUpdateSlowReaction 1
      
      # ...

      1
      낮은 작업자 대기 시간 정책 사용을 지정합니다.

변경 사항이 적용되므로 각 작업자 노드의 예약이 비활성화됩니다.

검증

  • 모든 노드가 Ready 조건으로 돌아가면 다음 명령을 사용하여 Kubernetes 컨트롤러 관리자를 확인하여 적용되었는지 확인할 수 있습니다.

    $ oc get KubeControllerManager -o yaml | grep -i workerlatency -A 5 -B 5

    출력 예

    # ...
        - lastTransitionTime: "2022-07-11T19:47:10Z"
          reason: ProfileUpdated
          status: "False"
          type: WorkerLatencyProfileProgressing
        - lastTransitionTime: "2022-07-11T19:47:10Z" 1
          message: all static pod revision(s) have updated latency profile
          reason: ProfileUpdated
          status: "True"
          type: WorkerLatencyProfileComplete
        - lastTransitionTime: "2022-07-11T19:20:11Z"
          reason: AsExpected
          status: "False"
          type: WorkerLatencyProfileDegraded
        - lastTransitionTime: "2022-07-11T19:20:36Z"
          status: "False"
    # ...

    1
    프로필이 적용되고 활성화되도록 지정합니다.

미디어 프로필을 기본값으로 변경하거나 기본값을 medium로 변경하려면 node.config 오브젝트를 편집하고 spec.workerLatencyProfile 매개변수를 적절한 값으로 설정합니다.

15.4. workerLatencyProfile의 결과 값을 표시하는 단계의 예

다음 명령을 사용하여 workerLatencyProfile 의 값을 표시할 수 있습니다.

검증

  1. Kube API Server에서 default-not-ready-toleration-secondsdefault-unreachable-toleration-seconds 필드 출력을 확인합니다.

    $ oc get KubeAPIServer -o yaml | grep -A 1 default-

    출력 예

    default-not-ready-toleration-seconds:
    - "300"
    default-unreachable-toleration-seconds:
    - "300"

  2. Kube Controller Manager에서 node-monitor-grace-period 필드의 값을 확인합니다.

    $ oc get KubeControllerManager -o yaml | grep -A 1 node-monitor

    출력 예

    node-monitor-grace-period:
    - 40s

  3. Kubelet에서 nodeStatusUpdateFrequency 값을 확인합니다. 디버그 쉘 내에서 /host 디렉터리를 root 디렉터리로 설정합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

    $ oc debug node/<worker-node-name>
    $ chroot /host
    # cat /etc/kubernetes/kubelet.conf|grep nodeStatusUpdateFrequency

    출력 예

      “nodeStatusUpdateFrequency”: “10s”

이러한 출력은 Worker Latency Profile의 타이밍 변수 집합의 유효성을 검사합니다.

16장. 워크로드 파티셔닝

리소스가 제한적인 환경에서는 워크로드 파티셔닝을 사용하여 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 분리하여 예약된 CPU 세트에서 실행할 수 있습니다.

클러스터 관리에 필요한 최소 예약된 CPU 수는 4개의 CPU Hyper-Threads(HT)입니다. 워크로드 파티셔닝을 사용하면 클러스터 관리 워크로드 파티션에 포함할 수 있도록 클러스터 관리 Pod 세트와 일반적인 추가 기능 Operator 세트에 주석을 답니다. 이러한 Pod는 최소 크기 CPU 구성 내에서 정상적으로 작동합니다. 최소 클러스터 관리 Pod 세트 이외의 추가 Operator 또는 워크로드에는 워크로드 파티션에 추가 CPU를 추가해야 합니다.

워크로드 파티셔닝은 표준 Kubernetes 스케줄링 기능을 사용하여 플랫폼 워크로드에서 사용자 워크로드를 분리합니다.

워크로드 파티셔닝에는 다음과 같은 변경이 필요합니다.

  1. install-config.yaml 파일에서 추가 필드: cpu CryostatingMode 를 추가합니다.

    apiVersion: v1
    baseDomain: devcluster.openshift.com
    cpuPartitioningMode: AllNodes 1
    compute:
      - architecture: amd64
        hyperthreading: Enabled
        name: worker
        platform: {}
        replicas: 3
    controlPlane:
      architecture: amd64
      hyperthreading: Enabled
      name: master
      platform: {}
      replicas: 3
    1
    설치 시 CPU 파티셔닝을 위한 클러스터를 설정합니다. 기본값은 None 입니다.
    참고

    워크로드 파티셔닝은 클러스터 설치 중에만 활성화할 수 있습니다. 워크로드 파티션 설치 후 비활성화할 수 없습니다.

  2. 성능 프로필에서 분리된 CPU와 예약된 CPU를 지정합니다.

    권장되는 성능 프로파일 구성

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
      # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
      # Also in file 'validatorCRs/informDuValidator.yaml':
      # name: 50-performance-${PerformanceProfile.metadata.name}
      name: openshift-node-performance-profile
      annotations:
        ran.openshift.io/reference-configuration: "ran-du.redhat.com"
    spec:
      additionalKernelArgs:
        - "rcupdate.rcu_normal_after_boot=0"
        - "efi=runtime"
        - "vfio_pci.enable_sriov=1"
        - "vfio_pci.disable_idle_d3=1"
        - "module_blacklist=irdma"
      cpu:
        isolated: $isolated
        reserved: $reserved
      hugepages:
        defaultHugepagesSize: $defaultHugepagesSize
        pages:
          - size: $size
            count: $count
            node: $node
      machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/$mcp: ""
      nodeSelector:
        node-role.kubernetes.io/$mcp: ""
      numa:
        topologyPolicy: "restricted"
      # To use the standard (non-realtime) kernel, set enabled to false
      realTimeKernel:
        enabled: true
      workloadHints:
        # WorkloadHints defines the set of upper level flags for different type of workloads.
        # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
        # for detailed descriptions of each item.
        # The configuration below is set for a low latency, performance mode.
        realTime: true
        highPowerConsumption: false
        perPodPowerManagement: false

    표 16.1. 단일 노드 OpenShift 클러스터에 대한 PerformanceProfile CR 옵션
    PerformanceProfile CR 필드설명

    metadata.name

    name 이 관련 GitOps ZTP CR(사용자 정의 리소스)에 설정된 다음 필드와 일치하는지 확인합니다.

    • TunedPerformancePatch.yaml에서 include=openshift-node-performance-${PerformanceProfile.metadata.name}
    • 이름: validatorCRs/informDuValidator.yaml의 50-performance-${PerformanceProfile.metadata.name}

    spec.additionalKernelArgs

    "EFI=runtime" 은 클러스터 호스트에 대해 UEFI 보안 부팅을 구성합니다.

    spec.cpu.isolated

    분리된 CPU를 설정합니다. 모든 Hyper-Threading 쌍이 일치하는지 확인합니다.

    중요

    예약 및 격리된 CPU 풀은 겹치지 않아야 하며 함께 사용 가능한 모든 코어에 걸쳐 있어야 합니다. 에 대해 고려하지 않은 CPU 코어로 인해 시스템에서 정의되지 않은 동작이 발생합니다.

    spec.cpu.reserved

    예약된 CPU를 설정합니다. 워크로드 파티셔닝이 활성화되면 시스템 프로세스, 커널 스레드 및 시스템 컨테이너 스레드가 이러한 CPU로 제한됩니다. 분리되지 않은 모든 CPU를 예약해야 합니다.

    spec.hugepages.pages

    • 대규모 페이지 수 설정 (count)
    • 대규모 페이지 크기(크기)를 설정합니다.
    • nodehugepages 가 할당된 NUMA 노드로 설정합니다(노드)

    spec.realTimeKernel

    실시간 커널을 사용하려면 enabledtrue 로 설정합니다.

    spec.workloadHints

    workloadHints 를 사용하여 다른 워크로드 유형에 대한 최상위 플래그 세트를 정의합니다. 예제 구성은 짧은 대기 시간과 높은 성능을 위해 클러스터를 구성합니다.

워크로드 파티셔닝으로 플랫폼 pod의 확장된 management.workload.openshift.io/cores 리소스 유형을 도입합니다. kubelet은 해당 리소스 내에서 풀에 할당된 Pod의 리소스 및 CPU 요청을 알립니다. 워크로드 파티셔닝이 활성화되면 management.workload.openshift.io/cores 리소스를 사용하면 스케줄러에서 기본 cpuset 뿐만 아니라 호스트의 cpushares 용량에 따라 Pod를 올바르게 할당할 수 있습니다.

추가 리소스

17장. Node Observability Operator를 사용하여 CRI-O 및 Kubelet 프로파일링 데이터 요청

Node Observability Operator는 작업자 노드의 CRI-O 및 Kubelet 프로파일링 데이터를 수집하고 저장합니다. 프로파일링 데이터를 쿼리하여 CRI-O 및 Kubelet 성능 추세를 분석하고 성능 관련 문제를 디버깅할 수 있습니다.

중요

Node Observability Operator는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

17.1. Node Observability Operator의 워크플로우

다음 워크플로는 Node Observability Operator를 사용하여 프로파일링 데이터를 쿼리하는 방법을 간략하게 설명합니다.

  1. OpenShift Container Platform 클러스터에 Node Observability Operator를 설치합니다.
  2. NodeObservability 사용자 정의 리소스를 생성하여 선택한 작업자 노드에서 CRI-O 프로파일링을 활성화합니다.
  3. 프로파일링 쿼리를 실행하여 프로파일링 데이터를 생성합니다.

17.2. Node Observability Operator 설치

Node Observability Operator는 기본적으로 OpenShift Container Platform에 설치되지 않습니다. OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 Node Observability Operator를 설치할 수 있습니다.

17.2.1. CLI를 사용하여 Node Observability Operator 설치

OpenShift CLI(oc)를 사용하여 Node Observability Operator를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 Node Observability Operator를 사용할 수 있는지 확인합니다.

    $ oc get packagemanifests -n openshift-marketplace node-observability-operator

    출력 예

    NAME                            CATALOG                AGE
    node-observability-operator     Red Hat Operators      9h

  2. 다음 명령을 실행하여 node-observability-operator 네임스페이스를 생성합니다.

    $ oc new-project node-observability-operator
  3. OperatorGroup 오브젝트 YAML 파일을 생성합니다.

    cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: node-observability-operator
      namespace: node-observability-operator
    spec:
      targetNamespaces: []
    EOF
  4. 서브스크립션 오브젝트 YAML 파일을 생성하여 Operator에 네임스페이스를 등록합니다.

    cat <<EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: node-observability-operator
      namespace: node-observability-operator
    spec:
      channel: alpha
      name: node-observability-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
    EOF

검증

  1. 다음 명령을 실행하여 설치 계획 이름을 확인합니다.

    $ oc -n node-observability-operator get sub node-observability-operator -o yaml | yq '.status.installplan.name'

    출력 예

    install-dt54w

  2. 다음 명령을 실행하여 설치 계획 상태를 확인합니다.

    $ oc -n node-observability-operator get ip <install_plan_name> -o yaml | yq '.status.phase'

    <install_plan_name >은 이전 명령의 출력에서 얻은 설치 계획 이름입니다.

    출력 예

    COMPLETE

  3. Node Observability Operator가 실행 중인지 확인합니다.

    $ oc get deploy -n node-observability-operator

    출력 예

    NAME                                            READY   UP-TO-DATE  AVAILABLE   AGE
    node-observability-operator-controller-manager  1/1     1           1           40h

17.2.2. 웹 콘솔을 사용하여 Node Observability Operator 설치

OpenShift Container Platform 웹 콘솔에서 Node Observability Operator를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.
  • OpenShift Container Platform 웹 콘솔에 액세스할 수 있습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에 로그인합니다.
  2. 관리자 탐색 패널에서 Operator → OperatorHub 확장합니다.
  3. All items 필드에 Node Observability Operator 를 입력하고 Node Observability Operator 타일을 선택합니다.
  4. 설치를 클릭합니다.
  5. Operator 설치 페이지에서 다음 설정을 구성합니다.

    1. 채널 업데이트 영역에서 알파 를 클릭합니다.
    2. 설치 모드 영역에서 클러스터에서 특정 네임스페이스를 클릭합니다.
    3. 설치된 네임스페이스 목록에서 목록에서 node-observability-operator 를 선택합니다.
    4. 업데이트 승인 영역에서 Automatic 을 선택합니다.
    5. 설치를 클릭합니다.

검증

  1. 관리자 탐색 패널에서 Operator → 설치된 Operator 를 확장합니다.
  2. Node Observability Operator가 Operator 목록에 나열되어 있는지 확인합니다.

17.3. 노드 Observability 사용자 정의 리소스 생성

프로파일링 쿼리를 실행하기 전에 NodeObservability CR(사용자 정의 리소스)을 생성하고 실행해야 합니다. NodeObservability CR을 실행하면 nodeSelector 와 일치하는 작업자 노드에서 CRI-O 프로파일링을 활성화하는 데 필요한 머신 구성 및 머신 구성 풀 CR을 생성합니다.

중요

작업자 노드에서 CRI-O 프로파일링이 활성화되지 않으면 NodeObservabilityMachineConfig 리소스가 생성됩니다. NodeObservability CR에 지정된 nodeSelector 와 일치하는 작업자 노드가 재시작됩니다. 완료하는 데 10분 이상 걸릴 수 있습니다.

참고

kubelet 프로파일링은 기본적으로 활성화되어 있습니다.

노드의 CRI-O unix 소켓은 에이전트 pod에 마운트되므로 에이전트가 CRI-O와 통신하여 pprof 요청을 실행할 수 있습니다. 마찬가지로 kubelet-serving-ca 인증서 체인은 에이전트 pod에 마운트되므로 에이전트와 노드의 kubelet 끝점 간의 보안 통신이 가능합니다.

사전 요구 사항

  • Node Observability Operator가 설치되어 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 OpenShift Container Platform CLI에 로그인합니다.

    $ oc login -u kubeadmin https://<HOSTNAME>:6443
  2. 다음 명령을 실행하여 node-observability-operator 네임스페이스로 다시 전환합니다.

    $ oc project node-observability-operator
  3. 다음 텍스트가 포함된 nodeobservability.yaml 이라는 CR 파일을 생성합니다.

        apiVersion: nodeobservability.olm.openshift.io/v1alpha2
        kind: NodeObservability
        metadata:
          name: cluster 1
        spec:
          nodeSelector:
            kubernetes.io/hostname: <node_hostname> 2
          type: crio-kubelet
    1
    클러스터NodeObservability CR이 하나뿐이어야 하므로 이름을 클러스터로 지정해야 합니다.
    2
    노드 Observability 에이전트를 배포해야 하는 노드를 지정합니다.
  4. NodeObservability CR을 실행합니다.

    oc apply -f nodeobservability.yaml

    출력 예

    nodeobservability.olm.openshift.io/cluster created

  5. 다음 명령을 실행하여 NodeObservability CR의 상태를 검토합니다.

    $ oc get nob/cluster -o yaml | yq '.status.conditions'

    출력 예

    conditions:
      conditions:
      - lastTransitionTime: "2022-07-05T07:33:54Z"
        message: 'DaemonSet node-observability-ds ready: true NodeObservabilityMachineConfig
          ready: true'
        reason: Ready
        status: "True"
        type: Ready

    이유는 Ready 이고 상태가 True 인 경우 NodeObservability CR 실행이 완료됩니다.

17.4. 프로파일링 쿼리 실행

프로파일링 쿼리를 실행하려면 NodeObservabilityRun 리소스를 생성해야 합니다. 프로파일링 쿼리는 30초 동안 CRI-O 및 Kubelet 프로파일링 데이터를 가져오는 차단 작업입니다. 프로파일링 쿼리가 완료되면 컨테이너 파일 시스템 /run/node-observability 디렉터리 내에서 프로파일링 데이터를 검색해야 합니다. 데이터의 수명은 emptyDir 볼륨을 통해 에이전트 Pod에 바인딩되므로 에이전트 Pod가 실행 중인 동안 프로파일링 데이터에 액세스할 수 있습니다.

중요

언제든지 하나의 프로파일링 쿼리만 요청할 수 있습니다.

사전 요구 사항

  • Node Observability Operator가 설치되어 있습니다.
  • NodeObservability CR(사용자 정의 리소스)을 생성했습니다.
  • cluster-admin 권한이 있는 클러스터에 액세스할 수 있습니다.

프로세스

  1. 다음 텍스트가 포함된 nodeobservabilityrun.yaml 이라는 NodeObservabilityRun 리소스 파일을 생성합니다.

    apiVersion: nodeobservability.olm.openshift.io/v1alpha2
    kind: NodeObservabilityRun
    metadata:
      name: nodeobservabilityrun
    spec:
      nodeObservabilityRef:
        name: cluster
  2. NodeObservabilityRun 리소스를 실행하여 프로파일링 쿼리를 트리거합니다.

    $ oc apply -f nodeobservabilityrun.yaml
  3. 다음 명령을 실행하여 NodeObservabilityRun 의 상태를 검토합니다.

    $ oc get nodeobservabilityrun nodeobservabilityrun -o yaml  | yq '.status.conditions'

    출력 예

    conditions:
    - lastTransitionTime: "2022-07-07T14:57:34Z"
      message: Ready to start profiling
      reason: Ready
      status: "True"
      type: Ready
    - lastTransitionTime: "2022-07-07T14:58:10Z"
      message: Profiling query done
      reason: Finished
      status: "True"
      type: Finished

    상태가 True 이면 프로파일링 쿼리가 완료되고 유형이 완료됨 .

  4. 다음 bash 스크립트를 실행하여 컨테이너의 /run/node-observability 경로에서 프로파일링 데이터를 검색합니다.

    for a in $(oc get nodeobservabilityrun nodeobservabilityrun -o yaml | yq .status.agents[].name); do
      echo "agent ${a}"
      mkdir -p "/tmp/${a}"
      for p in $(oc exec "${a}" -c node-observability-agent -- bash -c "ls /run/node-observability/*.pprof"); do
        f="$(basename ${p})"
        echo "copying ${f} to /tmp/${a}/${f}"
        oc exec "${a}" -c node-observability-agent -- cat "${p}" > "/tmp/${a}/${f}"
      done
    done

18장. 네트워크 맨 위 엣지의 클러스터

18.1. 네트워크 맨 위 엣지의 과제

엣지 컴퓨팅은 지리적으로 대체된 위치에서 많은 사이트를 관리할 때 복잡한 문제를 안고 있습니다. ZTP( GitOps Zero Touch Provisioning)를 사용하여 네트워크의 맨 위에 있는 사이트를 프로비저닝하고 관리합니다.

18.1.1. 네트워크의 문제를 해결하여 엣지

현재 서비스 제공업체는 네트워크의 에지에 인프라를 배포하려고 합니다. 이는 상당한 과제를 안고 있습니다:

  • 여러 에지 사이트의 배포를 병렬로 어떻게 처리합니까?
  • 연결이 끊긴 환경에서 사이트를 배포해야 하는 경우 어떻게 됩니까?
  • 대규모 클러스터의 라이프사이클을 어떻게 관리합니까?

GitOps ZTP(ZTP) 및 GitOps 는 베어 메탈 장비에 대한 선언적 사이트 정의 및 구성으로 대규모로 원격 에지 사이트를 프로비저닝할 수 있으므로 이러한 문제를 해결합니다. 템플릿 또는 오버레이 구성은 CNF 워크로드에 필요한 OpenShift Container Platform 기능을 설치합니다. 설치 및 업그레이드의 전체 라이프사이클은 GitOps ZTP 파이프라인을 통해 처리됩니다.

GitOps ZTP는 인프라 배포에 GitOps를 사용합니다. GitOps에서는 선언적 YAML 파일 및 Git 리포지토리에 저장된 기타 정의된 패턴을 사용합니다. RHACM(Red Hat Advanced Cluster Management)은 Git 리포지토리를 사용하여 인프라 배포를 지원합니다.

GitOps는 추적성, 역할 기반 액세스 제어(RBAC) 및 각 사이트의 원하는 상태에 대해 단일 정보 소스를 제공합니다. 확장성 문제는 Webhook를 통해 Git 방법론 및 이벤트 중심 작업을 통해 해결됩니다.

GitOps ZTP 파이프라인이 에지 노드에 제공하는 선언적 사이트 정의 및 구성 CR(사용자 정의 리소스)을 생성하여 GitOps ZTP 워크플로를 시작합니다.

다음 다이어그램은 GitOps ZTP가 far edge 프레임워크 내에서 작동하는 방법을 보여줍니다.

네트워크 맨 위 엣지의 GitOps ZTP

18.1.2. GitOps ZTP를 사용하여 네트워크 엣지에서 클러스터를 프로비저닝

RHACM(Red Hat Advanced Cluster Management)은 단일 허브 클러스터가 많은 spoke 클러스터를 관리하는 hub-and-spoke 아키텍처의 클러스터를 관리합니다. RHACM을 실행하는 Hub 클러스터는 GitOps ZTP(ZTP) 및 RHACM을 설치할 때 배포되는 지원 서비스를 사용하여 관리 클러스터를 프로비저닝하고 배포합니다.

지원 서비스는 단일 노드 클러스터, 3-노드 클러스터 또는 베어 메탈에서 실행되는 표준 클러스터에서 OpenShift Container Platform의 프로비저닝을 처리합니다.

OpenShift Container Platform으로 베어 메탈 호스트를 프로비저닝하고 유지 관리하기 위해 GitOps ZTP를 사용하는 방법에 대한 개괄적인 개요는 다음과 같습니다.

  • RHACM을 실행하는 허브 클러스터는 OpenShift Container Platform 릴리스 이미지를 미러링하는 OpenShift 이미지 레지스트리를 관리합니다. RHACM은 OpenShift 이미지 레지스트리를 사용하여 관리 클러스터를 프로비저닝합니다.
  • Git 리포지토리에 버전이 지정된 YAML 형식 인벤토리 파일에서 베어 메탈 호스트를 관리합니다.
  • 호스트를 관리 클러스터로 프로비저닝할 준비를 하고 RHACM 및 지원 서비스를 사용하여 사이트에 베어 메탈 호스트를 설치합니다.

클러스터 설치 및 배포는 초기 설치 단계와 후속 구성 및 배포 단계가 포함된 2단계 프로세스입니다. 다음 다이어그램에서는 이 워크플로를 보여줍니다.

GitOps 및 GitOps ZTP를 사용하여 관리형 클러스터 설치 및 배포

18.1.3. SiteConfig 리소스 및 RHACM을 사용하여 관리형 클러스터 설치

GitOps ZTP(ZTP)는 Git 리포지토리에서 site Config CR(사용자 정의 리소스)을 사용하여 OpenShift Container Platform 클러스터를 설치하는 프로세스를 관리합니다. SiteConfig CR에는 설치에 필요한 클러스터별 매개변수가 포함되어 있습니다. 사용자 정의 추가 매니페스트를 포함하여 설치 중에 선택한 구성 CR을 적용하는 옵션이 있습니다.

GitOps ZTP 플러그인은 siteConfig CR을 처리하여 허브 클러스터에서 CR 컬렉션을 생성합니다. 이렇게 하면 RHACM(Red Hat Advanced Cluster Management)에서 지원 서비스가 트리거되어 베어 메탈 호스트에 OpenShift Container Platform을 설치합니다. hub 클러스터에서 이러한 CR에서 설치 상태 및 오류 메시지를 찾을 수 있습니다.

단일 클러스터를 수동으로 프로비저닝하거나 GitOps ZTP를 사용하여 배치에서 프로비저닝할 수 있습니다.

단일 클러스터 프로비저닝
클러스터의 단일 SiteConfig CR 및 관련 설치 및 구성 CR을 생성하고 Hub 클러스터에 적용하여 클러스터 프로비저닝을 시작합니다. 이는 대규모에 배포하기 전에 CR을 테스트하는 좋은 방법입니다.
여러 클러스터 프로비저닝
Git 리포지토리에서 site Config 및 관련 CR을 정의하여 최대 400개의 배치에 관리형 클러스터를 설치합니다. ArgoCD는 site Config CR을 사용하여 사이트를 배포합니다. RHACM 정책 생성기는 매니페스트를 생성하여 Hub 클러스터에 적용합니다. 그러면 클러스터 프로비저닝 프로세스가 시작됩니다.

18.1.4. 정책 및 PolicyGenTemplate 리소스를 사용하여 관리형 클러스터 구성

GitOps ZTP(Red Hat Advanced Cluster Management)는 정책 기반 거버넌스 접근 방식을 사용하여 구성을 적용하여 클러스터를 구성합니다.

정책 생성기 또는 PolicyGen 은 GitOps Operator의 플러그인으로, 간결한 템플릿에서 RHACM 정책을 생성할 수 있습니다. 이 툴은 여러 CR을 단일 정책으로 결합할 수 있으며, 플릿의 다양한 클러스터 하위 집합에 적용되는 여러 정책을 생성할 수 있습니다.

참고

확장성을 유지하고 클러스터 전체에서 구성 관리의 복잡성을 줄이려면 가능한 한 많은 공통성을 갖춘 구성 CR을 사용하십시오.

  • 가능한 경우 플릿 전체 공통 정책을 사용하여 구성 CR을 적용합니다.
  • 다음 기본 설정은 그룹 정책에서 최대한 많은 나머지 구성을 관리할 클러스터의 논리 그룹을 생성하는 것입니다.
  • 구성이 개별 사이트에 고유한 경우 허브 클러스터에서 RHACM 템플릿 작성을 사용하여 사이트별 데이터를 공통 또는 그룹 정책에 삽입합니다. 또는 사이트에 대한 개별 사이트 정책을 적용합니다.

다음 다이어그램은 클러스터 배포 구성 단계에서 정책 생성기가 GitOps 및 RHACM과 상호 작용하는 방법을 보여줍니다.

정책 생성기

대규모 클러스터의 경우 해당 클러스터 구성에 높은 수준의 일관성이 있는 것이 일반적입니다.

다음과 같은 권장 정책 구조에서는 구성 CR을 결합하여 몇 가지 목표를 달성할 수 있습니다.

  • 일반적인 구성을 한 번 설명하고 플릿에 적용됩니다.
  • 유지 관리 및 관리되는 정책의 수를 최소화합니다.
  • 클러스터 변형에 대한 일반적인 구성에서 유연성을 지원합니다.
표 18.1. 권장되는 PolicyGenTemplate 정책 범주
정책 카테고리설명

공통

공통 카테고리에 존재하는 정책은 플릿의 모든 클러스터에 적용됩니다. 공통 PolicyGenTemplate CR을 사용하여 모든 클러스터 유형에 공통 설치 설정을 적용합니다.

그룹

그룹 카테고리에 존재하는 정책은 플릿의 클러스터 그룹에 적용됩니다. 그룹 PolicyGenTemplate CR을 사용하여 단일 노드, 3-노드 및 표준 클러스터 설치의 특정 측면을 관리합니다. 클러스터 그룹은 지역 리전, 하드웨어 변형 등을 따를 수도 있습니다.

사이트

사이트 카테고리에 존재하는 정책은 특정 클러스터 사이트에 적용됩니다. 모든 클러스터는 고유한 정책을 유지 관리할 수 있습니다.

추가 리소스

  • ztp-site-generate 컨테이너 이미지에서 site ConfigPolicyGenTemplate CR을 추출하는 방법에 대한 자세한 내용은 ZTP Git 리포지토리 준비를 참조하십시오.

18.2. ZTP용 허브 클러스터 준비

연결이 끊긴 환경에서 RHACM을 사용하려면 필요한 Operator 이미지가 포함된 OpenShift Container Platform 릴리스 이미지 및 OLM(Operator Lifecycle Manager) 카탈로그를 미러링하는 미러 레지스트리를 생성합니다. OLM은 Operator 및 클러스터의 종속 항목을 관리, 설치 및 업그레이드합니다. 연결이 끊긴 미러 호스트를 사용하여 베어 메탈 호스트를 프로비저닝하는 데 사용되는 RHCOS ISO 및 RootFS 디스크 이미지를 제공할 수도 있습니다.

18.2.1. Telco RAN DU 4.14 검증 소프트웨어 구성 요소

Red Hat telco RAN DU 4.14 솔루션은 OpenShift Container Platform 관리 클러스터 및 허브 클러스터에 대해 다음과 같은 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.

표 18.2. Telco RAN DU 관리 클러스터 검증 소프트웨어 구성 요소
Component소프트웨어 버전

관리형 클러스터 버전

4.14

Cluster Logging Operator

5.7

Local Storage Operator

4.14

PTP Operator

4.14

SRIOV Operator

4.14

Node Tuning Operator

4.14

Logging Operator

4.14

SRIOV-FEC Operator

2.7

표 18.3. hub 클러스터 검증 소프트웨어 구성 요소
Component소프트웨어 버전

hub 클러스터 버전

4.14

GitOps ZTP 플러그인

4.14

Red Hat Advanced Cluster Management(RHACM)

2.9, 2.10

Red Hat OpenShift GitOps

1.9, 1.10

토폴로지 인식 라이프사이클 관리자(TALM)

4.14

18.2.2. GitOps ZTP에 대한 권장 허브 클러스터 사양 및 관리 클러스터 제한

GitOps Zero Touch Provisioning (ZTP)을 사용하면 지리적으로 분산된 지역 및 네트워크에서 수천 개의 클러스터를 관리할 수 있습니다. Red Hat Performance 및 Scale 랩은 랩 환경에서 단일 RHACM(Red Hat Advanced Cluster Management) 허브 클러스터에서 DU 프로필이 감소하여 3500개의 가상 단일 노드 OpenShift 클러스터를 성공적으로 생성 및 관리합니다.

실제 상황에서 관리할 수 있는 클러스터 수에 대한 스케일링 제한은 hub 클러스터에 영향을 미치는 다양한 요인에 따라 달라집니다. 예를 들면 다음과 같습니다.

hub 클러스터 리소스
사용 가능한 허브 클러스터 호스트 리소스(CPU, 메모리, 스토리지)는 허브 클러스터가 관리할 수 있는 클러스터 수를 결정하는 데 중요한 요소입니다. 허브 클러스터에 할당될수록 더 많은 관리 클러스터를 수용할 수 있습니다.
hub 클러스터 스토리지
허브 클러스터 호스트 스토리지 IOPS 등급과 허브 클러스터 호스트가 NVMe 스토리지를 사용하는지 여부는 허브 클러스터 성능과 관리할 수 있는 클러스터 수에 영향을 미칠 수 있습니다.
네트워크 대역폭 및 대기 시간
허브 클러스터와 관리 클러스터 간의 대기 시간이 느리거나 대기 시간이 긴 네트워크 연결은 허브 클러스터가 여러 클러스터를 관리하는 방법에 영향을 미칠 수 있습니다.
관리형 클러스터 크기 및 복잡성
관리 클러스터의 크기와 복잡성은 허브 클러스터의 용량에도 영향을 미칩니다. 더 많은 노드, 네임스페이스 및 리소스가 있는 대규모 관리 클러스터에는 추가 처리 및 관리 리소스가 필요합니다. 마찬가지로 RAN DU 프로필 또는 다양한 워크로드와 같은 복잡한 구성이 있는 클러스터에는 허브 클러스터의 더 많은 리소스가 필요할 수 있습니다.
관리 정책 수
해당 정책에 바인딩된 관리 클러스터 수를 통해 확장되는 허브 클러스터에서 관리하는 정책 수는 관리할 수 있는 클러스터 수를 결정하는 중요한 요소입니다.
모니터링 및 관리 워크로드
RHACM은 관리 클러스터를 지속적으로 모니터링하고 관리합니다. 허브 클러스터에서 실행되는 모니터링 및 관리 워크로드의 수와 복잡성은 용량에 영향을 미칠 수 있습니다. 집중적인 모니터링 또는 빈번한 조정 작업에는 추가 리소스가 필요할 수 있으므로 관리 가능한 클러스터 수를 제한할 수 있습니다.
RHACM 버전 및 구성
RHACM의 다른 버전에는 다양한 성능 특성과 리소스 요구 사항이 있을 수 있습니다. 또한 동시 조정 수 또는 상태 점검 빈도와 같은 RHACM의 구성 설정은 허브 클러스터의 관리 클러스터 용량에 영향을 미칠 수 있습니다.

다음 대표 구성 및 네트워크 사양을 사용하여 자체 Hub 클러스터 및 네트워크 사양을 개발합니다.

중요

다음 지침은 내부 랩 벤치마크 테스트만 기반으로 하며 완전한 베어 메탈 호스트 사양을 나타내지 않습니다.

표 18.4. 대표 3노드 허브 클러스터 머신 사양
요구 사항설명

OpenShift Container Platform

버전 4.13

RHACM

버전 2.7

토폴로지 인식 라이프사이클 관리자(TALM)

버전 4.13

서버 하드웨어

3개의 x Dell PowerEdge R650 랙 서버

NVMe 하드 디스크

  • /var/lib/etcd용 50GB 디스크
  • /var/lib/containers용 2.9TB 디스크

SSD 하드 디스크

  • 1 SSD가 PV CR로 프로비저닝된 15GB 씬 프로비저닝된 논리 볼륨으로 분할
  • 1 SSD는 추가 대규모 PV 리소스 역할을 합니다.

적용되는 DU 프로파일 정책 수

5

중요

다음 네트워크 사양은 일반적인 실제 RAN 네트워크를 나타내며 테스트 중에 스케일 랩 환경에 적용되었습니다.

표 18.5. 시뮬레이션된 랩 환경 네트워크 사양
사양설명

Round-trip Time (RTT) 대기 시간

50 MS

패킷 손실

0.02% 패킷 손실

네트워크 대역폭 제한

20Mbps

18.2.3. 연결이 끊긴 환경에서 GitOps ZTP 설치

연결이 끊긴 환경의 허브 클러스터에서 RHACM(Red Hat Advanced Cluster Management), Red Hat OpenShift GitOps 및 Topology Aware Lifecycle Manager(TALM)를 사용하여 여러 관리 클러스터의 배포를 관리합니다.

사전 요구 사항

  • OpenShift Container Platform CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 클러스터에서 사용할 연결이 끊긴 미러 레지스트리가 구성되어 있습니다.

    참고

    생성하는 연결이 끊긴 미러 레지스트리에는 허브 클러스터에서 실행 중인 TALM 버전과 일치하는 TALM 백업 및 사전 캐시 이미지가 포함되어야 합니다. spoke 클러스터는 연결이 끊긴 미러 레지스트리에서 이러한 이미지를 확인할 수 있어야 합니다.

프로세스

18.2.4. 연결이 끊긴 미러 호스트에 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 이미지가 지원되지 않습니다.

프로세스

  1. 미러 호스트에 로그인합니다.
  2. mirror.openshift.com 에서 RHCOS ISO 및 RootFS 이미지를 가져옵니다. 예를 들면 다음과 같습니다.

    1. 필요한 이미지 이름 및 OpenShift Container Platform 버전을 환경 변수로 내보냅니다.

      $ export ISO_IMAGE_NAME=<iso_image_name> 1
      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1
      $ export OCP_VERSION=<ocp_version> 1
      1
      ISO 이미지 이름(예: rhcos-4.1-x86_64-live.x86_64.iso)
      1
      rootfs 이미지 이름(예: rhcos-4.14.1-x86_64-live-rootfs.x86_64.img
      1
      OpenShift Container Platform 버전 (예: 4.14.1)
    2. 필요한 이미지를 다운로드합니다.

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.14/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.14/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

검증 단계

  • 다음과 같이 이미지가 성공적으로 다운로드되고 연결이 끊긴 미러 호스트에서 제공되고 있는지 확인합니다.

    $ wget http://$(hostname)/${ISO_IMAGE_NAME}

    출력 예

    Saving to: rhcos-4.14.1-x86_64-live.x86_64.iso
    rhcos-4.14.1-x86_64-live.x86_64.iso-  11%[====>    ]  10.01M  4.71MB/s

18.2.5. 지원 서비스 활성화

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이 있어야 합니다.

프로세스

  1. 프로비저닝 리소스를 활성화하여 모든 네임스페이스를 조사하고 연결이 끊긴 환경에 대한 미러를 구성합니다. 자세한 내용은 중앙 인프라 관리 서비스 활성화를 참조하십시오.
  2. 다음 명령을 실행하여 AgentServiceConfig CR을 업데이트합니다.

    $ oc edit AgentServiceConfig
  3. CR의 items.spec.osImages 필드에 다음 항목을 추가합니다.

    - cpuArchitecture: x86_64
        openshiftVersion: "4.14"
        rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
        url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

    다음과 같습니다.

    <host>
    대상 미러 레지스트리 HTTP 서버의 FQDN(정규화된 도메인 이름)입니다.
    <path>
    대상 미러 레지스트리의 이미지 경로입니다.

    편집기를 저장하고 종료하여 변경 사항을 적용합니다.

18.2.6. 연결이 끊긴 미러 레지스트리를 사용하도록 허브 클러스터 구성

연결이 끊긴 환경에서 연결이 끊긴 미러 레지스트리를 사용하도록 허브 클러스터를 구성할 수 있습니다.

사전 요구 사항

  • RHACM(Red Hat Advanced Cluster Management) 2.8이 설치된 연결이 끊긴 허브 클러스터 설치가 있어야 합니다.
  • HTTP 서버의 rootfsiso 이미지를 호스팅했습니다. OpenShift Container Platform 이미지 리포지토리 미러링에 대한 지침은 추가 리소스 섹션을 참조하십시오.
주의

HTTP 서버에 대해 TLS를 활성화하면 루트 인증서가 클라이언트가 신뢰하는 기관에서 서명했는지 확인하고 OpenShift Container Platform 허브와 관리 클러스터와 HTTP 서버 간의 신뢰할 수 있는 인증서 체인을 확인해야 합니다. 신뢰할 수 없는 인증서로 구성된 서버를 사용하면 이미지가 이미지 생성 서비스로 다운로드되지 않습니다. 신뢰할 수 없는 HTTPS 서버 사용은 지원되지 않습니다.

프로세스

  1. 미러 레지스트리 구성이 포함된 ConfigMap 을 생성합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: assisted-installer-mirror-config
      namespace: multicluster-engine 1
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: | 2
        -----BEGIN CERTIFICATE-----
        <certificate_contents>
        -----END CERTIFICATE-----
    
      registries.conf: | 3
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
           prefix = ""
           location = "quay.io/example-repository" 4
           mirror-by-digest-only = true
    
           [[registry.mirror]]
           location = "mirror1.registry.corp.com:5000/example-repository" 5
    1
    ConfigMap 네임스페이스는 multicluster-engine 으로 설정해야 합니다.
    2
    미러 레지스트리를 생성할 때 사용되는 미러 레지스트리의 인증서입니다.
    3
    미러 레지스트리의 구성 파일입니다. 미러 레지스트리 구성은 검색 이미지의 /etc/containers/registries.conf 파일에 미러 정보를 추가합니다. 미러 정보는 정보가 설치 프로그램에 전달될 때 install-config.yaml 파일의 imageContentSources 섹션에 저장됩니다. hub 클러스터에서 실행되는 지원 서비스 Pod는 구성된 미러 레지스트리에서 컨테이너 이미지를 가져옵니다.
    4
    미러 레지스트리의 URL입니다. 미러 레지스트리를 구성할 때 oc adm release mirror 명령을 실행하여 imageContentSources 섹션의 URL을 사용해야 합니다. 자세한 내용은 OpenShift Container Platform 이미지 저장소 미러링 섹션을 참조하십시오.
    5
    registries.conf 파일에 정의된 레지스트리는 레지스트리가 아닌 리포지터리로 범위를 지정해야 합니다. 이 예에서 quay.io/example-repositorymirror1.registry.corp.com:5000/example-repository 리포지토리의 범위는 example-repository 리포지토리로 지정됩니다.

    이 업데이트는 다음과 같이 AgentServiceConfig 사용자 정의 리소스에서 mirrorRegistryRef 를 업데이트합니다.

    출력 예

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      name: agent
      namespace: multicluster-engine 1
    spec:
      databaseStorage:
        volumeName: <db_pv_name>
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_storage_size>
      filesystemStorage:
        volumeName: <fs_pv_name>
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_storage_size>
      mirrorRegistryRef:
        name: assisted-installer-mirror-config 2
      osImages:
        - openshiftVersion: <ocp_version>
          url: <iso_url> 3

    1
    ConfigMap 네임스페이스와 일치하도록 AgentServiceConfig 네임스페이스를 multicluster-engine 으로 설정합니다.
    2
    관련 ConfigMap CR에 지정된 정의와 일치하도록 mirrorRegistryRef.name 을 설정합니다.
    3
    httpd 서버에서 호스팅되는 ISO의 URL 설정
중요

클러스터 설치 중에 유효한 NTP 서버가 필요합니다. 적절한 NTP 서버를 사용할 수 있고 연결이 끊긴 네트워크를 통해 설치된 클러스터에서 연결할 수 있는지 확인합니다.

18.2.7. 인증되지 않은 레지스트리를 사용하도록 허브 클러스터 구성

인증되지 않은 레지스트리를 사용하도록 허브 클러스터를 구성할 수 있습니다. 인증되지 않은 레지스트리는 이미지에 액세스하고 다운로드하는 데 인증이 필요하지 않습니다.

사전 요구 사항

  • hub 클러스터를 설치 및 구성하고 hub 클러스터에 Red Hat Advanced Cluster Management(RHACM)를 설치 및 구성했습니다.
  • OpenShift Container Platform CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • hub 클러스터에서 사용할 인증되지 않은 레지스트리를 구성했습니다.

프로세스

  1. 다음 명령을 실행하여 AgentServiceConfig CR(사용자 정의 리소스)을 업데이트합니다.

    $ oc edit AgentServiceConfig agent
  2. CR에 unauthenticatedRegistries 필드를 추가합니다.

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      name: agent
    spec:
      unauthenticatedRegistries:
      - example.registry.com
      - example.registry2.com
      ...

    인증되지 않은 레지스트리는 AgentServiceConfig 리소스의 spec.unauthenticatedRegistries 에 나열됩니다. 이 목록의 레지스트리에는 spoke 클러스터 설치에 사용되는 풀 시크릿에 항목이 필요하지 않습니다. assisted-service 는 설치에 사용되는 모든 이미지 레지스트리에 대한 인증 정보가 포함되어 있는지 확인하여 풀 시크릿을 검증합니다.

참고

미러 레지스트리는 무시 목록에 자동으로 추가되며 spec.unauthenticatedRegistries 아래에 추가할 필요가 없습니다. ConfigMap 에서 PUBLIC_CONTAINER_REGISTRIES 환경 변수를 지정하면 지정된 값이 있는 기본값이 재정의됩니다. PUBLIC_CONTAINER_REGISTRIES 기본값은 quay.ioregistry.svc.ci.openshift.org 입니다.

검증

다음 명령을 실행하여 hub 클러스터에서 새로 추가된 레지스트리에 액세스할 수 있는지 확인합니다.

  1. hub 클러스터에 대한 디버그 쉘 프롬프트를 엽니다.

    $ oc debug node/<node_name>
  2. 다음 명령을 실행하여 인증되지 않은 레지스트리에 대한 액세스를 테스트합니다.

    sh-4.4# podman login -u kubeadmin -p $(oc whoami -t) <unauthenticated_registry>

    다음과 같습니다.

    <unauthenticated_registry>
    새 레지스트리입니다(예: unauthenticated-image-registry.openshift-image-registry.svc:5000 ).

    출력 예

    Login Succeeded!

18.2.8. ArgoCD를 사용하여 허브 클러스터 구성

ZTP(ZTP)를 사용하여 각 사이트에 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하는 ArgoCD 애플리케이션 세트를 사용하여 허브 클러스터를 구성할 수 있습니다.

참고

RHACM(Red Hat Advanced Cluster Management)은 site Config CR을 사용하여 ArgoCD의 Day 1 관리형 클러스터 설치 CR을 생성합니다. 각 ArgoCD 애플리케이션은 최대 300개의 site Config CR을 관리할 수 있습니다.

사전 요구 사항

  • RHACM(Red Hat Advanced Cluster Management) 및 Red Hat OpenShift GitOps가 설치된 OpenShift Container Platform 허브 클러스터가 있어야 합니다.
  • " GitOps ZTP 사이트 구성 리포지토리 준비" 섹션에 설명된 대로 GitOps ZTP 플러그인 컨테이너에서 참조 배포를 추출했습니다. 참조 배포를 추출하면 다음 절차에서 참조되는 out/argocd/deployment 디렉터리가 생성됩니다.

프로세스

  1. ArgoCD 파이프라인 구성을 준비합니다.

    1. 예제 디렉터리와 유사한 디렉터리 구조를 사용하여 Git 리포지토리를 생성합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
    2. ArgoCD UI를 사용하여 리포지토리에 대한 액세스를 구성합니다. 설정에서 다음을 구성합니다.

      • 리포지토리 - 연결 정보를 추가합니다. URL은 .git 로 끝나야 합니다(예: https://repo.example.com/repo.git 및 인증 정보).
      • certificates - 필요한 경우 리포지토리의 공용 인증서를 추가합니다.
    3. Git 리포지토리에 따라 2개의 ArgoCD 애플리케이션( out/argocd/deployment/clusters-app.yamlout/argocd/deployment/policies-app.yaml )을 수정합니다.

      • Git 리포지토리를 가리키도록 URL을 업데이트합니다. URL은 .git 로 끝납니다(예: https://repo.example.com/repo.git ).
      • targetRevision 은 모니터링할 Git 리포지토리 분기를 나타냅니다.
      • path 는 각각 SiteConfigPolicyGenTemplate CR의 경로를 지정합니다.
  1. GitOps ZTP 플러그인을 설치하려면 허브 클러스터의 ArgoCD 인스턴스를 관련 MCCE(Multicluster engine) 서브스크립션 이미지로 패치합니다. 이전에 추출한 패치 파일을 사용자 환경의 out/argocd/deployment/ 디렉터리에 사용자 지정합니다.

    1. RHACM 버전과 일치하는 multicluster-operators-subscription 이미지를 선택합니다.

      표 18.6. multicluster-operators-subscription 이미지 버전
      OpenShift Container Platform 버전RHACM 버전MCE 버전MCE RHEL 버전MCE 이미지

      4.14, 4.15, 4.16

      2.8, 2.9

      2.8, 2.9

      RHEL 8

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9

      4.14, 4.15, 4.16

      2.10

      2.10

      RHEL 9

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10

      중요

      multicluster-operators-subscription 이미지의 버전은 RHACM 버전과 일치해야 합니다. MCE 2.10 릴리스부터 RHEL 9는 multicluster-operators-subscription 이미지의 기본 이미지입니다.

    2. out/argocd/deployment/argocd-openshift-gitops-patch.json 파일에 다음 구성을 추가합니다.

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }
      1
      선택 사항: RHEL 9 이미지의 경우 ArgoCD 버전에 필요한 범용 실행 파일을 /policy-generator/PolicyGenerator-not-fips-compliant 폴더에 복사합니다.
      2
      multicluster-operators-subscription 이미지를 RHACM 버전과 일치시킵니다.
      3
      연결이 끊긴 환경에서는 multicluster-operators-subscription 이미지의 URL을 해당 환경에 해당하는 연결이 끊긴 레지스트리로 교체합니다.
    3. ArgoCD 인스턴스를 패치합니다. 다음 명령을 실행합니다.

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
  2. RHACM 2.7 이상에서는 다중 클러스터 엔진에서 기본적으로 cluster-proxy-addon 기능을 활성화합니다. 다음 패치를 적용하여 cluster-proxy-addon 기능을 비활성화하고 이 애드온을 담당하는 관련 허브 클러스터 및 관리 Pod를 제거합니다. 다음 명령을 실행합니다.

    $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
  3. 다음 명령을 실행하여 허브 클러스터에 파이프라인 구성을 적용합니다.

    $ oc apply -k out/argocd/deployment

18.2.9. GitOps ZTP 사이트 구성 리포지토리 준비

GitOps ZTP(ZTP) 파이프라인을 사용하려면 사이트 구성 데이터를 호스팅하기 위해 Git 리포지토리를 준비해야 합니다.

사전 요구 사항

  • 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하도록 Hub 클러스터 GitOps 애플리케이션을 구성했습니다.
  • GitOps ZTP를 사용하여 관리 클러스터를 배포했습니다.

프로세스

  1. SiteConfigPolicyGenTemplate CR에 대한 별도의 경로를 사용하여 디렉터리 구조를 생성합니다.

    참고

    site ConfigPolicyGenTemplate CR을 별도의 디렉터리에 보관합니다. SiteConfigPolicyGenTemplate 디렉터리에는 둘 다 해당 디렉터리에 파일을 명시적으로 포함하는 kustomization.yaml 파일이 포함되어야 합니다.

  2. 다음 명령을 사용하여 ztp-site-generate 컨테이너 이미지에서 argocd 디렉터리를 내보냅니다.

    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14
    $ mkdir -p ./out
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14 extract /home/ztp --tar | tar x -C ./out
  3. out 디렉터리에 다음 하위 디렉터리가 포함되어 있는지 확인합니다.

    • out/extra-manifest 에는 SiteConfig 에서 추가 매니페스트 configMap 을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
    • Out/source-crs 에는 PolicyGenTemplate 이 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
    • out/argocd/deployment 에는 이 절차의 다음 단계에서 사용할 허브 클러스터에 적용할 패치 및 YAML 파일이 포함되어 있습니다.
    • out/argocd/example 에는 권장 구성을 나타내는 SiteConfigPolicyGenTemplate 파일의 예가 포함되어 있습니다.
  4. out/source-crs 폴더 및 콘텐츠를 PolicyGentemplate 디렉터리에 복사합니다.
  5. out/extra-manifests 디렉터리에는 RAN DU 클러스터에 대한 참조 매니페스트가 포함되어 있습니다. out/extra-manifests 디렉터리를 site Config 폴더에 복사합니다. 이 디렉터리에는 ztp-site-generate 컨테이너의 CR만 포함되어야 합니다. 여기에 사용자 제공 CR을 추가하지 마십시오. 사용자 제공 CR을 사용하려면 해당 콘텐츠에 대한 다른 디렉터리를 생성해야 합니다. 예를 들면 다음과 같습니다.

    example/
      ├── policygentemplates
      │   ├── kustomization.yaml
      │   └── source-crs/
      └── siteconfig
            ├── extra-manifests
            └── kustomization.yaml
  6. 디렉터리 구조와 kustomization.yaml 파일을 커밋하고 Git 리포지토리로 내보냅니다. Git으로의 초기 내보내기에는 kustomization.yaml 파일이 포함되어야 합니다.

out/argocd/example 아래의 디렉터리 구조를 Git 리포지토리의 구조 및 콘텐츠에 대한 참조로 사용할 수 있습니다. 이러한 구조에는 단일 노드, 3-노드 및 표준 클러스터에 대한 SiteConfigPolicyGenTemplate 참조 CR이 포함됩니다. 사용하지 않는 클러스터 유형에 대한 참조를 제거합니다.

모든 클러스터 유형의 경우 다음을 수행해야 합니다.

  • source-crs 하위 디렉터리를 policygentemplate 디렉터리에 추가합니다.
  • extra-manifests 디렉터리를 siteconfig 디렉터리에 추가합니다.

다음 예제에서는 단일 노드 클러스터 네트워크에 대한 CR 세트를 설명합니다.

example/
  ├── policygentemplates
  │   ├── common-ranGen.yaml
  │   ├── example-sno-site.yaml
  │   ├── group-du-sno-ranGen.yaml
  │   ├── group-du-sno-validator-ranGen.yaml
  │   ├── kustomization.yaml
  │   ├── source-crs/
  │   └── ns.yaml
  └── siteconfig
        ├── example-sno.yaml
        ├── extra-manifests/ 1
        ├── custom-manifests/ 2
        ├── KlusterletAddonConfigOverride.yaml
        └── kustomization.yaml
1
ztp-container 의 참조 매니페스트를 포함합니다.
2
사용자 정의 매니페스트를 포함합니다.
18.2.9.1. 버전 독립성을 위한 GitOps ZTP 사이트 구성 리포지토리 준비

GitOps ZTP를 사용하여 다른 버전의 OpenShift Container Platform을 실행하는 관리 클러스터의 소스 CR(사용자 정의 리소스)을 관리할 수 있습니다. 즉, hub 클러스터에서 실행되는 OpenShift Container Platform 버전은 관리 클러스터에서 실행되는 버전과 독립적일 수 있습니다.

프로세스

  1. SiteConfigPolicyGenTemplate CR에 대한 별도의 경로를 사용하여 디렉터리 구조를 생성합니다.
  2. PolicyGenTemplate 디렉터리 내에서 사용할 각 OpenShift Container Platform 버전에 대한 디렉터리를 생성합니다. 각 버전에 다음 리소스를 생성합니다.

    • 해당 디렉터리에 파일을 명시적으로 포함하는 kustomization.yaml 파일
    • ztp-site-generate 컨테이너의 참조 CR 구성 파일을 포함하는 source-crs 디렉터리

      사용자 제공 CR을 사용하려면 이를 위해 별도의 디렉터리를 생성해야 합니다.

  3. /siteconfig 디렉터리에서 사용할 각 OpenShift Container Platform 버전의 하위 디렉터리를 생성합니다. 각 버전에 대해 컨테이너에서 복사할 참조 CR을 참조하기 위해 하나 이상의 디렉터리를 생성합니다. 디렉터리 이름 지정 또는 참조 디렉터리 수에는 제한이 없습니다. 사용자 정의 매니페스트를 사용하려면 이를 위해 별도의 디렉터리를 생성해야 합니다.

    다음 예제에서는 다른 OpenShift Container Platform 버전에 대해 사용자 제공 매니페스트 및 CR을 사용하는 구조를 설명합니다.

    ├── policygentemplates
    │   ├── kustomization.yaml 1
    │   ├── version_4.13 2
    │   │   ├── common-ranGen.yaml
    │   │   ├── group-du-sno-ranGen.yaml
    │   │   ├── group-du-sno-validator-ranGen.yaml
    │   │   ├── helix56-v413.yaml
    │   │   ├── kustomization.yaml 3
    │   │   ├── ns.yaml
    │   │   └── source-crs/ 4
    │   │      └── reference-crs/ 5
    │   │      └── custom-crs/ 6
    │   └── version_4.14 7
    │       ├── common-ranGen.yaml
    │       ├── group-du-sno-ranGen.yaml
    │       ├── group-du-sno-validator-ranGen.yaml
    │       ├── helix56-v414.yaml
    │       ├── kustomization.yaml 8
    │       ├── ns.yaml
    │       └── source-crs/ 9
    │         └── reference-crs/ 10
    │         └── custom-crs/ 11
    └── siteconfig
        ├── kustomization.yaml
        ├── version_4.13
        │   ├── helix56-v413.yaml
        │   ├── kustomization.yaml
        │   ├── extra-manifest/ 12
        │   └── custom-manifest/ 13
        └── version_4.14
            ├── helix57-v414.yaml
            ├── kustomization.yaml
            ├── extra-manifest/ 14
            └── custom-manifest/ 15
    1
    최상위 kustomization YAML 파일을 생성합니다.
    2 7
    사용자 지정 /policygentemplates 디렉터리 내에 버전별 디렉터리를 생성합니다.
    3 8
    각 버전에 대한 kustomization.yaml 파일을 생성합니다.
    4 9
    ztp-site-generate 컨테이너의 참조 CR을 포함하도록 각 버전의 source-crs 디렉터리를 생성합니다.
    5 10
    ZTP 컨테이너에서 추출된 정책 CR에 대한 reference-crs 디렉터리를 생성합니다.
    6 11
    선택 사항: 사용자 제공 CR에 대한 사용자 정의 CR 디렉터리를 생성합니다.
    12 14
    사용자 지정 /siteconfig 디렉터리에 디렉터리를 생성하여 ztp-site-generate 컨테이너의 추가 매니페스트를 포함합니다.
    13 15
    사용자 제공 매니페스트를 저장할 폴더를 생성합니다.
    참고

    이전 예에서 사용자 지정 /siteconfig 디렉터리의 각 버전 하위 디렉터리에는 컨테이너에서 복사한 참조 매니페스트가 포함된 두 개의 하위 디렉터리가 있으며, 다른 하나는 사용자가 제공하는 사용자 정의 매니페스트를 위한 것입니다. 해당 디렉터리에 할당된 이름은 예입니다. 사용자 제공 CR을 사용하는 경우 SiteConfig CR의 extraManifests.searchPaths 아래에 나열된 마지막 디렉터리는 사용자 제공 CR이 포함된 디렉터리여야 합니다.

  4. 생성한 디렉터리의 검색 경로를 포함하도록 SiteConfig CR을 편집합니다. extraManifests.searchPaths 아래에 나열된 첫 번째 디렉터리는 참조 매니페스트가 포함된 디렉터리여야 합니다. 디렉터리가 나열되는 순서를 고려하십시오. 디렉터리에 이름이 같은 파일이 포함된 경우 최종 디렉터리의 파일이 우선합니다.

    siteConfig CR의 예

    extraManifests:
        searchPaths:
        - extra-manifest/ 1
        - custom-manifest/ 2

    1
    참조 매니페스트가 포함된 디렉터리는 extraManifests.searchPaths 아래에 먼저 나열되어야 합니다.
    2
    사용자 제공 CR을 사용하는 경우 SiteConfig CR의 extraManifests.searchPaths 아래에 나열된 마지막 디렉터리는 해당 사용자 제공 CR을 포함하는 디렉터리여야 합니다.
  5. 최상위 kustomization.yaml 파일을 편집하여 활성 상태인 OpenShift Container Platform 버전을 제어합니다. 다음은 최상위 수준의 kustomization.yaml 파일의 예입니다.

    resources:
    - version_4.13 1
    #- version_4.14 2
    1
    버전 4.13을 활성화합니다.
    2
    주석을 사용하여 버전을 비활성화합니다.

18.3. GitOps ZTP 업데이트

hub 클러스터, RHACM(Advanced Cluster Management) 및 관리형 OpenShift Container Platform 클러스터와 독립적으로ZTP(ZTP) 인프라를 업데이트할 수 있습니다.

참고

새 버전이 출시되면 Red Hat OpenShift GitOps Operator를 업데이트할 수 있습니다. GitOps ZTP 플러그인을 업데이트할 때 참조 구성에서 업데이트된 파일을 검토하고 변경 사항이 요구 사항을 충족하는지 확인합니다.

18.3.1. GitOps ZTP 업데이트 프로세스 개요

이전 버전의 GitOps ZTP 인프라를 실행하는 완전히 작동하는 허브 클러스터에 대해 GitOps ZTP(ZTP)를 업데이트할 수 있습니다. 업데이트 프로세스는 관리 클러스터에 미치는 영향을 방지합니다.

참고

권장 콘텐츠 추가를 포함하여 정책 설정을 변경하면 관리 클러스터에 롤아웃하고 조정되어야 하는 업데이트된 정책이 생성됩니다.

높은 수준에서 GitOps ZTP 인프라를 업데이트하기위한 전략은 다음과 같습니다.

  1. 기존 클러스터에 ztp-done 라벨을 지정합니다.
  2. ArgoCD 애플리케이션을 중지합니다.
  3. 새 GitOps ZTP 툴을 설치합니다.
  4. Git 리포지토리에서 필요한 콘텐츠 및 선택적 변경 사항을 업데이트합니다.
  5. 애플리케이션 구성을 업데이트하고 다시 시작합니다.

18.3.2. 업그레이드 준비

다음 절차에 따라ZTP(ZTP) 업그레이드를 위한 사이트를 준비합니다.

프로세스

  1. GitOps ZTP와 함께 사용하도록 Red Hat OpenShift GitOps를 구성하는 데 사용되는 사용자 정의 리소스(CR)가 있는 GitOps ZTP 컨테이너의 최신 버전을 가져옵니다.
  2. 다음 명령을 사용하여 argocd/deployment 디렉터리를 추출합니다.

    $ mkdir -p ./update
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14 extract /home/ztp --tar | tar x -C ./update

    /update 디렉터리에는 다음 하위 디렉터리가 포함되어 있습니다.

    • update/extra-manifest: SiteConfig CR에서 추가 매니페스트 configMap 을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
    • update/source-crs: PolicyGenTemplate CR에서 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
    • update/argocd/deployment: 이 절차의 다음 단계에서 사용할 허브 클러스터에 적용할 패치 및 YAML 파일이 포함되어 있습니다.
    • update/argocd/example: 권장 구성 을 나타내는 example siteConfigPolicyGenTemplate 파일이 포함되어 있습니다.
  3. 애플리케이션 이름과 Git 리포지토리의 URL, 분기 및 경로를 반영하도록 cluster-app.yaml 및 policies-app.yaml 파일을 업데이트합니다.

    업그레이드에 더 이상 사용되지 않는 정책이 생성되는 변경 사항이 포함된 경우 업그레이드를 수행하기 전에 더 이상 사용되지 않는 정책을 제거해야 합니다.

  4. 플릿 사이트 CR을 관리하는 /update 폴더 및 Git 리포지터리의 구성 및 배포 소스 CR 간 변경 사항을 diffe the changes between the configuration and deployment source CRs in the /update folder and Git repo where you manage your fleet site CRs. 필요한 변경 사항을 적용하고 사이트 리포지토리에 내보냅니다.

    중요

    GitOps ZTP를 최신 버전으로 업데이트할 때 update/argocd/deployment 디렉터리의 변경 사항을 사이트 리포지토리에 적용해야 합니다. 이전 버전의 argocd/deployment/ 파일을 사용하지 마십시오.

18.3.3. 기존 클러스터에 레이블 지정

툴 업데이트로 기존 클러스터가 그대로 유지되도록 기존 관리 클러스터에 ztp-done 라벨을 지정합니다.

참고

이 절차는 Topology Aware Lifecycle Manager (TALM)를 사용하여 프로비저닝되지 않은 클러스터를 업데이트하는 경우에만 적용됩니다. TALM으로 프로비저닝하는 클러스터는 자동으로 ztp-done 로 레이블이 지정됩니다.

프로세스

  1. local-cluster!=true 와 같이 GitOps ZTP(ZTP)와 함께 배포된 관리 클러스터를 나열하는 라벨 선택기를 찾습니다.

    $ oc get managedcluster -l 'local-cluster!=true'
  2. 결과 목록에 GitOps ZTP와 함께 배포된 모든 관리 클러스터가 포함되어 있는지 확인한 다음 해당 선택기를 사용하여 ztp-done 레이블을 추가합니다.

    $ oc label managedcluster -l 'local-cluster!=true' ztp-done=

18.3.4. 기존 GitOps ZTP 애플리케이션 중지

기존 애플리케이션을 제거하면 새 버전의 툴을 사용할 수 있을 때까지 Git 리포지토리의 기존 콘텐츠에 대한 변경 사항이 롤아웃되지 않습니다.

배포 디렉터리의 애플리케이션 파일을 사용합니다. 애플리케이션에 사용자 지정 이름을 사용한 경우 먼저 이러한 파일의 이름을 업데이트합니다.

프로세스

  1. 클러스터 애플리케이션에서 캐스케이딩되지 않은 삭제를 수행하여 생성된 모든 리소스를 제자리에 남겨 둡니다.

    $ oc delete -f update/argocd/deployment/clusters-app.yaml
  2. 정책 애플리케이션에서 계단식 삭제를 수행하여 이전 정책을 모두 제거합니다.

    $ oc patch -f policies-app.yaml -p '{"metadata": {"finalizers": ["resources-finalizer.argocd.argoproj.io"]}}' --type merge
    $ oc delete -f update/argocd/deployment/policies-app.yaml

18.3.5. Git 리포지토리에 대한 필수 변경 사항

ztp-site-generate 컨테이너를 이전 버전의 ZTP(ZTP)에서 4.10 이상으로 업그레이드하는 경우 Git 리포지토리의 콘텐츠에 대한 추가 요구 사항이 있습니다. 리포지토리의 기존 콘텐츠는 이러한 변경 사항을 반영하도록 업데이트해야 합니다.

  • PolicyGenTemplate 파일을 변경해야 합니다.

    모든 PolicyGenTemplate 파일은 ztp 로 접두사 가 지정된 네임스페이스 에서 생성해야 합니다. 이렇게 하면 GitOps ZTP 애플리케이션이 RHSM(Red Hat Advanced Cluster Management)에서 내부적으로 정책을 관리하는 방식과 충돌하지 않고 GitOps ZTP에서 생성한 정책 CR을 관리할 수 있습니다.

  • kustomization.yaml 파일을 리포지토리에 추가합니다.

    모든 siteConfigPolicyGenTemplate CR은 해당 디렉터리 트리 아래에 kustomization.yaml 파일에 포함되어야 합니다. 예를 들면 다음과 같습니다.

    ├── policygentemplates
    │   ├── site1-ns.yaml
    │   ├── site1.yaml
    │   ├── site2-ns.yaml
    │   ├── site2.yaml
    │   ├── common-ns.yaml
    │   ├── common-ranGen.yaml
    │   ├── group-du-sno-ranGen-ns.yaml
    │   ├── group-du-sno-ranGen.yaml
    │   └── kustomization.yaml
    └── siteconfig
        ├── site1.yaml
        ├── site2.yaml
        └── kustomization.yaml
    참고

    생성기 섹션에 나열된 파일에는 site Config 또는 PolicyGenTemplate CR만 포함되어야 합니다. 기존 YAML 파일에 다른 CR(예: 네임스페이스 )이 포함된 경우 이러한 다른 CR을 별도의 파일로 가져와 resources 섹션에 나열해야 합니다.

    PolicyGenTemplate kustomization 파일에는 resources 섹션의 generator 섹션에 있는 모든 PolicyGenTemplate YAML 파일과 Namespace CR이 포함되어야 합니다. 예를 들면 다음과 같습니다.

    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    
    generators:
    - common-ranGen.yaml
    - group-du-sno-ranGen.yaml
    - site1.yaml
    - site2.yaml
    
    resources:
    - common-ns.yaml
    - group-du-sno-ranGen-ns.yaml
    - site1-ns.yaml
    - site2-ns.yaml

    SiteConfig kustomization 파일에는 생성기 섹션의 모든 SiteConfig YAML 파일과 리소스의 다른 CR이 포함되어야 합니다.

    apiVersion: kustomize.config.k8s.io/v1beta1
    kind: Kustomization
    
    generators:
    - site1.yaml
    - site2.yaml
  • pre-sync.yamlpost-sync.yaml 파일을 제거합니다.

    OpenShift Container Platform 4.10 이상에서는 더 이상 pre-sync.yamlpost-sync.yaml 파일이 필요하지 않습니다. update/deployment/kustomization.yaml CR은 hub 클러스터에서 정책 배포를 관리합니다.

    참고

    SiteConfigPolicyGenTemplate 트리 아래에는 pre-sync.yamlpost-sync.yaml 파일 세트가 있습니다.

  • 권장 변경 사항 검토 및 통합

    각 릴리스에는 배포된 클러스터에 적용된 구성에 권장되는 추가 변경 사항이 포함될 수 있습니다. 일반적으로 이러한 변경으로 인해 OpenShift 플랫폼, 추가 기능 또는 플랫폼 튜닝에서 CPU 사용이 줄어들게 됩니다.

    네트워크의 클러스터 유형에 적용되는 사이트ConfigPolicyGenTemplate CR을 확인합니다. 이러한 예제는 GitOps ZTP 컨테이너에서 추출된 argocd/example 디렉터리에서 확인할 수 있습니다.

18.3.6. 새 GitOps ZTP 애플리케이션 설치

추출된 argocd/deployment 디렉터리를 사용하여 애플리케이션이 사이트 Git 리포지토리를 가리키는지 확인한 후 배포 디렉터리의 전체 콘텐츠를 적용합니다. 디렉터리의 전체 콘텐츠를 적용하면 애플리케이션에 필요한 모든 리소스가 올바르게 구성됩니다.

프로세스

  1. GitOps ZTP 플러그인을 설치하려면 허브 클러스터의 ArgoCD 인스턴스를 관련 MCCE(Multicluster engine) 서브스크립션 이미지로 패치합니다. 이전에 추출한 패치 파일을 사용자 환경의 out/argocd/deployment/ 디렉터리에 사용자 지정합니다.

    1. RHACM 버전과 일치하는 multicluster-operators-subscription 이미지를 선택합니다.

      표 18.7. multicluster-operators-subscription 이미지 버전
      OpenShift Container Platform 버전RHACM 버전MCE 버전MCE RHEL 버전MCE 이미지

      4.14, 4.15, 4.16

      2.8, 2.9

      2.8, 2.9

      RHEL 8

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.8

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel8:v2.9

      4.14, 4.15, 4.16

      2.10

      2.10

      RHEL 9

      registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10

      중요

      multicluster-operators-subscription 이미지의 버전은 RHACM 버전과 일치해야 합니다. MCE 2.10 릴리스부터 RHEL 9는 multicluster-operators-subscription 이미지의 기본 이미지입니다.

    2. out/argocd/deployment/argocd-openshift-gitops-patch.json 파일에 다음 구성을 추가합니다.

      {
        "args": [
          "-c",
          "mkdir -p /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator && cp /policy-generator/PolicyGenerator-not-fips-compliant /.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator" 1
        ],
        "command": [
          "/bin/bash"
        ],
        "image": "registry.redhat.io/rhacm2/multicluster-operators-subscription-rhel9:v2.10", 2 3
        "name": "policy-generator-install",
        "imagePullPolicy": "Always",
        "volumeMounts": [
          {
            "mountPath": "/.config",
            "name": "kustomize"
          }
        ]
      }
      1
      선택 사항: RHEL 9 이미지의 경우 ArgoCD 버전에 필요한 범용 실행 파일을 /policy-generator/PolicyGenerator-not-fips-compliant 폴더에 복사합니다.
      2
      multicluster-operators-subscription 이미지를 RHACM 버전과 일치시킵니다.
      3
      연결이 끊긴 환경에서는 multicluster-operators-subscription 이미지의 URL을 해당 환경에 해당하는 연결이 끊긴 레지스트리로 교체합니다.
    3. ArgoCD 인스턴스를 패치합니다. 다음 명령을 실행합니다.

      $ oc patch argocd openshift-gitops \
      -n openshift-gitops --type=merge \
      --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
  2. RHACM 2.7 이상에서는 다중 클러스터 엔진에서 기본적으로 cluster-proxy-addon 기능을 활성화합니다. 다음 패치를 적용하여 cluster-proxy-addon 기능을 비활성화하고 이 애드온을 담당하는 관련 허브 클러스터 및 관리 Pod를 제거합니다. 다음 명령을 실행합니다.

    $ oc patch multiclusterengines.multicluster.openshift.io multiclusterengine --type=merge --patch-file out/argocd/deployment/disable-cluster-proxy-addon.json
  3. 다음 명령을 실행하여 허브 클러스터에 파이프라인 구성을 적용합니다.

    $ oc apply -k out/argocd/deployment

18.3.7. GitOps ZTP 구성 변경 사항 롤아웃

권장 변경 사항 구현으로 인해 구성 변경이 업그레이드에 포함된 경우 업그레이드 프로세스에서 hub 클러스터에 정책 CR 세트를 Non-Compliant 상태로 만듭니다. GitOps ZTP(ZTP) 버전 4.10 및 이후 ztp-site-generate 컨테이너를 사용하면 이러한 정책은 정보 모드로 설정되고 사용자가 추가 단계없이 관리 클러스터로 푸시되지 않습니다. 이렇게 하면 변경 사항이 발생하는 시기(예: 유지 관리 기간 중) 및 동시에 업데이트되는 클러스터 수에 따라 클러스터에 잠재적으로 중단될 수 있습니다.

변경 사항을 롤아웃하려면 TALM 설명서에 자세히 설명된 대로 하나 이상의 ClusterGroupUpgrade CR을 생성합니다. CR에는 관리 클러스터로 푸시하려는 비준수 정책 목록과 업데이트에 포함되어야 하는 클러스터 목록 또는 선택기가 포함되어야 합니다.

추가 리소스

18.4. RHACM 및 siteConfig 리소스를 사용하여 관리형 클러스터 설치

지원 서비스 및 core-reduction 기술이 활성화된 GitOps 플러그인 정책 생성기를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 대규모로 OpenShift Container Platform 클러스터를 프로비저닝할 수 있습니다. GitOps ZTP(ZTP) 파이프라인은 클러스터 설치를 수행합니다. GitOps ZTP는 연결이 끊긴 환경에서 사용할 수 있습니다.

18.4.1. GitOps ZTP 및 토폴로지 인식 라이프사이클 관리자

GitOps ZTP(ZTP)는 Git에 저장된 매니페스트에서 설치 및 구성 CR을 생성합니다. 이러한 아티팩트는 RHACM(Red Hat Advanced Cluster Management), 지원 서비스, 토폴로지 Aware Lifecycle Manager(TALM)에서 CR을 사용하여 관리 클러스터를 설치하고 구성하는 중앙 집중식 허브 클러스터에 적용됩니다. GitOps ZTP 파이프라인의 구성 단계는 TALM을 사용하여 구성 CR의 애플리케이션을 클러스터에 오케스트레이션합니다. GitOps ZTP와 TALM 사이에는 몇 가지 주요 통합 지점이 있습니다.

정책 정보
기본적으로 GitOps ZTP는 inform 이라는 수정 작업을 사용하여 모든 정책을 생성합니다. 이러한 정책을 사용하면 RHACM에서 정책과 관련된 클러스터의 규정 준수 상태를 보고하지만 원하는 구성은 적용되지 않습니다. GitOps ZTP 프로세스 중에 OpenShift를 설치한 후 생성된 정보 정책을 통해 TALM을 단계화하고 대상 관리 클러스터에 적용합니다. 이렇게 하면 구성이 관리 클러스터에 적용됩니다. 클러스터 라이프사이클의 GitOps ZTP 단계 외부에서는 해당 변경 사항을 영향을 받는 클러스터로 즉시 롤아웃할 위험이 없는 정책을 변경할 수 있습니다. TALM을 사용하여 수정되는 클러스터 세트와 타이밍을 제어할 수 있습니다.
ClusterGroupUpgrade CR 자동 생성

새로 배포된 클러스터의 초기 구성을 자동화하기 위해 TALM은 hub 클러스터에서 모든 ManagedCluster CR의 상태를 모니터링합니다. 새로 생성된 ManagedCluster CR을 포함하여 ztp-done 레이블이 적용되지 않은 ManagedCluster CR을 사용하면 TALM에서 다음과 같은 특성을 가진 ClusterGroupUpgrade CR을 자동으로 생성합니다.

  • ztp-install 네임스페이스에서 ClusterGroupUpgrade CR이 생성되고 활성화됩니다.
  • ClusterGroupUpgrade CR의 이름은 ManagedCluster CR과 동일합니다.
  • 클러스터 선택기에는 해당 ManagedCluster CR과 연결된 클러스터만 포함됩니다.
  • 관리 정책 세트에는 ClusterGroupUpgrade 가 생성될 때 RHACM이 클러스터에 바인딩한 모든 정책이 포함됩니다.
  • 사전 캐싱은 비활성화되어 있습니다.
  • 시간 초과가 4시간(240분)으로 설정됩니다.

활성화된 ClusterGroupUpgrade 의 자동 생성을 통해 사용자 개입 없이도 초기 무차별 클러스터 배포를 진행할 수 있습니다. 또한 ztp-done 레이블이 없는 ManagedCluster 에 대한 ClusterGroupUpgrade CR을 자동으로 생성하면 클러스터에 대한 ClusterGroupUpgrade CR을 간단히 삭제하여 실패한 GitOps ZTP 설치를 다시 시작할 수 있습니다.

웨이브

PolicyGenTemplate CR에서 생성된 각 정책에는 ztp-deploy-ECDSA 주석이 포함됩니다. 이 주석은 해당 정책에 포함된 각 CR에서 동일한 주석을 기반으로 합니다. 웨이브 주석은 자동 생성된 ClusterGroupUpgrade CR의 정책을 정렬하는 데 사용됩니다. 웨이브 주석은 자동 생성된 ClusterGroupUpgrade CR 이외의 용도로는 사용되지 않습니다.

참고

동일한 정책의 모든 CR에는 ztp-deploy- Cryostat 주석에 대해 동일한 설정이 있어야 합니다. 각 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
단계 레이블

ClusterGroupUpgrade CR이 자동으로 생성되고 GitOps ZTP 프로세스의 시작 및 종료 시 라벨을 사용하여 ManagedCluster CR에 주석을 달 수 있는 지시문이 포함됩니다.

GitOps ZTP 구성 후 설치가 시작되면 ManagedClusterztp-running 레이블이 적용됩니다. 모든 정책이 클러스터에 수정되어 완전히 준수되면 이러한 지시문으로 인해 TALM에서 ztp-running 레이블을 제거하고 ztp-done 레이블을 적용합니다.

informDuValidator 정책을 사용하는 배포의 경우 클러스터가 애플리케이션 배포를 완전히 준비할 때 ztp-done 레이블이 적용됩니다. 여기에는 GitOps ZTP가 적용된 구성 CR의 모든 조정 및 결과 영향이 포함됩니다. ztp-done 레이블은 TALM의 자동 ClusterGroupUpgrade CR 생성에 영향을 미칩니다. 클러스터의 초기 GitOps ZTP 설치 후에는 이 라벨을 조작하지 마십시오.

연결된 CR
자동으로 생성된 ClusterGroupUpgrade CR에는 파생된 ManagedCluster 로 설정된 owner 참조가 있습니다. 이 참조를 사용하면 ManagedCluster CR을 삭제하면 지원되는 리소스와 함께 ClusterGroupUpgrade 인스턴스가 삭제됩니다.

18.4.2. GitOps ZTP를 사용하여 관리형 클러스터 배포 개요

RHACM(Red Hat Advanced Cluster Management)은 GitOps ZTP(ZTP)를 사용하여 단일 노드 OpenShift Container Platform 클러스터, 3노드 클러스터 및 표준 클러스터를 배포합니다. Git 리포지토리에서 사이트 구성 데이터를 OpenShift Container Platform CR(사용자 정의 리소스)으로 관리합니다. GitOps ZTP는 선언적 GitOps 접근 방식을 사용하여 한 번 개발하고 모델을 배포하여 관리 클러스터를 배포합니다.

클러스터 배포에는 다음이 포함됩니다.

  • 빈 서버에 호스트 운영 체제(RHCOS) 설치
  • OpenShift Container Platform 배포
  • 클러스터 정책 및 사이트 서브스크립션 생성
  • 서버 운영 체제에 필요한 네트워크 구성 만들기
  • 프로파일 Operator 배포 및 성능 프로필, PTP 및 SR-IOV와 같은 필요한 소프트웨어 관련 구성 수행
관리 사이트 설치 프로세스 개요

허브 클러스터에 관리 사이트 CR(사용자 정의 리소스)을 적용한 후 다음 작업이 자동으로 수행됩니다.

  1. 검색 이미지 ISO 파일이 생성되어 대상 호스트에서 부팅됩니다.
  2. 대상 호스트에서 ISO 파일이 성공적으로 부팅되면 호스트 하드웨어 정보를 RHACM에 보고합니다.
  3. 모든 호스트가 검색되면 OpenShift Container Platform이 설치됩니다.
  4. OpenShift Container Platform 설치가 완료되면 허브가 대상 클러스터에 klusterlet 서비스를 설치합니다.
  5. 요청된 애드온 서비스가 대상 클러스터에 설치되어 있습니다.

hub 클러스터에서 관리 클러스터의 Agent CR이 생성되면 Discovery 이미지 ISO 프로세스가 완료됩니다.

중요

대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대해 권장 단일 노드 OpenShift 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.

18.4.3. 관리형 베어 메탈 호스트 시크릿 생성

관리 베어 메탈 호스트에 필요한 Secret CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. BMC(Baseboard Management Controller)에 액세스하려면 GitOps ZTP(ZTP) 파이프라인의 시크릿과 지원되는 설치 프로그램 서비스에서 레지스트리에서 클러스터 설치 이미지를 가져오는 시크릿이 필요합니다.

참고

보안은 site Config CR에서 이름으로 참조됩니다. 네임스페이스는 site Config 네임스페이스와 일치해야 합니다.

프로세스

  1. OpenShift 및 모든 추가 기능 클러스터 Operator 설치에 필요한 호스트 BMC(Baseboard Management Controller)에 대한 인증 정보와 풀 시크릿을 포함하는 YAML 시크릿 파일을 생성합니다.

    1. 다음 YAML을 example-sno-secret.yaml 파일로 저장합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson
      1
      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.
      2
      암호사용자이름에 대한 base64로 인코딩된 값
      3
      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.
      4
      base64로 인코딩된 풀 시크릿
  2. 클러스터를 설치하는 데 사용하는 kustomization.yaml 파일에 example-sno-secret.yaml 에 상대 경로를 추가합니다.

18.4.4. GitOps ZTP를 사용하여 설치를 위한 Discovery ISO 커널 인수 구성

GitOps ZTP(ZTP) 워크플로는 관리형 베어 메탈 호스트에서 OpenShift Container Platform 설치 프로세스의 일부로 Discovery ISO를 사용합니다. InfraEnv 리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어 클러스터의 정적 네트워킹을 용이하게 하거나 설치 중에 루트 파일 시스템을 다운로드하기 전에 DHCP 주소를 수신하도록 Discovery ISO에 rd.net.timeout.carrier 커널 인수를 구성합니다.

참고

OpenShift Container Platform 4.14에서는 커널 인수만 추가할 수 있습니다. 커널 인수를 교체하거나 삭제할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. InfraEnv CR을 생성하고 spec.kernelArguments 사양을 편집하여 커널 인수를 구성합니다.

    1. 다음 YAML을 InfraEnv-example.yaml 파일에 저장합니다.

      참고

      이 예제의 InfraEnv CR은 site Config CR의 값에 따라 채워진 {{ .Cluster.ClusterName }} 과 같은 템플릿 구문을 사용합니다. SiteConfig CR은 배포 중에 이러한 템플릿의 값을 자동으로 채웁니다. 템플릿을 수동으로 편집하지 마십시오.

      apiVersion: agent-install.openshift.io/v1beta1
      kind: InfraEnv
      metadata:
        annotations:
          argocd.argoproj.io/sync-wave: "1"
        name: "{{ .Cluster.ClusterName }}"
        namespace: "{{ .Cluster.ClusterName }}"
      spec:
        clusterRef:
          name: "{{ .Cluster.ClusterName }}"
          namespace: "{{ .Cluster.ClusterName }}"
        kernelArguments:
          - operation: append 1
            value: audit=0 2
          - operation: append
            value: trace=1
        sshAuthorizedKey: "{{ .Site.SshPublicKey }}"
        proxy: "{{ .Cluster.ProxySettings }}"
        pullSecretRef:
          name: "{{ .Site.PullSecretRef.Name }}"
        ignitionConfigOverride: "{{ .Cluster.IgnitionConfigOverride }}"
        nmStateConfigLabelSelector:
          matchLabels:
            nmstate-label: "{{ .Cluster.ClusterName }}"
        additionalNTPSources: "{{ .Cluster.AdditionalNTPSources }}"
      1
      커널 인수를 추가하려면 추가 작업을 지정합니다.
      2
      구성할 커널 인수를 지정합니다. 이 예제에서는 audit 커널 인수와 trace 커널 인수를 구성합니다.
  2. InfraEnv-example.yaml CR을 site Config CR이 있는 Git 리포지토리의 동일한 위치에 커밋하고 변경 사항을 내보냅니다. 다음 예제에서는 샘플 Git 리포지토리 구조를 보여줍니다.

    ~/example-ztp/install
              └── site-install
                   ├── siteconfig-example.yaml
                   ├── InfraEnv-example.yaml
                   ...
  3. SiteConfig CR에서 spec.clusters.crTemplates 사양을 편집하여 Git 리포지토리의 InfraEnv-example.yaml CR을 참조합니다.

    clusters:
      crTemplates:
        InfraEnv: "InfraEnv-example.yaml"

    SiteConfig CR을 커밋하고 푸시하여 클러스터를 배포할 준비가 되면 빌드 파이프라인은 Git 리포지토리의 사용자 지정 InfraEnv-example CR을 사용하여 사용자 지정 커널 인수를 포함하여 인프라 환경을 구성합니다.

검증

커널 인수가 적용되었는지 확인하려면 검색 이미지에서 OpenShift Container Platform을 설치할 준비가 되었는지 확인한 후 설치 프로세스가 시작되기 전에 대상 호스트에 SSH를 수행할 수 있습니다. 이때 /proc/cmdline 파일에서 Discovery ISO의 커널 인수를 볼 수 있습니다.

  1. 대상 호스트를 사용하여 SSH 세션을 시작합니다.

    $ ssh -i /path/to/privatekey core@<host_name>
  2. 다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.

    $ cat /proc/cmdline

18.4.5. SiteConfig 및 GitOps ZTP를 사용하여 관리형 클러스터 배포

다음 절차에 따라 SiteConfig CR(사용자 정의 리소스) 및 관련 파일을 생성하고 ZTP( GitOps Zero Touch Provisioning) 클러스터 배포를 시작합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD 애플리케이션의 소스 리포지토리로 구성해야 합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.

    참고

    소스 리포지토리를 생성할 때 ztp-site-generate 컨테이너에서 추출한 argocd/deployment/argocd-openshift-gitops-patch.json patch-file을 사용하여 ArgoCD 애플리케이션을 패치하는지 확인합니다. " ArgoCD를 사용하여 허브 클러스터 구성"을 참조하십시오.

  • 관리 클러스터 프로비저닝을 준비하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.

    네트워크 연결
    네트워크에는 DNS가 필요합니다. 허브 클러스터에서 관리 클러스터 호스트에 연결할 수 있어야 합니다. hub 클러스터와 관리 클러스터 호스트 간에 계층 3 연결이 있는지 확인합니다.
    BMC(Baseboard Management Controller) 세부 정보
    GitOps ZTP는 BMC 사용자 이름과 암호 세부 정보를 사용하여 클러스터 설치 중에 BMC에 연결합니다. GitOps ZTP 플러그인은 사이트 Git 리포지토리의 site Config CR을 기반으로 Hub 클러스터에서 ManagedCluster CR을 관리합니다. 각 호스트에 대해 수동으로 개별 BMCSecret CR을 생성합니다.

    프로세스

    1. hub 클러스터에 필요한 관리 클러스터 시크릿을 생성합니다. 이러한 리소스는 클러스터 이름과 일치하는 이름이 있는 네임스페이스에 있어야 합니다. 예를 들어 out/argocd/example/siteconfig/example-sno.yaml 에서 클러스터 이름과 네임스페이스는 example-sno 입니다.

      1. 다음 명령을 실행하여 클러스터 네임스페이스를 내보냅니다.

        $ export CLUSTERNS=example-sno
      2. 네임스페이스를 생성합니다.

        $ oc create namespace $CLUSTERNS
    2. 관리 클러스터에 대한 풀 시크릿 및 BMC Secret CR을 생성합니다. 풀 시크릿에는 OpenShift Container Platform 및 필요한 모든 Operator를 설치하는 데 필요한 모든 인증 정보가 포함되어야 합니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.

      참고

      보안은 site Config CR(사용자 정의 리소스)에서 이름으로 참조됩니다. 네임스페이스는 site Config 네임스페이스와 일치해야 합니다.

    3. Git 리포지토리의 로컬 복제본에 클러스터의 site Config CR을 생성합니다.

      1. out/argocd/example/siteconfig/ 폴더에서 CR에 적합한 예제를 선택합니다. 폴더에는 단일 노드, 3-노드 및 표준 클러스터에 대한 예제 파일이 포함되어 있습니다.

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml
      2. 예제 파일의 클러스터 및 호스트 세부 정보를 원하는 클러스터 유형과 일치하도록 변경합니다. 예를 들면 다음과 같습니다.

        단일 노드 OpenShift SiteConfig CR의 예

        # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
        ---
        apiVersion: ran.openshift.io/v1
        kind: 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..."
          clusters:
          - clusterName: "example-sno"
            networkType: "OVNKubernetes"
            # installConfigOverrides is a generic way of passing install-config
            # parameters through the siteConfig.  The 'capabilities' field configures
            # the composable openshift feature.  In this 'capabilities' setting, we
            # remove all but the marketplace component from the optional set of
            # components.
            # Notes:
            # - OperatorLifecycleManager is needed for 4.15 and later
            # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
            installConfigOverrides: |
              {
                "capabilities": {
                  "baselineCapabilitySet": "None",
                  "additionalEnabledCapabilities": [
                    "NodeTuning",
                    "OperatorLifecycleManager"
                  ]
                }
              }
            # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
            # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
            # extraManifestPath: sno-extra-manifest
            clusterLabels:
              # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
              du-profile: "latest"
              # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
              # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
              common: true
              # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
              group-du-sno: ""
              # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
              # Normally this should match or contain the cluster name so it only applies to a single cluster
              sites : "example-sno"
            clusterNetwork:
              - cidr: 1001:1::/48
                hostPrefix: 64
            machineNetwork:
              - cidr: 1111:2222:3333:4444::/64
            serviceNetwork:
              - 1001:2::/112
            additionalNTPSources:
              - 1111:2222:3333:4444::2
            # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
            # please see Workload Partitioning Feature for a complete guide.
            cpuPartitioningMode: AllNodes
            # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
            #crTemplates:
            #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
            nodes:
              - hostName: "example-node1.example.com"
                role: "master"
                # Optionally; This can be used to configure desired BIOS setting on a host:
                #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:BB:CC:DD:EE:11"
                # Use UEFISecureBoot to enable secure boot
                bootMode: "UEFI"
                rootDeviceHints:
                  deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
                # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
                ignitionConfigOverride: |
                   {
                    "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"
                       }
                      ]
                    }
                   }
                nodeNetwork:
                  interfaces:
                    - name: eno1
                      macAddress: "AA:BB:CC:DD:EE:11"
                  config:
                    interfaces:
                      - name: eno1
                        type: ethernet
                        state: up
                        ipv4:
                          enabled: false
                        ipv6:
                          enabled: true
                          address:
                          # For SNO sites with static IP addresses, the node-specific,
                          # API and Ingress IPs should all be the same and configured on
                          # the interface
                          - ip: 1111:2222:3333:4444::aaaa:1
                            prefix-length: 64
                    dns-resolver:
                      config:
                        search:
                        - example.com
                        server:
                        - 1111:2222:3333:4444::2
                    routes:
                      config:
                      - destination: ::/0
                        next-hop-interface: eno1
                        next-hop-address: 1111:2222:3333:4444::1
                        table-id: 254

        참고

        BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오. installConfigOverridesignitionConfigOverride 필드는 쉽게 읽을 수 있도록 확장됩니다.

      3. 외부/argocd/extra-manifest에서 기본 extra-manifest MachineConfig CR 세트를 검사할 수 있습니다. 설치 시 클러스터에 자동으로 적용됩니다.
      4. 선택 사항: 프로비저닝된 클러스터에서 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리를 생성하고 (예: sno-extra-manifest/ ) 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다. SiteConfig.yamlextraManifestPath 필드의 이 디렉터리를 참조하는 경우 이 참조 디렉터리의 모든 CR이 기본 추가 매니페스트 세트에 추가됩니다.

        crun OCI 컨테이너 런타임 활성화

        최적의 클러스터 성능을 위해서는 단일 노드 OpenShift에서 마스터 및 작업자 노드에 대해 crun, 추가 작업자 노드가 있는 단일 노드 OpenShift, 3-노드 OpenShift 및 표준 클러스터를 활성화합니다.

        클러스터를 재부팅하지 않도록 ContainerRuntimeConfig CR에서 0일 추가 설치 시간 매니페스트로 crun을 활성화합니다.

        enable-crun-master.yamlenable-crun-worker.yaml CR 파일은 ztp-site-generate 컨테이너에서 추출할 수 있는 out/source-crs/optional-extra-manifest/ 폴더에 있습니다. 자세한 내용은 " GitOps ZTP 파이프라인의 추가 설치 매니페스트 사용자 지정"을 참조하십시오.

    4. out/argocd/example/siteconfig/ kustomization.yaml 과 유사하게 generators 섹션의 kustomization.yaml 파일에 SiteConfig CR을 추가합니다.
    5. Git 리포지토리에서 SiteConfig CR 및 관련 kustomization.yaml 변경 사항을 커밋하고 변경 사항을 내보냅니다.

      ArgoCD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다.

검증

  • 노드가 배포된 후 사용자 정의 역할 및 라벨이 적용되는지 확인합니다.

    $ oc describe node example-node.example.com

출력 예

Name:   example-node.example.com
Roles:  control-plane,example-label,master,worker
Labels: beta.kubernetes.io/arch=amd64
        beta.kubernetes.io/os=linux
        custom-label/parameter1=true
        kubernetes.io/arch=amd64
        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
        kubernetes.io/os=linux
        node-role.kubernetes.io/control-plane=
        node-role.kubernetes.io/example-label= 1
        node-role.kubernetes.io/master=
        node-role.kubernetes.io/worker=
        node.openshift.io/os_id=rhcos

1
사용자 정의 레이블이 노드에 적용됩니다.
18.4.5.1. 단일 노드 OpenShift SiteConfig CR 설치 참조
표 18.8. 단일 노드 OpenShift 클러스터에 대한 SiteConfig CR 설치 옵션
siteConfig CR 필드설명

spec.cpuPartitioningMode

cpu CryostatingMode 값을 AllNodes 로 설정하여 워크로드 파티셔닝을 구성합니다. 구성을 완료하려면 PerformanceProfile CR에서 분리된 CPU와 예약된 CPU를 지정합니다.

참고

SiteConfig CR에서 cpu CryostatingMode 필드를 사용하여 워크로드 파티셔닝을 구성하는 것은 OpenShift Container Platform 4.13의 기술 프리뷰 기능입니다.

metadata.name

nameassisted-deployment-pull-secret 으로 설정하고 site Config CR과 동일한 네임스페이스에 assisted-deployment-pull-secret CR 을 생성합니다.

spec.clusterImageSetNameRef

사이트의 모든 클러스터에 대해 hub 클러스터에서 사용 가능한 이미지 세트를 구성합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 oc get clusterimagesets 를 실행합니다.

installConfigOverrides

클러스터 설치 전에 선택적 구성 요소를 활성화하거나 비활성화하려면 installConfigOverrides 필드를 설정합니다.

중요

예제 SiteConfig CR에 지정된 대로 참조 구성을 사용합니다. 시스템에 추가 구성 요소를 추가하려면 추가로 예약된 CPU 용량이 필요할 수 있습니다.

spec.clusters.clusterImageSetNameRef

개별 클러스터를 배포하는 데 사용되는 클러스터 이미지 세트를 지정합니다. 정의된 경우 사이트 수준에서 spec.clusterImageSetNameRef 를 덮어씁니다.

spec.clusters.clusterLabels

사용자가 정의한 PolicyGenTemplate CR의 bindingRules 필드에 해당하도록 클러스터 레이블을 구성합니다. 예를 들어 policygentemplates/common-ranGen.yamlcommon: true 가 설정된 모든 클러스터에 적용됩니다. policygentemplates/group-du-sno-ranGen.yamlgroup-du-sno: "" 가 설정된 모든 클러스터에 적용됩니다.

spec.clusters.crTemplates.KlusterletAddonConfig

선택 사항: KlusterletAddonConfigKlusterletAddonConfig로 설정하여 클러스터에 생성된 기본 'KlusterletAddonConfig를 재정의합니다.

spec.clusters.nodes.hostName

단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 세 개의 호스트를 정의합니다. 표준 배포의 경우 역할이 있는 세 개의 호스트( master 및 role: worker )로 정의된 두 개 이상의 호스트를 정의합니다.

spec.clusters.nodes.nodeLabels

관리 클러스터에서 노드의 사용자 지정 역할을 지정합니다. 추가 역할은 사용자만 OpenShift Container Platform 구성 요소에서 사용하지 않습니다. 사용자 지정 역할을 추가하면 해당 역할의 특정 구성을 참조하는 사용자 지정 머신 구성 풀과 연결할 수 있습니다. 설치 중에 사용자 정의 레이블 또는 역할을 추가하면 배포 프로세스가 더 효과적이며 설치가 완료된 후 추가 재부팅이 필요하지 않습니다.

spec.clusters.nodes.automatedCleaningMode

선택 사항: 디스크를 완전히 삭제하지 않고 값의 주석을 metadata 로 설정하여 디스크 파티션 테이블만 제거할 수 있습니다. 기본값은 disabled 입니다.

spec.clusters.nodes.bmcAddress

호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.

spec.clusters.nodes.bmcAddress

호스트에 액세스하는 데 사용하는 BMC 주소입니다. 모든 클러스터 유형에 적용됩니다. GitOps ZTP는 Redfish 또는 IPMI 프로토콜을 사용하여 iPXE 및 가상 미디어 부팅을 지원합니다. iPXE 부팅을 사용하려면 RHACM 2.8 이상을 사용해야 합니다. BMC 주소 지정에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.

참고

지금까지 엣지 Telco 사용 사례에서는 GitOps ZTP에서 사용할 수 있도록 가상 미디어만 지원됩니다.

spec.clusters.nodes.bmcCredentialsName

호스트 BMC 인증 정보를 사용하여 별도로 생성하는 bmh-secret CR을 구성합니다. bmh-secret CR을 생성할 때 호스트를 프로비저닝하는 SiteConfig CR과 동일한 네임스페이스를 사용합니다.

spec.clusters.nodes.bootMode

호스트의 부팅 모드를 UEFI 로 설정합니다. 기본값은 UEFI 입니다. UEFISecureBoot 를 사용하여 호스트에서 보안 부팅을 활성화합니다.

spec.clusters.nodes.rootDeviceHints

배포 장치를 지정합니다. 재부팅 시 안정적인 식별자를 사용하는 것이 좋습니다. 예를 들어 wwn: <disk_wwn> 또는 deviceName: /dev/disk/by-path/<device_path >. <by-path& gt; 값이 선호됩니다. 안정적인 식별자의 자세한 목록은 "루트 장치 팁 정보" 섹션을 참조하십시오.

spec.clusters.nodes.ignitionConfigOverride

선택 사항: 이 필드를 사용하여 영구 스토리지의 파티션을 할당합니다. 디스크 ID와 크기를 특정 하드웨어에 조정합니다.

spec.clusters.nodes.nodeNetwork

노드의 네트워크 설정을 구성합니다.

spec.clusters.nodes.nodeNetwork.config.interfaces.ipv6

호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다.

18.4.6. 관리형 클러스터 설치 진행 상황 모니터링

ArgoCD 파이프라인은 site Config CR을 사용하여 클러스터 구성 CR을 생성하고 Hub 클러스터와 동기화합니다. ArgoCD 대시보드에서 동기화의 진행 상황을 모니터링할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

동기화가 완료되면 설치는 일반적으로 다음과 같이 진행됩니다.

  1. Assisted Service Operator는 클러스터에 OpenShift Container Platform을 설치합니다. 다음 명령을 실행하여 RHACM 대시보드 또는 명령줄에서 클러스터 설치 진행 상황을 모니터링할 수 있습니다.

    1. 클러스터 이름을 내보냅니다.

      $ export CLUSTER=<clusterName>
    2. 관리 클러스터의 AgentClusterInstall CR을 쿼리합니다.

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
    3. 클러스터의 설치 이벤트를 가져옵니다.

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

18.4.7. 설치 CR을 검증하여 GitOps ZTP 문제 해결

ArgoCD 파이프라인은 site ConfigPolicyGenTemplate CR(사용자 정의 리소스)을 사용하여 클러스터 구성 CR 및 RHACM(Red Hat Advanced Cluster Management) 정책을 생성합니다. 이 프로세스 중에 발생할 수 있는 문제를 해결하려면 다음 단계를 사용하십시오.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. 다음 명령을 사용하여 설치 CR이 생성되었는지 확인합니다.

    $ oc get AgentClusterInstall -n <cluster_name>

    오브젝트가 반환되지 않은 경우 다음 단계를 사용하여 SiteConfig 파일에서 설치 CR로 ArgoCD 파이프라인 흐름의 문제를 해결합니다.

  2. hub 클러스터의 SiteConfig CR을 사용하여 ManagedCluster CR이 생성되었는지 확인합니다.

    $ oc get managedcluster
  3. ManagedCluster 가 없는 경우 클러스터 애플리케이션이 Git 리포지토리의 파일을 hub 클러스터와 동기화하지 않았는지 확인합니다.

    $ oc describe -n openshift-gitops application clusters
    1. Status.Conditions 필드를 확인하여 관리 클러스터의 오류 로그를 확인합니다. 예를 들어, SiteConfig CR에서 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:  ComparisonError
    2. Status.Sync 필드를 확인합니다. 로그 오류가 있는 경우 Status.Sync 필드에 알 수 없는 오류가 표시될 수 있습니다.

      Status:
        Sync:
          Compared To:
            Destination:
              Namespace:  clusters-sub
              Server:     https://kubernetes.default.svc
            Source:
              Path:             sites-config
              Repo URL:         https://git.com/ran-sites/siteconfigs/.git
              Target Revision:  master
          Status:               Unknown

18.4.8. Supermicro 서버에서 GitOps ZTP 가상 미디어 부팅 문제 해결

Supermicro X11 서버는 https 프로토콜을 사용하여 이미지를 제공하는 경우 가상 미디어 설치를 지원하지 않습니다. 결과적으로 이 환경의 단일 노드 OpenShift 배포가 대상 노드에서 부팅되지 않습니다. 이 문제를 방지하려면 hub 클러스터에 로그인하고 프로비저닝 리소스에서 TLS(Transport Layer Security)를 비활성화합니다. 이렇게 하면 이미지 주소가 https 스키마를 사용하더라도 TLS로 이미지가 제공되지 않습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. 다음 명령을 실행하여 프로비저닝 리소스에서 TLS를 비활성화합니다.

    $ oc patch provisioning provisioning-configuration --type merge -p '{"spec":{"disableVirtualMediaTLS": true}}'
  2. 단일 노드 OpenShift 클러스터를 배포하려면 단계를 계속합니다.

18.4.9. GitOps ZTP 파이프라인에서 관리되는 클러스터 사이트 제거

GitOps ZTP(ZTP) 파이프라인에서 관리 사이트 및 관련 설치 및 구성 정책 CR을 제거할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. kustomization.yaml 파일에서 관련 SiteConfigPolicyGenTemplate 파일을 제거하여 사이트 및 관련 CR을 제거합니다.
  2. SiteConfig 애플리케이션에 다음 syncOptions 필드를 추가합니다.

    kind: Application
    spec:
      syncPolicy:
        syncOptions:
        - PrunePropagationPolicy=background

    GitOps ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.

  3. 선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site Config 및 사이트별 PolicyGenTemplate 파일을 제거해야 합니다.
  4. 선택 사항: 예를 들어 사이트를 재배포할 때 사이트를 일시적으로 제거하려면 site Config 및 사이트PolicyGenTemplate CR을 Git 리포지토리에 남겨 둘 수 있습니다.

추가 리소스

18.4.10. GitOps ZTP 파이프라인에서 더 이상 사용되지 않는 콘텐츠 제거

PolicyGenTemplate 구성을 변경하면 더 이상 사용되지 않는 정책이 생성되는 경우(예: 정책 이름 변경) 다음 절차를 사용하여 더 이상 사용되지 않는 정책을 제거합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. Git 리포지토리에서 영향을 받는 PolicyGenTemplate 파일을 제거하고 원격 리포지토리를 커밋하고 내보냅니다.
  2. 변경 사항이 애플리케이션을 통해 동기화되고 영향을 받는 정책이 허브 클러스터에서 제거될 때까지 기다립니다.
  3. 업데이트된 PolicyGenTemplate 파일을 Git 리포지토리에 다시 추가한 다음 원격 리포지토리를 커밋하고 내보냅니다.

    참고

    Git 리포지토리에서 GitOps Zero Touch Provisioning(ZTP) 정책을 제거하면 허브 클러스터에서도 해당 정책을 제거해도 관리 클러스터의 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리 클러스터에 남아 있습니다.

  4. 선택 사항: 대신 더 이상 사용되지 않는 정책을 생성하는 PolicyGenTemplate CR을 변경한 후 hub 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.

    $ oc delete policy -n <namespace> <policy_name>

18.4.11. GitOps ZTP 파이프라인 종료

ArgoCD 파이프라인 및 생성된 모든 ZTP(ZTP) 아티팩트를 제거할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.
  2. 다음 명령을 사용하여 배포 디렉터리에서 kustomization.yaml 파일을 삭제합니다.

    $ oc delete -k out/argocd/deployment
  3. 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.

18.5. 정책 및 PolicyGenTemplate 리소스를 사용하여 관리형 클러스터 구성

적용된 정책 CR(사용자 정의 리소스)은 사용자가 프로비저닝하는 관리 클러스터를 구성합니다. RHACM(Red Hat Advanced Cluster Management)에서 PolicyGenTemplate CR을 사용하여 적용된 정책 CR을 생성하는 방법을 사용자 지정할 수 있습니다.

18.5.1. PolicyGenTemplate CRD 정보

PolicyGenTemplate CRD(사용자 정의 리소스 정의)는 PolicyGen 정책 생성기에 클러스터 구성에 포함할 사용자 정의 리소스(CR), 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.yamlbindingRules 섹션에 나열된 레이블을 기반으로 정책을 클러스터에 바인딩하는 단일 배치 바인딩 및 배치 규칙을 생성합니다.

예: PolicyGenTemplate CR - common-du-ranGen.yaml

---
apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "common"
  namespace: "ztp-common"
spec:
  bindingRules:
    common: "true" 1
  sourceFiles: 2
    - fileName: SriovSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogNS.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageNS.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ReduceMonitoringFootprint.yaml
      policyName: "config-policy"
    - fileName: OperatorHub.yaml 3
      policyName: "config-policy"
    - fileName: DefaultCatsrc.yaml 4
      policyName: "config-policy" 5
      metadata:
        name: redhat-operators
      spec:
        displayName: disconnected-redhat-operators
        image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
    - fileName: DisconnectedICSP.yaml
      policyName: "config-policy"
      spec:
        repositoryDigestMirrors:
        - mirrors:
          - registry.example.com:5000
          source: registry.redhat.io

1
Common: "true" 는 이 레이블이 있는 모든 클러스터에 정책을 적용합니다.
2
sourceFiles 아래에 나열된 파일은 설치된 클러스터에 대한 Operator 정책을 생성합니다.
3
OperatorHub.yaml 은 연결이 끊긴 레지스트리에 대한 OperatorHub를 구성합니다.
4
DefaultCatsrc.yaml 은 연결이 끊긴 레지스트리의 카탈로그 소스를 구성합니다.
5
PolicyName: "config-policy" 는 Operator 서브스크립션을 구성합니다. OperatorHub CR은 기본값을 비활성화하고 이 CR은 연결이 끊긴 레지스트리를 가리키는 CatalogSource CR로 redhat-operators 를 대체합니다.

PolicyGenTemplate CR은 포함된 CR 수를 사용하여 구성할 수 있습니다. hub 클러스터에 다음 예제 CR을 적용하여 단일 CR을 포함하는 정책을 생성합니다.

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-du-sno"
  namespace: "ztp-group"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  sourceFiles:
    - fileName: PtpConfigSlave.yaml
      policyName: "config-policy"
      metadata:
        name: "du-ptp-slave"
      spec:
        profile:
        - name: "slave"
          interface: "ens5f0"
          ptp4lOpts: "-2 -s --summary_interval -4"
          phc2sysOpts: "-a -r -n 24"

소스 파일 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을 보여줍니다.

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: group-du-ptp-config-policy
  namespace: groups-sub
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
spec:
    remediationAction: inform
    disabled: false
    policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
                name: group-du-ptp-config-policy-config
            spec:
                remediationAction: inform
                severity: low
                namespaceselector:
                    exclude:
                        - kube-*
                    include:
                        - '*'
                object-templates:
                    - complianceType: musthave
                      objectDefinition:
                        apiVersion: ptp.openshift.io/v1
                        kind: PtpConfig
                        metadata:
                            name: du-ptp-slave
                            namespace: openshift-ptp
                        spec:
                            recommend:
                                - match:
                                - nodeLabel: node-role.kubernetes.io/worker-du
                                  priority: 4
                                  profile: slave
                            profile:
                                - interface: ens5f0
                                  name: slave
                                  phc2sysOpts: -a -r -n 24
                                  ptp4lConf: |
                                    [global]
                                    #
                                    # Default Data Set
                                    #
                                    twoStepFlag 1
                                    slaveOnly 0
                                    priority1 128
                                    priority2 128
                                    domainNumber 24
                                    .....

18.5.2. PolicyGenTemplate CR을 사용자 정의할 때 권장 사항

사이트 구성 PolicyGenTemplate CR(사용자 정의 리소스)을 사용자 정의할 때 다음과 같은 모범 사례를 고려하십시오.

  • 필요한 만큼의 정책을 사용하십시오. 정책을 더 적게 사용하려면 더 적은 리소스가 필요합니다. 각 추가 정책은 허브 클러스터 및 배포된 관리 클러스터에 대한 오버헤드를 생성합니다. CR은 PolicyGenTemplate CR의 policyName 필드를 기반으로 정책에 결합됩니다. policyName 에 동일한 값이 있는 동일한 PolicyGenTemplate 의 CR은 단일 정책으로 관리됩니다.
  • 연결이 끊긴 환경에서는 모든 Operator가 포함된 단일 인덱스로 레지스트리를 구성하여 모든 Operator에 대해 단일 카탈로그 소스를 사용합니다. 관리 클러스터의 각 추가 CatalogSource CR은 CPU 사용량을 늘립니다.
  • MachineConfig CR은 설치 중에 적용되도록 SiteConfig CR에서 extraManifests 로 포함되어야 합니다. 이를 통해 클러스터가 애플리케이션을 배포할 준비가 될 때까지 걸리는 전체 시간을 줄일 수 있습니다.
  • PolicyGenTemplates 는 원하는 버전을 명시적으로 식별하도록 channel 필드를 재정의해야 합니다. 이렇게 하면 업그레이드 중에 소스 CR의 변경이 생성된 서브스크립션을 업데이트하지 않습니다.

추가 리소스

  • RHACM을 사용한 클러스터 스케일링에 대한 권장 사항은 성능 및 확장성을 참조하십시오.
참고

허브 클러스터에서 많은 수의 음성 클러스터를 관리할 때 정책 수를 최소화하여 리소스 소비를 줄입니다.

여러 구성 CR을 단일 또는 제한된 정책으로 그룹화하는 것이 허브 클러스터의 전체 정책 수를 줄이는 한 가지 방법입니다. 사이트 구성을 관리하기 위한 공통, 그룹 및 사이트 계층 구조를 사용하는 경우 사이트별 구성을 단일 정책으로 결합하는 것이 특히 중요합니다.

18.5.3. RAN 배포를 위한 PolicyGenTemplate CR

PBT( PolicyGenTemplate ) 사용자 정의 리소스(CR)를 사용하여ZTP( GitOps Zero Touch Provisioning) 파이프라인을 사용하여 클러스터에 적용되는 구성을 사용자 지정합니다. 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은 다음과 같습니다. 단일 노드, 3-노드 컴팩트 및 표준 클러스터 구성의 차이점을 고려하여 PolicyGenTemplate CR 그룹에 변형이 제공됩니다. 마찬가지로 단일 노드 클러스터 및 다중 노드(콤팩트 또는 표준) 클러스터에 대해 사이트별 구성 변형이 제공됩니다. 배포와 관련된 그룹 및 사이트별 구성 변형을 사용합니다.

표 18.9. RAN 배포를 위한 PolicyGenTemplate CR
PolicyGenTemplate CR설명

example-multinode-site.yaml

다중 노드 클러스터에 적용되는 CR 세트를 포함합니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다.

example-sno-site.yaml

단일 노드 OpenShift 클러스터에 적용되는 CR 세트를 포함합니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다.

common-ranGen.yaml

모든 클러스터에 적용되는 공통 RAN CR 세트를 포함합니다. 이러한 CR은 RAN 및 기본 클러스터 튜닝에 일반적인 클러스터 기능을 제공하는 Operator 세트에 서브스크립션합니다.

group-du-3node-ranGen.yaml

3-노드 클러스터에 대한 RAN 정책만 포함합니다.

group-du-sno-ranGen.yaml

단일 노드 클러스터에 대한 RAN 정책만 포함합니다.

group-du-standard-ranGen.yaml

표준 세 개의 컨트롤 플레인 클러스터에 대한 RAN 정책을 포함합니다.

group-du-3node-validator-ranGen.yaml

3-노드 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 PolicyGenTemplate CR입니다.

group-du-standard-validator-ranGen.yaml

표준 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 PolicyGenTemplate CR입니다.

group-du-sno-validator-ranGen.yaml

단일 노드 OpenShift 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 PolicyGenTemplate CR입니다.

18.5.4. PolicyGenTemplate CR을 사용하여 관리 클러스터 사용자 정의

다음 절차에 따라 ZTP(ZTP) 파이프라인을 사용하여 프로비저닝하는 관리 클러스터에 적용할 수 있는 정책을 사용자 지정할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. 사이트별 구성 CR에 대한 PolicyGenTemplate CR을 생성합니다.

    1. out/argocd/example/policygentemplates 폴더에서 CR에 대한 적절한 예를 선택합니다(예: example-sno-site.yaml 또는 example-multinode-site.yaml ).
    2. 예제 파일의 bindingRules 필드를 site Config CR에 포함된 사이트별 레이블과 일치하도록 변경합니다. 예제 SiteConfig 파일에서 사이트별 레이블은 sites: example-sno 입니다.

      참고

      PolicyGenTemplate bindingRules 필드에 정의된 라벨이 관련 관리 클러스터 site Config CR에 정의된 라벨에 해당하는지 확인합니다.

    3. 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.
  2. 선택 사항: 전체 클러스터에 적용되는 일반적인 구성 CR에 대한 PolicyGenTemplate CR을 생성합니다.

    1. out/argocd/example/policygentemplates 폴더에서 CR에 대한 적절한 예를 선택합니다(예: common-ranGen.yaml ).
    2. 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.
  3. 선택 사항: 플릿의 특정 클러스터 그룹에 적용되는 모든 그룹 구성 CR에 대해 PolicyGenTemplate CR을 생성합니다.

    overlaid 사양 파일의 내용이 원하는 최종 상태와 일치하는지 확인합니다. 참조로 out/source-crs 디렉터리에는 PolicyGenTemplate 템플릿에서 포함할 수 있는 source-crs의 전체 목록이 포함되어 있습니다.

    참고

    클러스터의 특정 요구 사항에 따라 클러스터 유형당 단일 그룹 정책이 필요할 수 있습니다. 특히 예제 그룹 정책에는 각각 동일한 하드웨어 구성으로 구성된 클러스터 집합에서만 공유할 수 있는 단일 PerformancePolicy.yaml 파일이 있습니다.

    1. out/argocd/example/policygentemplates 폴더에서 CR에 대한 적절한 예를 선택합니다(예: group-du-sno-ranGen.yaml ).
    2. 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.
  4. 선택 사항: 배포된 클러스터의 GitOps ZTP 설치 및 구성이 완료되면 정책 PolicyGenTemplate CR을 생성합니다. 자세한 내용은 "검토 확인 정보 정책 생성"을 참조하십시오.
  5. example out/argocd/example/policygentemplates/ns.yaml 파일과 유사한 YAML 파일에서 모든 정책 네임스페이스를 정의합니다.

    중요

    PolicyGenTemplate CR과 동일한 파일에 Namespace CR을 포함하지 마십시오.

  6. out/argocd/example/policygentemplates/ kustomization.yaml 에 표시된 예제와 유사하게 PolicyGenTemplate CR 및 Namespace CR을 generators 섹션의 kustomization.yaml 파일에 추가합니다.
  7. Git 리포지토리에서 PolicyGenTemplate CR, Namespace CR 및 관련 kustomization.yaml 파일을 커밋하고 변경 사항을 내보냅니다.

    ArgoCD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다. 변경 사항을 SiteConfig CR 및 PolicyGenTemplate CR에 동시에 푸시할 수 있습니다.

18.5.5. 관리형 클러스터 정책 배포 진행 상황 모니터링

ArgoCD 파이프라인은 Git의 PolicyGenTemplate CR을 사용하여 RHACM 정책을 생성한 다음 hub 클러스터에 동기화합니다. 지원 서비스가 관리형 클러스터에 OpenShift Container Platform을 설치한 후 관리 클러스터 정책 동기화의 진행 상황을 모니터링할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. Topology Aware Lifecycle Manager(TALM)는 클러스터에 바인딩된 구성 정책을 적용합니다.

    클러스터 설치가 완료되고 클러스터가 Ready 가 되면 ran.openshift.io/ztp-deploy-ECDHE 주석에 의해 정의된 정렬된 정책 목록과 함께 이 클러스터에 해당하는 ClusterGroupUpgrade CR이 TALM에 의해 자동으로 생성됩니다. 클러스터의 정책은 ClusterGroupUpgrade CR에 나열된 순서대로 적용됩니다.

    다음 명령을 사용하여 구성 정책 조정의 고급 진행 상황을 모니터링할 수 있습니다.

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

    출력 예

    {
      "lastTransitionTime": "2022-11-09T07:28:09Z",
      "message": "Remediating non-compliant policies",
      "reason": "InProgress",
      "status": "True",
      "type": "Progressing"
    }

  2. RHACM 대시보드 또는 명령줄을 사용하여 자세한 클러스터 정책 규정 준수 상태를 모니터링할 수 있습니다.

    1. oc 를 사용하여 정책 규정 준수를 확인하려면 다음 명령을 실행합니다.

      $ oc get policies -n $CLUSTER

      출력 예

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

    2. RHACM 웹 콘솔에서 정책 상태를 확인하려면 다음 작업을 수행합니다.

      1. Governancepolicies 찾기를 클릭합니다.
      2. 클러스터 정책을 클릭하여 상태를 확인합니다.

모든 클러스터 정책이 준수되면 클러스터의 GitOps ZTP 설치 및 구성이 완료됩니다. ztp-done 레이블이 클러스터에 추가되었습니다.

참조 구성에서 준수되는 최종 정책은 *-du-validator-policy 정책에 정의된 정책입니다. 클러스터 준수 시 이 정책은 모든 클러스터 구성, Operator 설치 및 Operator 구성이 완료되었는지 확인합니다.

18.5.6. 구성 정책 CR 생성 검증

정책 CR(사용자 정의 리소스)은 해당 리소스가 생성된 PolicyGenTemplate 과 동일한 네임스페이스에 생성됩니다. 동일한 문제 해결 흐름은 다음 명령을 사용하여 표시된 것처럼 ztp-common,ztp-group 또는 ztp-site 기반 여부에 관계없이 PolicyGenTemplate 에서 생성된 모든 정책 CR에 적용됩니다.

$ export NS=<namespace>
$ oc get policy -n $NS

정책 래핑된 CR의 예상 세트가 표시되어야 합니다.

정책 동기화에 실패한 경우 다음 문제 해결 단계를 사용하십시오.

프로세스

  1. 정책에 대한 자세한 정보를 표시하려면 다음 명령을 실행합니다.

    $ oc describe -n openshift-gitops application policies
  2. Status: Conditions: 를 확인하여 오류 로그를 표시합니다. 예를 들어 잘못된 sourceFile CryostatfileName: 을 설정하면 다음과 같은 오류가 생성됩니다.

    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:  ComparisonError
  3. 상태 확인: 동기화:. Status: Conditions: 에 로그 오류가 있는 경우 Status: Sync: shows Unknown or Error:

    Status:
      Sync:
        Compared To:
          Destination:
            Namespace:  policies-sub
            Server:     https://kubernetes.default.svc
          Source:
            Path:             policies
            Repo URL:         https://git.com/ran-sites/policies/.git
            Target Revision:  master
        Status:               Error
  4. RHACM(Red Hat Advanced Cluster Management)에서 ManagedCluster 오브젝트에 정책이 적용되는 것을 인식하면 정책 CR 오브젝트가 클러스터 네임스페이스에 적용됩니다. 정책이 클러스터 네임스페이스에 복사되었는지 확인합니다.

    $ oc get policy -n $CLUSTER

    출력 예:

    NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
    ztp-common.common-config-policy              inform               Compliant          13d
    ztp-common.common-subscriptions-policy       inform               Compliant          13d
    ztp-group.group-du-sno-config-policy         inform               Compliant          13d
    Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
    ztp-site.example-sno-config-policy           inform               Compliant          13d

    RHACM은 적용 가능한 모든 정책을 클러스터 네임스페이스에 복사합니다. 복사된 정책 이름의 형식은 < policyGenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName >입니다.

  5. 클러스터 네임스페이스에 복사되지 않은 모든 정책의 배치 규칙을 확인합니다. 해당 정책에 대한 PlacementRulematchSelectorManagedCluster 오브젝트의 라벨과 일치해야 합니다.

    $ oc get placementrule -n $NS
  6. 다음 명령을 사용하여 누락된 정책, 공통, 그룹 또는 사이트에 적절한 PlacementRule 이름을 확인합니다.

    $ oc get placementrule -n $NS <placementRuleName> -o yaml
    • status-decisions에는 클러스터 이름이 포함되어야 합니다.
    • 사양에 있는 matchSelector 의 키-값 쌍은 관리 클러스터의 라벨과 일치해야 합니다.
  7. 다음 명령을 사용하여 ManagedCluster 오브젝트에서 라벨을 확인합니다.

    $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
  8. 다음 명령을 사용하여 호환되는 정책을 확인합니다.

    $ oc get policy -n $CLUSTER

    네임스페이스 ,OperatorGroup서브스크립션 정책이 호환되지만 Operator 구성 정책이 적용되지 않은 경우 Operator가 관리 클러스터에 설치되지 않을 수 있습니다. 이로 인해 CRD가 아직 spoke에 적용되지 않았기 때문에 Operator 구성 정책이 적용되지 않습니다.

18.5.7. 정책 조정 다시 시작

예를 들어 ClusterGroupUpgrade CR(사용자 정의 리소스)이 시간 초과된 경우 예기치 않은 규정 준수 문제가 발생하면 정책 조정을 다시 시작할 수 있습니다.

프로세스

  1. ClusterGroupUpgrade CR은 관리 클러스터가 Ready 가 된 후 토폴로지 Aware Lifecycle Manager를 통해 ztp-install 네임스페이스에 생성됩니다.

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER
  2. 예기치 않은 문제가 있고 정책이 구성된 시간 내에 불만이 발생하지 않는 경우(기본값은 4시간) ClusterGroupUpgrade CR의 상태에 UpgradeTimedOut 이 표시됩니다.

    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
  3. UpgradeTimedOut 상태의 ClusterGroupUpgrade CR은 시간마다 정책 조정을 자동으로 다시 시작합니다. 정책을 변경한 경우 기존 ClusterGroupUpgrade CR을 삭제하여 즉시 재시도를 시작할 수 있습니다. 이렇게 하면 새 ClusterGroupUpgrade CR의 자동 생성이 트리거되고 즉시 정책 조정이 시작됩니다.

    $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

ClusterGroupUpgrade CR이 UpgradeCompleted 상태로 완료되고 관리 클러스터에 ztp-done 레이블이 적용된 경우 PolicyGenTemplate 을 사용하여 추가 구성을 변경할 수 있습니다. 기존 ClusterGroupUpgrade CR을 삭제하면 TALM에서 새 CR이 생성되지 않습니다.

이 시점에서 GitOps ZTP는 클러스터와의 상호 작용을 완료했으며 추가 상호 작용을 업데이트 및 정책 수정을 위해 생성된 새 ClusterGroupUpgrade CR로 처리해야 합니다.

추가 리소스

18.5.8. 정책을 사용하여 적용된 관리 클러스터 CR 변경

정책을 통해 관리 클러스터에 배포된 CR(사용자 정의 리소스)에서 콘텐츠를 제거할 수 있습니다.

기본적으로 Policy GenTemplate CR에서 생성된 모든 Policy CR에는 complianceType 필드가 musthave 로 설정되어 있습니다. 관리 클러스터의 CR에 지정된 콘텐츠가 모두 있으므로 제거된 콘텐츠가 없는 musthave 정책은 계속 호환됩니다. 이 구성을 사용하면 CR에서 콘텐츠를 제거할 때 TALM은 정책에서 콘텐츠를 제거하지만 콘텐츠는 관리 클러스터의 CR에서 제거되지 않습니다.

mustonlyhavecomplianceType 필드를 사용하면 정책에서 클러스터의 CR이 정책에 지정된 내용과 정확히 일치하도록 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • RHACM을 실행하는 허브 클러스터에서 관리 클러스터를 배포했습니다.
  • hub 클러스터에 Topology Aware Lifecycle Manager를 설치했습니다.

프로세스

  1. 영향을 받는 CR에서 더 이상 필요하지 않은 콘텐츠를 제거합니다. 이 예에서는 disableDrain: false 행이 SriovOperatorConfig CR에서 제거되었습니다.

    CR 예

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovOperatorConfig
    metadata:
      name: default
      namespace: openshift-sriov-network-operator
    spec:
      configDaemonNodeSelector:
        "node-role.kubernetes.io/$mcp": ""
      disableDrain: true
      enableInjector: true
      enableOperatorWebhook: true

  2. 영향을 받는 정책의 complianceTypegroup-du-sno-ranGen.yaml 파일에서 mustonlyhave 로 변경합니다.

    YAML의 예

    # ...
    - fileName: SriovOperatorConfig.yaml
      policyName: "config-policy"
      complianceType: mustonlyhave
    # ...

  3. ClusterGroupUpdates CR을 생성하고 CR 변경 사항을 받아야 하는 클러스터를 지정합니다.

    ClusterGroupUpdates CR의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-remove
      namespace: default
    spec:
      managedPolicies:
        - ztp-group.group-du-sno-config-policy
      enable: false
      clusters:
      - spoke1
      - spoke2
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
      batchTimeoutAction:

  4. 다음 명령을 실행하여 ClusterGroupUpgrade CR을 생성합니다.

    $ oc create -f cgu-remove.yaml
  5. 적절한 유지 관리 기간 동안 변경 사항을 적용할 준비가 되면 다음 명령을 실행하여 spec.enable 필드의 값을 true 로 변경합니다.

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \
    --patch '{"spec":{"enable":true}}' --type=merge

검증

  1. 다음 명령을 실행하여 정책의 상태를 확인합니다.

    $ oc get <kind> <changed_cr_name>

    출력 예

    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

    정책의 COMPLIANCE STATECompliant 인 경우 CR이 업데이트되고 원하지 않는 콘텐츠가 제거됨을 의미합니다.

  2. 관리 클러스터에서 다음 명령을 실행하여 정책이 대상 클러스터에서 제거되었는지 확인합니다.

    $ oc get <kind> <changed_cr_name>

    결과가 없는 경우 관리 클러스터에서 CR이 제거됩니다.

18.5.9. GitOps ZTP 설치에 대해 수행됨 표시

GitOps ZTP(ZTP)는 클러스터의 GitOps ZTP 설치 상태를 확인하는 프로세스를 단순화합니다. GitOps ZTP 상태는 클러스터 설치, 클러스터 구성 및 GitOps ZTP의 세 단계로 이동합니다.

클러스터 설치 단계
클러스터 설치 단계는 ManagedCluster CR의 ManagedClusterJoined ManagedCluster Available 조건으로 표시됩니다. ManagedCluster CR에 이러한 조건이 없거나 조건이 False 로 설정되어 있는 경우 클러스터는 여전히 설치 단계에 있습니다. 설치에 대한 자세한 내용은 AgentClusterInstallClusterDeployment CR에서 확인할 수 있습니다. 자세한 내용은 "Troubleshooting GitOps ZTP"를 참조하십시오.
클러스터 구성 단계
클러스터 구성 단계는 클러스터의 ManagedCluster CR을 적용한 ztp 실행 라벨에 의해 표시됩니다.
GitOps ZTP 완료

GitOps ZTP 완료 단계에서 클러스터 설치 및 구성이 완료됩니다. 이는 ztp-running 레이블을 제거하고 ztp-done 레이블을 ManagedCluster CR에 추가하여 표시됩니다. ztp-done 레이블은 구성이 적용되었으며 기준 DU 구성이 클러스터 튜닝을 완료했음을 보여줍니다.

GitOps ZTP done 상태로의 전환은 RHACM(Red Hat Advanced Cluster Management) 검증 검증 정보 정책의 준수 상태에서 조건부입니다. 이 정책은 완료된 설치에 대한 기존 기준을 캡처하고 관리 클러스터의 GitOps ZTP 프로비저닝이 완료된 경우에만 규정 준수 상태로 이동하는지 확인합니다.

검증기 정보 정책은 클러스터 구성이 완전히 적용되고 Operator가 초기화를 완료하도록 합니다. 정책은 다음을 확인합니다.

  • 대상 MachineConfigPool 에는 예상되는 항목이 포함되어 있으며 업데이트가 완료되었습니다. 모든 노드를 사용할 수 있으며 성능이 저하되지 않습니다.
  • SR-IOV Operator는 syncStatus: Succeeded 가 있는 하나 이상의 SriovNetworkNodeState 에 표시된 대로 초기화를 완료했습니다.
  • PTP Operator 데몬 세트가 있습니다.

18.6. ZTP를 사용하여 단일 노드 OpenShift 클러스터 수동 설치

RHACM(Red Hat Advanced Cluster Management) 및 지원 서비스를 사용하여 관리형 단일 노드 OpenShift 클러스터를 배포할 수 있습니다.

참고

여러 개의 관리 클러스터를 생성하는 경우 ZTP를 사용하여 멀리 엣지 사이트 배포에 설명된 site Config 방법을 사용하십시오.

중요

대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대한 권장 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.

18.6.1. 수동으로 GitOps ZTP 설치 및 구성 CR 생성

ztp-site-generate 컨테이너의 생성기 진입점을 사용하여 SiteConfigPolicyGenTemplate CR을 기반으로 클러스터에 대한 사이트 설치 및 구성 CR(사용자 정의 리소스)을 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

프로세스

  1. 다음 명령을 실행하여 출력 폴더를 생성합니다.

    $ mkdir -p ./out
  2. ztp-site-generate 컨테이너 이미지에서 argocd 디렉터리를 내보냅니다.

    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14 extract /home/ztp --tar | tar x -C ./out

    ./out 디렉터리에는 out/argocd/example/ 폴더에 PolicyGenTemplateSiteConfig CR이 있습니다.

    출력 예

    out
     └── argocd
          └── example
               ├── policygentemplates
               │     ├── common-ranGen.yaml
               │     ├── example-sno-site.yaml
               │     ├── group-du-sno-ranGen.yaml
               │     ├── group-du-sno-validator-ranGen.yaml
               │     ├── kustomization.yaml
               │     └── ns.yaml
               └── siteconfig
                      ├── example-sno.yaml
                      ├── KlusterletAddonConfigOverride.yaml
                      └── kustomization.yaml

  3. 사이트 설치 CR의 출력 폴더를 생성합니다.

    $ mkdir -p ./site-install
  4. 설치할 클러스터 유형에 대한 SiteConfig CR 예제를 수정합니다. example-sno.yamlsite-1-sno.yaml 에 복사하고 설치할 사이트 및 베어 메탈 호스트의 세부 정보와 일치하도록 CR을 수정합니다. 예를 들면 다음과 같습니다.

    # example-node1-bmh-secret & assisted-deployment-pull-secret need to be created under same namespace example-sno
    ---
    apiVersion: ran.openshift.io/v1
    kind: 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..."
      clusters:
      - clusterName: "example-sno"
        networkType: "OVNKubernetes"
        # installConfigOverrides is a generic way of passing install-config
        # parameters through the siteConfig.  The 'capabilities' field configures
        # the composable openshift feature.  In this 'capabilities' setting, we
        # remove all but the marketplace component from the optional set of
        # components.
        # Notes:
        # - OperatorLifecycleManager is needed for 4.15 and later
        # - NodeTuning is needed for 4.13 and later, not for 4.12 and earlier
        installConfigOverrides: |
          {
            "capabilities": {
              "baselineCapabilitySet": "None",
              "additionalEnabledCapabilities": [
                "NodeTuning",
                "OperatorLifecycleManager"
              ]
            }
          }
        # It is strongly recommended to include crun manifests as part of the additional install-time manifests for 4.13+.
        # The crun manifests can be obtained from source-crs/optional-extra-manifest/ and added to the git repo ie.sno-extra-manifest.
        # extraManifestPath: sno-extra-manifest
        clusterLabels:
          # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples
          du-profile: "latest"
          # These example cluster labels correspond to the bindingRules in the PolicyGenTemplate examples in ../policygentemplates:
          # ../policygentemplates/common-ranGen.yaml will apply to all clusters with 'common: true'
          common: true
          # ../policygentemplates/group-du-sno-ranGen.yaml will apply to all clusters with 'group-du-sno: ""'
          group-du-sno: ""
          # ../policygentemplates/example-sno-site.yaml will apply to all clusters with 'sites: "example-sno"'
          # Normally this should match or contain the cluster name so it only applies to a single cluster
          sites : "example-sno"
        clusterNetwork:
          - cidr: 1001:1::/48
            hostPrefix: 64
        machineNetwork:
          - cidr: 1111:2222:3333:4444::/64
        serviceNetwork:
          - 1001:2::/112
        additionalNTPSources:
          - 1111:2222:3333:4444::2
        # Initiates the cluster for workload partitioning. Setting specific reserved/isolated CPUSets is done via PolicyTemplate
        # please see Workload Partitioning Feature for a complete guide.
        cpuPartitioningMode: AllNodes
        # Optionally; This can be used to override the KlusterletAddonConfig that is created for this cluster:
        #crTemplates:
        #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml"
        nodes:
          - hostName: "example-node1.example.com"
            role: "master"
            # Optionally; This can be used to configure desired BIOS setting on a host:
            #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:BB:CC:DD:EE:11"
            # Use UEFISecureBoot to enable secure boot
            bootMode: "UEFI"
            rootDeviceHints:
              deviceName: "/dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0"
            # disk partition at `/var/lib/containers` with ignitionConfigOverride. Some values must be updated. See DiskPartitionContainer.md for more details
            ignitionConfigOverride: |
               {
                "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"
                   }
                  ]
                }
               }
            nodeNetwork:
              interfaces:
                - name: eno1
                  macAddress: "AA:BB:CC:DD:EE:11"
              config:
                interfaces:
                  - name: eno1
                    type: ethernet
                    state: up
                    ipv4:
                      enabled: false
                    ipv6:
                      enabled: true
                      address:
                      # For SNO sites with static IP addresses, the node-specific,
                      # API and Ingress IPs should all be the same and configured on
                      # the interface
                      - ip: 1111:2222:3333:4444::aaaa:1
                        prefix-length: 64
                dns-resolver:
                  config:
                    search:
                    - example.com
                    server:
                    - 1111:2222:3333:4444::2
                routes:
                  config:
                  - destination: ::/0
                    next-hop-interface: eno1
                    next-hop-address: 1111:2222:3333:4444::1
                    table-id: 254
    참고

    ztp-site-generate 컨테이너의 out/extra-manifest 디렉터리에서 참조 CR 구성 파일을 추출하면 extraManifests.searchPaths 를 사용하여 해당 파일이 포함된 git 디렉터리의 경로를 포함할 수 있습니다. 그러면 GitOps ZTP 파이프라인에서 클러스터 설치 중에 해당 CR 파일을 적용할 수 있습니다. searchPaths 디렉터리를 구성하면 GitOps ZTP 파이프라인에서 사이트를 설치하는 동안 ztp-site-generate 컨테이너에서 매니페스트를 가져오지 않습니다.

  5. 다음 명령을 실행하여 수정된 SiteConfig CR site-1-sno.yaml 을 처리하여 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.14 generator install site-1-sno.yaml /output

    출력 예

    site-install
    └── site-1-sno
        ├── site-1_agentclusterinstall_example-sno.yaml
        ├── site-1-sno_baremetalhost_example-node1.example.com.yaml
        ├── site-1-sno_clusterdeployment_example-sno.yaml
        ├── site-1-sno_configmap_example-sno.yaml
        ├── site-1-sno_infraenv_example-sno.yaml
        ├── site-1-sno_klusterletaddonconfig_example-sno.yaml
        ├── 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.yaml
        ├── site-1-sno_managedcluster_example-sno.yaml
        ├── site-1-sno_namespace_example-sno.yaml
        └── site-1-sno_nmstateconfig_example-node1.example.com.yaml

  6. 선택 사항: -E 옵션으로 참조 SiteConfig CR을 처리하여 특정 클러스터 유형에 대한 Day 0 MachineConfig 설치 CR만 생성합니다. 예를 들어 다음 명령을 실행합니다.

    1. MachineConfig CR의 출력 폴더를 생성합니다.

      $ mkdir -p ./site-machineconfig
    2. 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.14 generator install -E site-1-sno.yaml /output

      출력 예

      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.yaml

  7. 이전 단계의 PolicyGenTemplate CR 참조를 사용하여 Day 2 구성 CR을 생성하고 내보냅니다. 다음 명령을 실행합니다.

    1. Day 2 CR의 출력 폴더를 생성합니다.

      $ mkdir -p ./ref
    2. 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.14 generator config -N . /output

      이 명령은 단일 노드 OpenShift, 3-노드 클러스터, ./ref 폴더에 표준 클러스터를 위한 예제 그룹 및 사이트별 PolicyGenTemplate CR을 생성합니다.

      출력 예

      ref
       └── customResource
            ├── common
            ├── example-multinode-site
            ├── example-sno
            ├── group-du-3node
            ├── group-du-3node-validator
            │    └── Multiple-validatorCRs
            ├── group-du-sno
            ├── group-du-sno-validator
            ├── group-du-standard
            └── group-du-standard-validator
                 └── Multiple-validatorCRs

  8. 생성된 CR을 클러스터를 설치하는 데 사용하는 CR의 기반으로 사용합니다. "단일 관리 클러스터 설치"에 설명된 대로 hub 클러스터에 설치 CR을 적용합니다. 클러스터 설치가 완료된 후 구성 CR을 클러스터에 적용할 수 있습니다.

검증

  • 노드가 배포된 후 사용자 정의 역할 및 라벨이 적용되는지 확인합니다.

    $ oc describe node example-node.example.com

출력 예

Name:   example-node.example.com
Roles:  control-plane,example-label,master,worker
Labels: beta.kubernetes.io/arch=amd64
        beta.kubernetes.io/os=linux
        custom-label/parameter1=true
        kubernetes.io/arch=amd64
        kubernetes.io/hostname=cnfdf03.telco5gran.eng.rdu2.redhat.com
        kubernetes.io/os=linux
        node-role.kubernetes.io/control-plane=
        node-role.kubernetes.io/example-label= 1
        node-role.kubernetes.io/master=
        node-role.kubernetes.io/worker=
        node.openshift.io/os_id=rhcos

1
사용자 정의 레이블이 노드에 적용됩니다.

18.6.2. 관리형 베어 메탈 호스트 시크릿 생성

관리 베어 메탈 호스트에 필요한 Secret CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. BMC(Baseboard Management Controller)에 액세스하려면 GitOps ZTP(ZTP) 파이프라인의 시크릿과 지원되는 설치 프로그램 서비스에서 레지스트리에서 클러스터 설치 이미지를 가져오는 시크릿이 필요합니다.

참고

보안은 site Config CR에서 이름으로 참조됩니다. 네임스페이스는 site Config 네임스페이스와 일치해야 합니다.

프로세스

  1. OpenShift 및 모든 추가 기능 클러스터 Operator 설치에 필요한 호스트 BMC(Baseboard Management Controller)에 대한 인증 정보와 풀 시크릿을 포함하는 YAML 시크릿 파일을 생성합니다.

    1. 다음 YAML을 example-sno-secret.yaml 파일로 저장합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson
      1
      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.
      2
      암호사용자이름에 대한 base64로 인코딩된 값
      3
      관련 SiteConfig CR에 구성된 네임스페이스와 일치해야 합니다.
      4
      base64로 인코딩된 풀 시크릿
  2. 클러스터를 설치하는 데 사용하는 kustomization.yaml 파일에 example-sno-secret.yaml 에 상대 경로를 추가합니다.

18.6.3. GitOps ZTP를 사용하여 수동 설치를 위한 Discovery ISO 커널 인수 구성

GitOps ZTP(ZTP) 워크플로는 관리형 베어 메탈 호스트에서 OpenShift Container Platform 설치 프로세스의 일부로 Discovery ISO를 사용합니다. InfraEnv 리소스를 편집하여 Discovery ISO에 대한 커널 인수를 지정할 수 있습니다. 이는 특정 환경 요구 사항이 있는 클러스터 설치에 유용합니다. 예를 들어 클러스터의 정적 네트워킹을 용이하게 하거나 설치 중에 루트 파일 시스템을 다운로드하기 전에 DHCP 주소를 수신하도록 Discovery ISO에 rd.net.timeout.carrier 커널 인수를 구성합니다.

참고

OpenShift Container Platform 4.14에서는 커널 인수만 추가할 수 있습니다. 커널 인수를 교체하거나 삭제할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 설치 및 구성 사용자 정의 리소스(CR)를 수동으로 생성했습니다.

프로세스

  1. InfraEnv CR에서 spec.kernelArguments 사양을 편집하여 커널 인수를 구성합니다.
apiVersion: agent-install.openshift.io/v1beta1
kind: InfraEnv
metadata:
  name: <cluster_name>
  namespace: <cluster_name>
spec:
  kernelArguments:
    - operation: append 1
      value: audit=0 2
    - operation: append
      value: trace=1
  clusterRef:
    name: <cluster_name>
    namespace: <cluster_name>
  pullSecretRef:
    name: pull-secret
1
커널 인수를 추가하려면 추가 작업을 지정합니다.
2
구성할 커널 인수를 지정합니다. 이 예제에서는 audit 커널 인수와 trace 커널 인수를 구성합니다.
참고

SiteConfig CR은 InfraEnv 리소스를 day-0 설치 CR의 일부로 생성합니다.

검증

커널 인수가 적용되었는지 확인하려면 검색 이미지에서 OpenShift Container Platform을 설치할 준비가 되었는지 확인한 후 설치 프로세스가 시작되기 전에 대상 호스트에 SSH를 수행할 수 있습니다. 이때 /proc/cmdline 파일에서 Discovery ISO의 커널 인수를 볼 수 있습니다.

  1. 대상 호스트를 사용하여 SSH 세션을 시작합니다.

    $ ssh -i /path/to/privatekey core@<host_name>
  2. 다음 명령을 사용하여 시스템의 커널 인수를 확인합니다.

    $ cat /proc/cmdline

18.6.4. 단일 관리형 클러스터 설치

지원 서비스 및 RHACM(Red Hat Advanced Cluster Management)을 사용하여 단일 관리형 클러스터를 수동으로 배포할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • BMC(Baseboard Management Controller) Secret 및 image pull-secret Secret 사용자 정의 리소스(CR)를 생성했습니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.
  • 대상 베어 메탈 호스트는 관리 클러스터의 네트워킹 및 하드웨어 요구 사항을 충족합니다.

프로세스

  1. 배포할 각 특정 클러스터 버전(예: clusterImageSet-4.14.yaml )에 대한 ClusterImageSet 을 생성합니다. ClusterImageSet 의 형식은 다음과 같습니다.

    apiVersion: hive.openshift.io/v1
    kind: ClusterImageSet
    metadata:
      name: openshift-4.14.0 1
    spec:
       releaseImage: quay.io/openshift-release-dev/ocp-release:4.14.0-x86_64 2
    1
    배포하려는 설명 버전입니다.
    2
    배포할 releaseImage 를 지정하고 운영 체제 이미지 버전을 결정합니다. 검색 ISO는 releaseImage 에서 설정한 이미지 버전 또는 정확한 버전을 사용할 수 없는 경우 최신 버전을 기반으로 합니다.
  2. clusterImageSet CR을 적용합니다.

    $ oc apply -f clusterImageSet-4.14.yaml
  3. cluster-namespace.yaml 파일에 Namespace CR을 생성합니다.

    apiVersion: v1
    kind: Namespace
    metadata:
         name: <cluster_name> 1
         labels:
            name: <cluster_name> 2
    1 2
    프로비저닝할 관리 클러스터의 이름입니다.
  4. 다음 명령을 실행하여 네임스페이스 CR을 적용합니다.

    $ oc apply -f cluster-namespace.yaml
  5. ztp-site-generate 컨테이너에서 추출하고 요구 사항을 충족하도록 사용자 지정된 생성된 day-0 CR을 적용합니다.

    $ oc apply -R ./site-install/site-sno-1

18.6.5. 관리 클러스터 설치 상태 모니터링

클러스터 상태를 확인하여 클러스터 프로비저닝에 성공했는지 확인합니다.

사전 요구 사항

  • 모든 사용자 지정 리소스가 구성 및 프로비저닝되었으며 Agent 사용자 지정 리소스는 관리 클러스터의 허브에 생성됩니다.

프로세스

  1. 관리 클러스터의 상태를 확인합니다.

    $ oc get managedcluster

    true 는 관리 클러스터가 준비되었음을 나타냅니다.

  2. 에이전트 상태를 확인합니다.

    $ oc get agent -n <cluster_name>
  3. describe 명령을 사용하여 에이전트의 상태에 대한 심층적인 설명을 제공합니다. 알 수 있는 상태에는 BackendError,InputError,ValidationsFailing,InstallationFailed, AgentIConnected 가 포함됩니다. 이러한 상태는 AgentAgentClusterInstall 사용자 정의 리소스와 관련이 있습니다.

    $ oc describe agent -n <cluster_name>
  4. 클러스터 프로비저닝 상태를 확인합니다.

    $ oc get agentclusterinstall -n <cluster_name>
  5. describe 명령을 사용하여 클러스터 프로비저닝 상태에 대한 심층적인 설명을 제공합니다.

    $ oc describe agentclusterinstall -n <cluster_name>
  6. 관리 클러스터의 애드온 서비스의 상태를 확인합니다.

    $ oc get managedclusteraddon -n <cluster_name>
  7. 관리 클러스터에 대한 kubeconfig 파일의 인증 정보를 검색합니다.

    $ oc get secret -n <cluster_name> <cluster_name>-admin-kubeconfig -o jsonpath={.data.kubeconfig} | base64 -d > <directory>/<cluster_name>-kubeconfig

18.6.6. 관리 클러스터 문제 해결

관리 클러스터에서 발생할 수 있는 설치 문제를 진단하려면 다음 절차를 사용하십시오.

프로세스

  1. 관리 클러스터의 상태를 확인합니다.

    $ oc get managedcluster

    출력 예

    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED   AVAILABLE   AGE
    SNO-cluster     true                                   True     True      2d19h

    AVAILABLE 열의 상태가 True 이면 관리 클러스터가 허브에 의해 관리되고 있습니다.

    AVAILABLE 열의 상태가 Unknown 인 경우 관리 클러스터는 허브에 의해 관리되지 않습니다. 자세한 정보를 얻으려면 다음 단계를 계속 확인하십시오.

  2. AgentClusterInstall 설치 상태를 확인합니다.

    $ oc get clusterdeployment -n <cluster_name>

    출력 예

    NAME        PLATFORM            REGION   CLUSTERTYPE   INSTALLED    INFRAID    VERSION  POWERSTATE AGE
    Sno0026    agent-baremetal                               false                          Initialized
    2d14h

    INSTALLED 열의 상태가 false 이면 설치에 실패했습니다.

  3. 설치에 실패한 경우 다음 명령을 입력하여 AgentClusterInstall 리소스의 상태를 검토합니다.

    $ oc describe agentclusterinstall -n <cluster_name> <cluster_name>
  4. 오류를 해결하고 클러스터를 재설정합니다.

    1. 클러스터의 관리 클러스터 리소스를 제거합니다.

      $ oc delete managedcluster <cluster_name>
    2. 클러스터의 네임스페이스를 제거합니다.

      $ oc delete namespace <cluster_name>

      이렇게 하면 이 클러스터에 대해 생성된 네임스페이스 범위 사용자 정의 리소스가 모두 삭제됩니다. 계속하기 전에 ManagedCluster CR 삭제가 완료될 때까지 기다려야 합니다.

    3. 관리 클러스터에 대한 사용자 정의 리소스를 다시 생성합니다.

18.6.7. RHACM 생성 클러스터 설치 CR 참조

RHACM(Red Hat Advanced Cluster Management)은 각 사이트에 site Config CR을 사용하여 생성하는 특정 설치 사용자 정의 리소스(CR) 세트가 있는 단일 노드 클러스터, 3-노드 클러스터 및 표준 클러스터에 OpenShift Container Platform 배포를 지원합니다.

참고

관리되는 모든 클러스터에는 자체 네임스페이스가 있으며 ManagedClusterClusterImageSet 을 제외한 모든 설치 CR은 해당 네임스페이스에 있습니다. ManagedClusterClusterImageSet 은 네임스페이스 범위가 아닌 클러스터 범위입니다. 네임스페이스 및 CR 이름은 클러스터 이름과 일치합니다.

다음 표에는 구성된 SiteConfig CR을 사용하여 클러스터를 설치할 때 RHACM 지원 서비스에서 자동으로 적용하는 설치 CR이 나열되어 있습니다.

표 18.10. RHACM에서 생성된 클러스터 설치 CR
CR설명사용법

BareMetalHost

대상 베어 메탈 호스트의 BMC(Baseboard Management Controller)에 대한 연결 정보를 포함합니다.

Redfish 프로토콜을 사용하여 대상 서버에서 검색 이미지를 로드하고 시작할 BMC에 대한 액세스를 제공합니다.

InfraEnv

대상 베어 메탈 호스트에 OpenShift Container Platform을 설치하기 위한 정보가 포함되어 있습니다.

ClusterDeployment 과 함께 사용하여 관리형 클러스터에 대한 검색 ISO를 생성합니다.

AgentClusterInstall

네트워킹 및 컨트롤 플레인 노드 수와 같은 관리형 클러스터 구성의 세부 정보를 지정합니다. 설치가 완료되면 클러스터 kubeconfig 및 인증 정보를 표시합니다.

관리되는 클러스터 구성 정보를 지정하고 클러스터를 설치하는 동안 상태를 제공합니다.

ClusterDeployment

사용할 AgentClusterInstall CR을 참조합니다.

InfraEnv 와 함께 사용하여 관리 클러스터에 대한 검색 ISO를 생성합니다.

NMStateConfig

MAC 주소와 같은 네트워크 구성 정보를 IP 매핑, DNS 서버, 기본 경로 및 기타 네트워크 설정을 제공합니다.

관리 클러스터의 Kube API 서버의 고정 IP 주소를 설정합니다.

agent

대상 베어 메탈 호스트에 대한 하드웨어 정보를 포함합니다.

대상 시스템의 검색 이미지가 부팅될 때 허브에서 자동으로 생성됩니다.

ManagedCluster

허브에서 클러스터를 관리하는 경우 이를 가져오고 알고 있어야 합니다. 이 Kubernetes 오브젝트는 해당 인터페이스를 제공합니다.

허브는 이 리소스를 사용하여 관리 클러스터의 상태를 관리하고 표시합니다.

KlusterletAddonConfig

ManagedCluster 리소스에 배포할 허브에서 제공하는 서비스 목록이 포함되어 있습니다.

ManagedCluster 리소스에 배포할 애드온 서비스를 허브에 지시합니다.

네임스페이스

허브에 존재하는 ManagedCluster 리소스의 논리 공간입니다. 사이트당 고유합니다.

ManagedCluster 에 리소스를 전파합니다.

Secret

BMC SecretImage Pull Secret 이라는 두 개의 CR이 생성됩니다.

  • BMC Secret 은 사용자 이름과 암호를 사용하여 대상 베어 메탈 호스트에 인증합니다.
  • 이미지 가져오기 시크릿에 는 대상 베어 메탈 호스트에 설치된 OpenShift Container Platform 이미지에 대한 인증 정보가 포함되어 있습니다.

ClusterImageSet

리포지토리 및 이미지 이름과 같은 OpenShift Container Platform 이미지 정보가 포함되어 있습니다.

OpenShift Container Platform 이미지를 제공하기 위해 리소스에 전달됩니다.

18.7. vDU 애플리케이션 워크로드에 권장되는 단일 노드 OpenShift 클러스터 구성

다음 참조 정보를 사용하여 클러스터에 가상 분산 단위(vDU) 애플리케이션을 배포하는 데 필요한 단일 노드 OpenShift 구성을 파악합니다. 구성에는 고성능 워크로드를 위한 클러스터 최적화, 워크로드 파티셔닝 활성화, 설치 후 필요한 재부팅 횟수 최소화가 포함됩니다.

추가 리소스

18.7.1. OpenShift Container Platform에서 짧은 대기 시간 애플리케이션 실행

OpenShift Container Platform을 사용하면 여러 기술 및 특수 하드웨어 장치를 사용하여 COTS(Commer off-the-shelf) 하드웨어에서 실행되는 애플리케이션에 대해 대기 시간이 짧은 처리를 수행할 수 있습니다.

RHCOS의 실시간 커널
높은 수준의 프로세스 결정으로 워크로드가 처리되도록 합니다.
CPU 격리
CPU 스케줄링 지연을 방지하고 CPU 용량을 일관되게 사용할 수 있도록 합니다.
NUMA 인식 토폴로지 관리
메모리 및 대규모 페이지를 CPU 및 PCI 장치와 조정하여 보장된 컨테이너 메모리 및 대규모 페이지를 NUMA(Non-Uniform Memory Access) 노드에 고정합니다. 모든 QoS(Quality of Service) 클래스에 대한 Pod 리소스는 동일한 NUMA 노드에 남아 있습니다. 이렇게 하면 대기 시간이 줄어들고 노드의 성능이 향상됩니다.
대규모 페이지 메모리 관리
대규모 페이지 크기를 사용하면 페이지 테이블에 액세스하는 데 필요한 시스템 리소스의 양을 줄임으로써 시스템 성능이 향상됩니다.
PTP를 사용한 정확한 타이밍 동기화
네트워크의 노드 간 동기화를 통해 마이크로초 이하의 정확도를 사용할 수 있습니다.

18.7.2. vDU 애플리케이션 워크로드에 대한 권장 클러스터 호스트 요구 사항

vDU 애플리케이션 워크로드를 실행하려면 OpenShift Container Platform 서비스 및 프로덕션 워크로드를 실행하기에 충분한 리소스가 있는 베어 메탈 호스트가 필요합니다.

표 18.11. 최소 리소스 요구사항
프로필vCPU메모리스토리지

최소

4에서 8 vCPU

32GB RAM

120GB

참고

하나의 vCPU는 하나의 물리적 코어와 동일합니다. 그러나 동시 멀티스레딩(SMT) 또는 Hyper-Threading을 활성화하면 다음 공식을 사용하여 하나의 물리적 코어를 나타내는 vCPU 수를 계산합니다.

  • (threads per core × cores) × sockets = vCPUs
중요

가상 미디어를 사용하여 부팅할 때 서버에 BMC(Baseboard Management Controller)가 있어야 합니다.

18.7.3. 짧은 대기 시간과 고성능을 위해 호스트 펌웨어 구성

호스트를 프로비저닝하기 전에 베어 메탈 호스트에 펌웨어를 구성해야 합니다. 펌웨어 구성은 특정 하드웨어 및 설치의 특정 요구 사항에 따라 다릅니다.

프로세스

  1. UEFI/BIOS 부팅 모드를 UEFI 로 설정합니다.
  2. 호스트 부팅 순서에서 먼저 하드 드라이브를 설정합니다.
  3. 하드웨어에 대한 특정 펌웨어 구성을 적용합니다. 다음 표에서는 Intel FlexRAN 4G 및 5G 베이스band CryostatY 참조 설계를 기반으로 하는 Intel Xeon Skylake 또는 Intel Cascade Lake 서버의 대표적인 펌웨어 구성에 대해 설명합니다.

    중요

    정확한 펌웨어 구성은 특정 하드웨어 및 네트워크 요구 사항에 따라 다릅니다. 다음 샘플 구성은 예시적인 목적으로만 사용됩니다.

    표 18.12. Intel Xeon Skylake 또는 Cascade Lake 서버의 펌웨어 구성 샘플
    펌웨어 설정설정

    CPU 전원 및 성능 정책

    성능

    코어 빈도 확장 해제

    비활성화됨

    성능 P-limit

    비활성화됨

    향상된 Intel SpeedStep ® Tech

    enabled

    Intel Configurable TDP

    enabled

    구성 가능한 TDP 수준

    수준 2

    Intel® Cryostat Boost Technology

    enabled

    에너지 효율성:

    비활성화됨

    하드웨어 P-States

    비활성화됨

    패키지 C-State

    C0/C1 상태

    C1E

    비활성화됨

    프로세서 C6

    비활성화됨

참고

호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.

18.7.4. 관리되는 클러스터 네트워크에 대한 연결 사전 요구 사항

GitOps ZTP(ZTP) 파이프라인을 사용하여 관리 클러스터를 설치하고 프로비저닝하려면 관리 클러스터 호스트가 다음 네트워킹 사전 요구 사항을 충족해야 합니다.

  • hub 클러스터의 GitOps ZTP 컨테이너와 대상 베어 메탈 호스트의 BMC(Baseboard Management Controller) 간에 양방향 연결이 있어야 합니다.
  • 관리 클러스터는 허브 호스트 이름 및 *.apps 호스트 이름의 API 호스트 이름을 확인하고 연결할 수 있어야 합니다. 다음은 hub 및 *.apps 호스트 이름의 API 호스트 이름의 예입니다.

    • api.hub-cluster.internal.domain.com
    • console-openshift-console.apps.hub-cluster.internal.domain.com
  • 허브 클러스터는 관리형 클러스터의 API 및 *.apps 호스트 이름을 확인하고 연결할 수 있어야 합니다. 다음은 관리 클러스터의 API 호스트 이름과 *.apps 호스트 이름의 예입니다.

    • api.sno-managed-cluster-1.internal.domain.com
    • console-openshift-console.apps.sno-managed-cluster-1.internal.domain.com

18.7.5. GitOps ZTP를 사용하여 단일 노드 OpenShift에서 워크로드 파티셔닝

워크로드 파티셔닝은 예약된 수의 호스트 CPU에서 실행되도록 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 구성합니다.

GitOps ZTP(ZTP)를 사용하여 워크로드 파티셔닝을 구성하려면 클러스터를 설치하는 데 사용하는 SiteConfig CR(사용자 정의 리소스)에서 cpu CryostatingMode 필드를 구성하고 호스트에 분리예약된 CPU를 구성하는 PerformanceProfile CR을 적용합니다.

SiteConfig CR을 구성하면 클러스터 설치 시 워크로드 파티셔닝을 활성화하고 PerformanceProfile CR을 적용하면 예약 및 분리된 세트에 대한 CPU의 특정 할당이 구성됩니다. 이 두 단계는 클러스터 프로비저닝 중에 서로 다른 지점에서 수행됩니다.

참고

SiteConfig CR에서 cpu CryostatingMode 필드를 사용하여 워크로드 파티셔닝을 구성하는 것은 OpenShift Container Platform 4.13의 기술 프리뷰 기능입니다.

또는 SiteConfig 사용자 정의 리소스(CR)의 cpuset 필드와 PolicyGenTemplate CR 그룹의 reserved 필드를 사용하여 클러스터 관리 CPU 리소스를 지정할 수 있습니다. GitOps ZTP 파이프라인은 이러한 값을 사용하여 워크로드 파티셔닝 MachineConfig CR(cpuset) 및 단일 노드 OpenShift 클러스터를 구성하는 PerformanceProfile CR(reserved)의 필수 필드를 채웁니다. 이 방법은 OpenShift Container Platform 4.14의 일반 가용성 기능입니다.

워크로드 파티셔닝 구성은 OpenShift Container Platform 인프라 Pod를 예약된 CPU 세트에 고정합니다. systemd, CRI-O 및 kubelet과 같은 플랫폼 서비스는 예약된 CPU 세트에서 실행됩니다. 격리된 CPU 세트는 컨테이너 워크로드에 독점적으로 할당됩니다. CPU를 격리하면 동일한 노드에서 실행되는 다른 애플리케이션의 경합 없이 워크로드가 지정된 CPU에 대한 액세스를 보장할 수 있습니다. 분리되지 않은 모든 CPU를 예약해야 합니다.

중요

예약분리된 CPU 세트가 서로 겹치지 않도록 합니다.

추가 리소스

18.7.6. 권장되는 클러스터 설치 매니페스트

ZTP 파이프라인은 클러스터 설치 중에 다음 사용자 정의 리소스(CR)를 적용합니다. 이러한 구성 CR을 사용하면 클러스터가 vDU 애플리케이션을 실행하는 데 필요한 기능 및 성능 요구 사항을 충족할 수 있습니다.

참고

클러스터 배포에 GitOps ZTP 플러그인 및 SiteConfig CR을 사용하는 경우 다음 MachineConfig CR이 기본적으로 포함됩니다.

SiteConfig 추가Manifests 필터를 사용하여 기본적으로 포함된 CR을 변경합니다. 자세한 내용은 SiteConfig CR을 사용한 고급 관리 클러스터 구성 을 참조하십시오.

18.7.6.1. 워크로드 파티셔닝

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 워크로드 파티셔닝이 필요합니다. 이렇게 하면 플랫폼 서비스를 실행할 수 있는 코어가 제한되고 애플리케이션 페이로드의 CPU 코어를 최대화할 수 있습니다.

참고

워크로드 파티셔닝은 클러스터 설치 중에만 활성화할 수 있습니다. 워크로드 파티션 설치 후 비활성화할 수 없습니다. 그러나 PerformanceProfile CR을 통해 분리된 세트 및 예약된 세트에 할당된 CPU 세트를 변경할 수 있습니다. CPU 설정을 변경하면 노드가 재부팅됩니다.

OpenShift Container Platform 4.12에서 4.13 이상으로 업그레이드

워크로드 파티셔닝을 활성화하기 위해 cpu CryostatingMode 를 사용하여 전환할 때 클러스터를 프로비저닝하는 데 사용하는 /extra-manifest 폴더에서 워크로드 파티션 MachineConfig CR을 제거합니다.

워크로드 파티셔닝에 권장되는 site Config CR 구성

apiVersion: ran.openshift.io/v1
kind: SiteConfig
metadata:
  name: "<site_name>"
  namespace: "<site_name>"
spec:
  baseDomain: "example.com"
  cpuPartitioningMode: AllNodes 1

1
cpu CryostatingMode 필드를 AllNodes 로 설정하여 클러스터의 모든 노드에 대한 워크로드 파티셔닝을 구성합니다.

검증

애플리케이션 및 클러스터 시스템 CPU 고정이 올바른지 확인합니다. 다음 명령을 실행합니다.

  1. 관리 클러스터에 대한 원격 쉘 프롬프트를 엽니다.

    $ oc debug node/example-sno-1
  2. OpenShift 인프라 애플리케이션 CPU 고정이 올바른지 확인합니다.

    sh-4.4# pgrep ovn | while read i; do taskset -cp $i; done

    출력 예

    pid 8481's current affinity list: 0-1,52-53
    pid 8726's current affinity list: 0-1,52-53
    pid 9088's current affinity list: 0-1,52-53
    pid 9945's current affinity list: 0-1,52-53
    pid 10387's current affinity list: 0-1,52-53
    pid 12123's current affinity list: 0-1,52-53
    pid 13313's current affinity list: 0-1,52-53

  3. 시스템 애플리케이션 CPU 고정이 올바른지 확인합니다.

    sh-4.4# pgrep systemd | while read i; do taskset -cp $i; done

    출력 예

    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

18.7.6.2. 플랫폼 관리 공간 감소

플랫폼의 전체 관리 공간을 줄이기 위해 MachineConfig CR(사용자 정의 리소스)을 호스트 운영 체제와 별도로 새 네임스페이스에 모든 Kubernetes별 마운트 지점을 배치해야 합니다. 다음 base64로 인코딩된 예제 MachineConfig CR은 이 구성을 보여줍니다.

권장 컨테이너 마운트 네임스페이스 구성 (01-container-mount-ns-and-kubelet-conf-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: container-mount-namespace-and-kubelet-conf-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKCmRlYnVnKCkgewogIGVjaG8gJEAgPiYyCn0KCnVzYWdlKCkgewogIGVjaG8gVXNhZ2U6ICQoYmFzZW5hbWUgJDApIFVOSVQgW2VudmZpbGUgW3Zhcm5hbWVdXQogIGVjaG8KICBlY2hvIEV4dHJhY3QgdGhlIGNvbnRlbnRzIG9mIHRoZSBmaXJzdCBFeGVjU3RhcnQgc3RhbnphIGZyb20gdGhlIGdpdmVuIHN5c3RlbWQgdW5pdCBhbmQgcmV0dXJuIGl0IHRvIHN0ZG91dAogIGVjaG8KICBlY2hvICJJZiAnZW52ZmlsZScgaXMgcHJvdmlkZWQsIHB1dCBpdCBpbiB0aGVyZSBpbnN0ZWFkLCBhcyBhbiBlbnZpcm9ubWVudCB2YXJpYWJsZSBuYW1lZCAndmFybmFtZSciCiAgZWNobyAiRGVmYXVsdCAndmFybmFtZScgaXMgRVhFQ1NUQVJUIGlmIG5vdCBzcGVjaWZpZWQiCiAgZXhpdCAxCn0KClVOSVQ9JDEKRU5WRklMRT0kMgpWQVJOQU1FPSQzCmlmIFtbIC16ICRVTklUIHx8ICRVTklUID09ICItLWhlbHAiIHx8ICRVTklUID09ICItaCIgXV07IHRoZW4KICB1c2FnZQpmaQpkZWJ1ZyAiRXh0cmFjdGluZyBFeGVjU3RhcnQgZnJvbSAkVU5JVCIKRklMRT0kKHN5c3RlbWN0bCBjYXQgJFVOSVQgfCBoZWFkIC1uIDEpCkZJTEU9JHtGSUxFI1wjIH0KaWYgW1sgISAtZiAkRklMRSBdXTsgdGhlbgogIGRlYnVnICJGYWlsZWQgdG8gZmluZCByb290IGZpbGUgZm9yIHVuaXQgJFVOSVQgKCRGSUxFKSIKICBleGl0CmZpCmRlYnVnICJTZXJ2aWNlIGRlZmluaXRpb24gaXMgaW4gJEZJTEUiCkVYRUNTVEFSVD0kKHNlZCAtbiAtZSAnL15FeGVjU3RhcnQ9LipcXCQvLC9bXlxcXSQvIHsgcy9eRXhlY1N0YXJ0PS8vOyBwIH0nIC1lICcvXkV4ZWNTdGFydD0uKlteXFxdJC8geyBzL15FeGVjU3RhcnQ9Ly87IHAgfScgJEZJTEUpCgppZiBbWyAkRU5WRklMRSBdXTsgdGhlbgogIFZBUk5BTUU9JHtWQVJOQU1FOi1FWEVDU1RBUlR9CiAgZWNobyAiJHtWQVJOQU1FfT0ke0VYRUNTVEFSVH0iID4gJEVOVkZJTEUKZWxzZQogIGVjaG8gJEVYRUNTVEFSVApmaQo=
          mode: 493
          path: /usr/local/bin/extractExecStart
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKbnNlbnRlciAtLW1vdW50PS9ydW4vY29udGFpbmVyLW1vdW50LW5hbWVzcGFjZS9tbnQgIiRAIgo=
          mode: 493
          path: /usr/local/bin/nsenterCmns
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Manages a mount namespace that both kubelet and crio can use to share their container-specific mounts

            [Service]
            Type=oneshot
            RemainAfterExit=yes
            RuntimeDirectory=container-mount-namespace
            Environment=RUNTIME_DIRECTORY=%t/container-mount-namespace
            Environment=BIND_POINT=%t/container-mount-namespace/mnt
            ExecStartPre=bash -c "findmnt ${RUNTIME_DIRECTORY} || mount --make-unbindable --bind ${RUNTIME_DIRECTORY} ${RUNTIME_DIRECTORY}"
            ExecStartPre=touch ${BIND_POINT}
            ExecStart=unshare --mount=${BIND_POINT} --propagation slave mount --make-rshared /
            ExecStop=umount -R ${RUNTIME_DIRECTORY}
          name: container-mount-namespace.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART}"
              name: 90-container-mount-namespace.conf
          name: crio.service
        - dropins:
            - contents: |
                [Unit]
                Wants=container-mount-namespace.service
                After=container-mount-namespace.service

                [Service]
                ExecStartPre=/usr/local/bin/extractExecStart %n /%t/%N-execstart.env ORIG_EXECSTART
                EnvironmentFile=-/%t/%N-execstart.env
                ExecStart=
                ExecStart=bash -c "nsenter --mount=%t/container-mount-namespace/mnt \
                    ${ORIG_EXECSTART} --housekeeping-interval=30s"
              name: 90-container-mount-namespace.conf
            - contents: |
                [Service]
                Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"
                Environment="OPENSHIFT_EVICTION_MONITORING_PERIOD_DURATION=30s"
              name: 30-kubelet-interval-tuning.conf
          name: kubelet.service

18.7.6.3. SCTP

SCTP(스트림 제어 전송 프로토콜)는 RAN 애플리케이션에서 사용되는 주요 프로토콜입니다. 이 MachineConfig 오브젝트는 노드에 SCTP 커널 모듈을 추가하여 이 프로토콜을 활성화합니다.

권장 컨트롤 플레인 노드 SCTP 구성 (03-sctp-machine-config-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: load-sctp-module-master
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

권장 작업자 노드 SCTP 구성 (03-sctp-machine-config-worker.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: load-sctp-module-worker
spec:
  config:
    ignition:
      version: 2.2.0
    storage:
      files:
        - contents:
            source: data:,
            verification: {}
          filesystem: root
          mode: 420
          path: /etc/modprobe.d/sctp-blacklist.conf
        - contents:
            source: data:text/plain;charset=utf-8,sctp
          filesystem: root
          mode: 420
          path: /etc/modules-load.d/sctp-load.conf

18.7.6.4. rcu_normal 설정

다음 MachineConfig CR은 시스템 시작이 완료된 후 rcu_normal 를 1로 설정하도록 구성합니다. 이로 인해 vDU 애플리케이션의 커널 대기 시간이 향상됩니다.

노드가 시작된 후 rcu_expedited 를 비활성화하는 권장 설정 (08-set-rcu-normal-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 08-set-rcu-normal-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvYmluL2Jhc2gKIwojIERpc2FibGUgcmN1X2V4cGVkaXRlZCBhZnRlciBub2RlIGhhcyBmaW5pc2hlZCBib290aW5nCiMKIyBUaGUgZGVmYXVsdHMgYmVsb3cgY2FuIGJlIG92ZXJyaWRkZW4gdmlhIGVudmlyb25tZW50IHZhcmlhYmxlcwojCgojIERlZmF1bHQgd2FpdCB0aW1lIGlzIDYwMHMgPSAxMG06Ck1BWElNVU1fV0FJVF9USU1FPSR7TUFYSU1VTV9XQUlUX1RJTUU6LTYwMH0KCiMgRGVmYXVsdCBzdGVhZHktc3RhdGUgdGhyZXNob2xkID0gMiUKIyBBbGxvd2VkIHZhbHVlczoKIyAgNCAgLSBhYnNvbHV0ZSBwb2QgY291bnQgKCsvLSkKIyAgNCUgLSBwZXJjZW50IGNoYW5nZSAoKy8tKQojICAtMSAtIGRpc2FibGUgdGhlIHN0ZWFkeS1zdGF0ZSBjaGVjawpTVEVBRFlfU1RBVEVfVEhSRVNIT0xEPSR7U1RFQURZX1NUQVRFX1RIUkVTSE9MRDotMiV9CgojIERlZmF1bHQgc3RlYWR5LXN0YXRlIHdpbmRvdyA9IDYwcwojIElmIHRoZSBydW5uaW5nIHBvZCBjb3VudCBzdGF5cyB3aXRoaW4gdGhlIGdpdmVuIHRocmVzaG9sZCBmb3IgdGhpcyB0aW1lCiMgcGVyaW9kLCByZXR1cm4gQ1BVIHV0aWxpemF0aW9uIHRvIG5vcm1hbCBiZWZvcmUgdGhlIG1heGltdW0gd2FpdCB0aW1lIGhhcwojIGV4cGlyZXMKU1RFQURZX1NUQVRFX1dJTkRPVz0ke1NURUFEWV9TVEFURV9XSU5ET1c6LTYwfQoKIyBEZWZhdWx0IHN0ZWFkeS1zdGF0ZSBhbGxvd3MgYW55IHBvZCBjb3VudCB0byBiZSAic3RlYWR5IHN0YXRlIgojIEluY3JlYXNpbmcgdGhpcyB3aWxsIHNraXAgYW55IHN0ZWFkeS1zdGF0ZSBjaGVja3MgdW50aWwgdGhlIGNvdW50IHJpc2VzIGFib3ZlCiMgdGhpcyBudW1iZXIgdG8gYXZvaWQgZmFsc2UgcG9zaXRpdmVzIGlmIHRoZXJlIGFyZSBzb21lIHBlcmlvZHMgd2hlcmUgdGhlCiMgY291bnQgZG9lc24ndCBpbmNyZWFzZSBidXQgd2Uga25vdyB3ZSBjYW4ndCBiZSBhdCBzdGVhZHktc3RhdGUgeWV0LgpTVEVBRFlfU1RBVEVfTUlOSU1VTT0ke1NURUFEWV9TVEFURV9NSU5JTVVNOi0wfQoKIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwoKd2l0aGluKCkgewogIGxvY2FsIGxhc3Q9JDEgY3VycmVudD0kMiB0aHJlc2hvbGQ9JDMKICBsb2NhbCBkZWx0YT0wIHBjaGFuZ2UKICBkZWx0YT0kKCggY3VycmVudCAtIGxhc3QgKSkKICBpZiBbWyAkY3VycmVudCAtZXEgJGxhc3QgXV07IHRoZW4KICAgIHBjaGFuZ2U9MAogIGVsaWYgW1sgJGxhc3QgLWVxIDAgXV07IHRoZW4KICAgIHBjaGFuZ2U9MTAwMDAwMAogIGVsc2UKICAgIHBjaGFuZ2U9JCgoICggIiRkZWx0YSIgKiAxMDApIC8gbGFzdCApKQogIGZpCiAgZWNobyAtbiAibGFzdDokbGFzdCBjdXJyZW50OiRjdXJyZW50IGRlbHRhOiRkZWx0YSBwY2hhbmdlOiR7cGNoYW5nZX0lOiAiCiAgbG9jYWwgYWJzb2x1dGUgbGltaXQKICBjYXNlICR0aHJlc2hvbGQgaW4KICAgIColKQogICAgICBhYnNvbHV0ZT0ke3BjaGFuZ2UjIy19ICMgYWJzb2x1dGUgdmFsdWUKICAgICAgbGltaXQ9JHt0aHJlc2hvbGQlJSV9CiAgICAgIDs7CiAgICAqKQogICAgICBhYnNvbHV0ZT0ke2RlbHRhIyMtfSAjIGFic29sdXRlIHZhbHVlCiAgICAgIGxpbWl0PSR0aHJlc2hvbGQKICAgICAgOzsKICBlc2FjCiAgaWYgW1sgJGFic29sdXRlIC1sZSAkbGltaXQgXV07IHRoZW4KICAgIGVjaG8gIndpdGhpbiAoKy8tKSR0aHJlc2hvbGQiCiAgICByZXR1cm4gMAogIGVsc2UKICAgIGVjaG8gIm91dHNpZGUgKCsvLSkkdGhyZXNob2xkIgogICAgcmV0dXJuIDEKICBmaQp9CgpzdGVhZHlzdGF0ZSgpIHsKICBsb2NhbCBsYXN0PSQxIGN1cnJlbnQ9JDIKICBpZiBbWyAkbGFzdCAtbHQgJFNURUFEWV9TVEFURV9NSU5JTVVNIF1dOyB0aGVuCiAgICBlY2hvICJsYXN0OiRsYXN0IGN1cnJlbnQ6JGN1cnJlbnQgV2FpdGluZyB0byByZWFjaCAkU1RFQURZX1NUQVRFX01JTklNVU0gYmVmb3JlIGNoZWNraW5nIGZvciBzdGVhZHktc3RhdGUiCiAgICByZXR1cm4gMQogIGZpCiAgd2l0aGluICIkbGFzdCIgIiRjdXJyZW50IiAiJFNURUFEWV9TVEFURV9USFJFU0hPTEQiCn0KCndhaXRGb3JSZWFkeSgpIHsKICBsb2dnZXIgIlJlY292ZXJ5OiBXYWl0aW5nICR7TUFYSU1VTV9XQUlUX1RJTUV9cyBmb3IgdGhlIGluaXRpYWxpemF0aW9uIHRvIGNvbXBsZXRlIgogIGxvY2FsIHQ9MCBzPTEwCiAgbG9jYWwgbGFzdENjb3VudD0wIGNjb3VudD0wIHN0ZWFkeVN0YXRlVGltZT0wCiAgd2hpbGUgW1sgJHQgLWx0ICRNQVhJTVVNX1dBSVRfVElNRSBdXTsgZG8KICAgIHNsZWVwICRzCiAgICAoKHQgKz0gcykpCiAgICAjIERldGVjdCBzdGVhZHktc3RhdGUgcG9kIGNvdW50CiAgICBjY291bnQ9JChjcmljdGwgcHMgMj4vZGV2L251bGwgfCB3YyAtbCkKICAgIGlmIFtbICRjY291bnQgLWd0IDAgXV0gJiYgc3RlYWR5c3RhdGUgIiRsYXN0Q2NvdW50IiAiJGNjb3VudCI7IHRoZW4KICAgICAgKChzdGVhZHlTdGF0ZVRpbWUgKz0gcykpCiAgICAgIGVjaG8gIlN0ZWFkeS1zdGF0ZSBmb3IgJHtzdGVhZHlTdGF0ZVRpbWV9cy8ke1NURUFEWV9TVEFURV9XSU5ET1d9cyIKICAgICAgaWYgW1sgJHN0ZWFkeVN0YXRlVGltZSAtZ2UgJFNURUFEWV9TVEFURV9XSU5ET1cgXV07IHRoZW4KICAgICAgICBsb2dnZXIgIlJlY292ZXJ5OiBTdGVhZHktc3RhdGUgKCsvLSAkU1RFQURZX1NUQVRFX1RIUkVTSE9MRCkgZm9yICR7U1RFQURZX1NUQVRFX1dJTkRPV31zOiBEb25lIgogICAgICAgIHJldHVybiAwCiAgICAgIGZpCiAgICBlbHNlCiAgICAgIGlmIFtbICRzdGVhZHlTdGF0ZVRpbWUgLWd0IDAgXV07IHRoZW4KICAgICAgICBlY2hvICJSZXNldHRpbmcgc3RlYWR5LXN0YXRlIHRpbWVyIgogICAgICAgIHN0ZWFkeVN0YXRlVGltZT0wCiAgICAgIGZpCiAgICBmaQogICAgbGFzdENjb3VudD0kY2NvdW50CiAgZG9uZQogIGxvZ2dlciAiUmVjb3Zlcnk6IFJlY292ZXJ5IENvbXBsZXRlIFRpbWVvdXQiCn0KCnNldFJjdU5vcm1hbCgpIHsKICBlY2hvICJTZXR0aW5nIHJjdV9ub3JtYWwgdG8gMSIKICBlY2hvIDEgPiAvc3lzL2tlcm5lbC9yY3Vfbm9ybWFsCn0KCm1haW4oKSB7CiAgd2FpdEZvclJlYWR5CiAgZWNobyAiV2FpdGluZyBmb3Igc3RlYWR5IHN0YXRlIHRvb2s6ICQoYXdrICd7cHJpbnQgaW50KCQxLzM2MDApImgiLCBpbnQoKCQxJTM2MDApLzYwKSJtIiwgaW50KCQxJTYwKSJzIn0nIC9wcm9jL3VwdGltZSkiCiAgc2V0UmN1Tm9ybWFsCn0KCmlmIFtbICIke0JBU0hfU09VUkNFWzBdfSIgPSAiJHswfSIgXV07IHRoZW4KICBtYWluICIke0B9IgogIGV4aXQgJD8KZmkK
          mode: 493
          path: /usr/local/bin/set-rcu-normal.sh
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Disable rcu_expedited after node has finished booting by setting rcu_normal to 1

            [Service]
            Type=simple
            ExecStart=/usr/local/bin/set-rcu-normal.sh

            # Maximum wait time is 600s = 10m:
            Environment=MAXIMUM_WAIT_TIME=600

            # Steady-state threshold = 2%
            # Allowed values:
            #  4  - absolute pod count (+/-)
            #  4% - percent change (+/-)
            #  -1 - disable the steady-state check
            # Note: '%' must be escaped as '%%' in systemd unit files
            Environment=STEADY_STATE_THRESHOLD=2%%

            # Steady-state window = 120s
            # If the running pod count stays within the given threshold for this time
            # period, return CPU utilization to normal before the maximum wait time has
            # expires
            Environment=STEADY_STATE_WINDOW=120

            # Steady-state minimum = 40
            # Increasing this will skip any steady-state checks until the count rises above
            # this number to avoid false positives if there are some periods where the
            # count doesn't increase but we know we can't be at steady-state yet.
            Environment=STEADY_STATE_MINIMUM=40

            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: set-rcu-normal.service

18.7.6.5. kdump를 사용한 자동 커널 크래시 덤프

kdump 는 커널이 충돌할 때 커널 크래시 덤프를 생성하는 Linux 커널 기능입니다. kdump 는 다음 MachineConfig CR을 사용하여 활성화됩니다.

컨트롤 플레인 kdump 로그에서 원래 드라이버를 제거하려면 MachineConfig CR을 권장함 (05-kdump-config-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 05-kdump-config-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump-remove-ice-module.service
          contents: |
            [Unit]
            Description=Remove ice module when doing kdump
            Before=kdump.service
            [Service]
            Type=oneshot
            RemainAfterExit=true
            ExecStart=/usr/local/bin/kdump-remove-ice-module.sh
            [Install]
            WantedBy=multi-user.target
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvdXNyL2Jpbi9lbnYgYmFzaAoKIyBUaGlzIHNjcmlwdCByZW1vdmVzIHRoZSBpY2UgbW9kdWxlIGZyb20ga2R1bXAgdG8gcHJldmVudCBrZHVtcCBmYWlsdXJlcyBvbiBjZXJ0YWluIHNlcnZlcnMuCiMgVGhpcyBpcyBhIHRlbXBvcmFyeSB3b3JrYXJvdW5kIGZvciBSSEVMUExBTi0xMzgyMzYgYW5kIGNhbiBiZSByZW1vdmVkIHdoZW4gdGhhdCBpc3N1ZSBpcwojIGZpeGVkLgoKc2V0IC14CgpTRUQ9Ii91c3IvYmluL3NlZCIKR1JFUD0iL3Vzci9iaW4vZ3JlcCIKCiMgb3ZlcnJpZGUgZm9yIHRlc3RpbmcgcHVycG9zZXMKS0RVTVBfQ09ORj0iJHsxOi0vZXRjL3N5c2NvbmZpZy9rZHVtcH0iClJFTU9WRV9JQ0VfU1RSPSJtb2R1bGVfYmxhY2tsaXN0PWljZSIKCiMgZXhpdCBpZiBmaWxlIGRvZXNuJ3QgZXhpc3QKWyAhIC1mICR7S0RVTVBfQ09ORn0gXSAmJiBleGl0IDAKCiMgZXhpdCBpZiBmaWxlIGFscmVhZHkgdXBkYXRlZAoke0dSRVB9IC1GcSAke1JFTU9WRV9JQ0VfU1RSfSAke0tEVU1QX0NPTkZ9ICYmIGV4aXQgMAoKIyBUYXJnZXQgbGluZSBsb29rcyBzb21ldGhpbmcgbGlrZSB0aGlzOgojIEtEVU1QX0NPTU1BTkRMSU5FX0FQUEVORD0iaXJxcG9sbCBucl9jcHVzPTEgLi4uIGhlc3RfZGlzYWJsZSIKIyBVc2Ugc2VkIHRvIG1hdGNoIGV2ZXJ5dGhpbmcgYmV0d2VlbiB0aGUgcXVvdGVzIGFuZCBhcHBlbmQgdGhlIFJFTU9WRV9JQ0VfU1RSIHRvIGl0CiR7U0VEfSAtaSAncy9eS0RVTVBfQ09NTUFORExJTkVfQVBQRU5EPSJbXiJdKi8mICcke1JFTU9WRV9JQ0VfU1RSfScvJyAke0tEVU1QX0NPTkZ9IHx8IGV4aXQgMAo=
          mode: 448
          path: /usr/local/bin/kdump-remove-ice-module.sh

권장 컨트롤 플레인 노드 kdump 구성 (06-kdump-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 06-kdump-enable-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump.service
  kernelArguments:
    - crashkernel=512M

작업자 노드 kdump 로그에서 원래 드라이버를 제거하려면 MachineConfig CR을 권장함 (05-kdump-config-worker.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 05-kdump-config-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump-remove-ice-module.service
          contents: |
            [Unit]
            Description=Remove ice module when doing kdump
            Before=kdump.service
            [Service]
            Type=oneshot
            RemainAfterExit=true
            ExecStart=/usr/local/bin/kdump-remove-ice-module.sh
            [Install]
            WantedBy=multi-user.target
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,IyEvdXNyL2Jpbi9lbnYgYmFzaAoKIyBUaGlzIHNjcmlwdCByZW1vdmVzIHRoZSBpY2UgbW9kdWxlIGZyb20ga2R1bXAgdG8gcHJldmVudCBrZHVtcCBmYWlsdXJlcyBvbiBjZXJ0YWluIHNlcnZlcnMuCiMgVGhpcyBpcyBhIHRlbXBvcmFyeSB3b3JrYXJvdW5kIGZvciBSSEVMUExBTi0xMzgyMzYgYW5kIGNhbiBiZSByZW1vdmVkIHdoZW4gdGhhdCBpc3N1ZSBpcwojIGZpeGVkLgoKc2V0IC14CgpTRUQ9Ii91c3IvYmluL3NlZCIKR1JFUD0iL3Vzci9iaW4vZ3JlcCIKCiMgb3ZlcnJpZGUgZm9yIHRlc3RpbmcgcHVycG9zZXMKS0RVTVBfQ09ORj0iJHsxOi0vZXRjL3N5c2NvbmZpZy9rZHVtcH0iClJFTU9WRV9JQ0VfU1RSPSJtb2R1bGVfYmxhY2tsaXN0PWljZSIKCiMgZXhpdCBpZiBmaWxlIGRvZXNuJ3QgZXhpc3QKWyAhIC1mICR7S0RVTVBfQ09ORn0gXSAmJiBleGl0IDAKCiMgZXhpdCBpZiBmaWxlIGFscmVhZHkgdXBkYXRlZAoke0dSRVB9IC1GcSAke1JFTU9WRV9JQ0VfU1RSfSAke0tEVU1QX0NPTkZ9ICYmIGV4aXQgMAoKIyBUYXJnZXQgbGluZSBsb29rcyBzb21ldGhpbmcgbGlrZSB0aGlzOgojIEtEVU1QX0NPTU1BTkRMSU5FX0FQUEVORD0iaXJxcG9sbCBucl9jcHVzPTEgLi4uIGhlc3RfZGlzYWJsZSIKIyBVc2Ugc2VkIHRvIG1hdGNoIGV2ZXJ5dGhpbmcgYmV0d2VlbiB0aGUgcXVvdGVzIGFuZCBhcHBlbmQgdGhlIFJFTU9WRV9JQ0VfU1RSIHRvIGl0CiR7U0VEfSAtaSAncy9eS0RVTVBfQ09NTUFORExJTkVfQVBQRU5EPSJbXiJdKi8mICcke1JFTU9WRV9JQ0VfU1RSfScvJyAke0tEVU1QX0NPTkZ9IHx8IGV4aXQgMAo=
          mode: 448
          path: /usr/local/bin/kdump-remove-ice-module.sh

권장 kdump 작업자 노드 구성 (06-kdump-worker.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 06-kdump-enable-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - enabled: true
          name: kdump.service
  kernelArguments:
    - crashkernel=512M

18.7.6.6. 자동 CRI-O 캐시 초기화 비활성화

제어되지 않은 호스트 종료 또는 클러스터 재부팅 후 CRI-O는 전체 CRI-O 캐시를 자동으로 삭제하여 노드가 재부팅될 때 레지스트리에서 모든 이미지를 가져옵니다. 이로 인해 복구 시간이 너무 느려지거나 복구 실패가 발생할 수 있습니다. GitOps ZTP로 설치하는 단일 노드 OpenShift 클러스터에서 이러한 문제가 발생하지 않도록 하려면 클러스터 설치 중에 CRI-O 삭제 캐시 기능을 비활성화합니다.

컨트롤 플레인 노드에서 CRI-O 캐시 초기화를 비활성화하려면 권장되는 MachineConfig CR (99-crio-disable-wipe-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-crio-disable-wipe-master
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,W2NyaW9dCmNsZWFuX3NodXRkb3duX2ZpbGUgPSAiIgo=
          mode: 420
          path: /etc/crio/crio.conf.d/99-crio-disable-wipe.toml

작업자 노드에서 CRI-O 캐시 초기화를 비활성화하려면 MachineConfig CR을 권장함 (99-crio-disable-wipe-worker.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-crio-disable-wipe-worker
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      files:
        - contents:
            source: data:text/plain;charset=utf-8;base64,W2NyaW9dCmNsZWFuX3NodXRkb3duX2ZpbGUgPSAiIgo=
          mode: 420
          path: /etc/crio/crio.conf.d/99-crio-disable-wipe.toml

18.7.6.7. crun을 기본 컨테이너 런타임으로 구성

다음 ContainerRuntimeConfig CR(사용자 정의 리소스)은 crun을 컨트롤 플레인 및 작업자 노드의 기본 OCI 컨테이너 런타임으로 구성합니다. crun 컨테이너 런타임은 빠르고 가벼우며 메모리 공간이 적습니다.

중요

최적의 성능을 위해 단일 노드 OpenShift, 3-노드 OpenShift 및 표준 클러스터에서 컨트롤 플레인 및 작업자 노드에 대해 crun을 활성화합니다. CR을 적용할 때 클러스터 재부팅을 방지하려면 변경 사항을 GitOps ZTP 추가 날짜 0 설치 시간 매니페스트로 적용합니다.

컨트롤 플레인 노드에 권장되는 ContainerRuntimeConfig CR (enable-crun-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: enable-crun-master
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/master: ""
  containerRuntimeConfig:
    defaultRuntime: crun

작업자 노드에 권장되는 ContainerRuntimeConfig CR (enable-crun-worker.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: ContainerRuntimeConfig
metadata:
  name: enable-crun-worker
spec:
  machineConfigPoolSelector:
    matchLabels:
      pools.operator.machineconfiguration.openshift.io/worker: ""
  containerRuntimeConfig:
    defaultRuntime: crun

18.7.7. 설치 후 클러스터 구성 권장

클러스터 설치가 완료되면 ZTP 파이프라인에서 DU 워크로드를 실행하는 데 필요한 다음 사용자 정의 리소스(CR)를 적용합니다.

참고

GitOps ZTP v4.10 및 이전 버전에서는 MachineConfig CR을 사용하여 UEFI 보안 부팅을 구성합니다. GitOps ZTP v4.11 이상에서는 더 이상 필요하지 않습니다. v4.11에서는 클러스터를 설치하는 데 사용하는 site Config CR에서 spec.clusters.nodes.bootMode 필드를 업데이트하여 단일 노드 OpenShift 클러스터에 대해 UEFI 보안 부팅을 구성합니다. 자세한 내용은 site Config 및 GitOps ZTP를 사용하여 관리되는 클러스터 배포를 참조하십시오.

18.7.7.1. Operator

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 다음 Operator를 설치해야 합니다.

  • Local Storage Operator
  • Logging Operator
  • PTP Operator
  • SR-IOV 네트워크 Operator

또한 사용자 정의 CatalogSource CR을 구성하고 기본 OperatorHub 구성을 비활성화하고 설치하는 클러스터에서 액세스할 수 있는 ImageContentSourcePolicy 미러 레지스트리를 구성해야 합니다.

권장 스토리지 Operator 네임스페이스 및 Operator group 구성 (StorageNS.yaml,StorageOperGroup.yaml)

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-local-storage
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-local-storage
  namespace: openshift-local-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-local-storage

권장되는 Cluster Logging Operator 네임스페이스 및 Operator group 구성 (ClusterLogNS.yaml,ClusterLogOperGroup.yaml)

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  targetNamespaces:
    - openshift-logging

권장되는 PTP Operator 네임스페이스 및 Operator 그룹 구성(PtpSubscriptionNS.yaml,PtpSubscriptionOperGroup.yaml)

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
  annotations: {}
spec:
  targetNamespaces:
    - openshift-ptp

권장되는 SR-IOV Operator 네임스페이스 및 Operator 그룹 구성(SriovSubscriptionNS.yaml,SriovSubscriptionOperGroup.yaml)

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: sriov-network-operators
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  targetNamespaces:
    - openshift-sriov-network-operator

권장되는 CatalogSource 구성 (DefaultCatsrc.yaml)

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: default-cat-source
  namespace: openshift-marketplace
  annotations:
    target.workload.openshift.io/management: '{"effect": "PreferredDuringScheduling"}'
spec:
  displayName: default-cat-source
  image: $imageUrl
  publisher: Red Hat
  sourceType: grpc
  updateStrategy:
    registryPoll:
      interval: 1h
status:
  connectionState:
    lastObservedState: READY

권장되는 ImageContentSourcePolicy 구성 (DisconnectedICSP.yaml)

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
  annotations: {}
spec:
  repositoryDigestMirrors:
    - $mirrors

권장되는 OperatorHub 구성 (OperatorHub.yaml)

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
  annotations: {}
spec:
  disableAllDefaultSources: true

18.7.7.2. Operator 서브스크립션

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 다음과 같은 Subscription CR이 필요합니다. 서브스크립션은 다음 Operator를 다운로드할 위치를 제공합니다.

  • Local Storage Operator
  • Logging Operator
  • PTP Operator
  • SR-IOV 네트워크 Operator
  • SRIOV-FEC Operator

Operator 서브스크립션마다 Operator를 가져올 채널을 지정합니다. 권장 채널은 안정적입니다.

수동 또는 자동 업데이트를 지정할 수 있습니다. 자동 모드에서 Operator는 레지스트리에서 사용 가능하게 되면 채널의 최신 버전으로 자동으로 업데이트됩니다. 수동 모드에서는 새 Operator 버전이 명시적으로 승인되는 경우에만 설치됩니다.

작은 정보

서브스크립션에 수동 모드를 사용합니다. 이를 통해 예약된 유지 관리 창에 맞게 Operator 업데이트의 타이밍을 제어할 수 있습니다.

권장 Local Storage Operator 서브스크립션 (StorageSubscription.yaml)

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: local-storage-operator
  namespace: openshift-local-storage
  annotations: {}
spec:
  channel: "stable"
  name: local-storage-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

권장되는 SR-IOV Operator 서브스크립션 (SriovSubscription.yaml)

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: sriov-network-operator-subscription
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  channel: "stable"
  name: sriov-network-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

권장되는 PTP Operator 서브스크립션(PtpSubscription.yaml)

---
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ptp-operator-subscription
  namespace: openshift-ptp
  annotations: {}
spec:
  channel: "stable"
  name: ptp-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

권장 Cluster Logging Operator 서브스크립션 (ClusterLogSubscription.yaml)

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  channel: "stable"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

18.7.7.3. 클러스터 로깅 및 로그 전달

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 디버깅을 위해 로깅 및 로그 전달이 필요합니다. 다음 ClusterLoggingClusterLogForwarder CR(사용자 정의 리소스)이 필요합니다.

권장되는 클러스터 로깅 구성 (ClusterLogging.yaml)

apiVersion: logging.openshift.io/v1
kind: ClusterLogging
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  managementState: "Managed"
  collection:
    logs:
      type: "vector"

권장되는 로그 전달 구성 (ClusterLogForwarder.yaml)

apiVersion: "logging.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  outputs: $outputs
  pipelines: $pipelines

spec.outputs.url 필드를 로그가 전달되는 Kafka 서버의 URL로 설정합니다.

18.7.7.4. 성능 프로필

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 실시간 호스트 기능 및 서비스를 사용하기 위해 Node Tuning Operator 성능 프로필이 필요합니다.

참고

이전 버전의 OpenShift Container Platform에서는 Performance Addon Operator를 사용하여 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 달성하기 위해 자동 튜닝을 구현했습니다. OpenShift Container Platform 4.11 이상에서 이 기능은 Node Tuning Operator의 일부입니다.

다음 예제 PerformanceProfile CR은 필요한 단일 노드 OpenShift 클러스터 구성을 보여줍니다.

권장 성능 프로파일 구성 (PerformanceProfile.yaml)

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  # if you change this name make sure the 'include' line in TunedPerformancePatch.yaml
  # matches this name: include=openshift-node-performance-${PerformanceProfile.metadata.name}
  # Also in file 'validatorCRs/informDuValidator.yaml':
  # name: 50-performance-${PerformanceProfile.metadata.name}
  name: openshift-node-performance-profile
  annotations:
    ran.openshift.io/reference-configuration: "ran-du.redhat.com"
spec:
  additionalKernelArgs:
    - "rcupdate.rcu_normal_after_boot=0"
    - "efi=runtime"
    - "vfio_pci.enable_sriov=1"
    - "vfio_pci.disable_idle_d3=1"
    - "module_blacklist=irdma"
  cpu:
    isolated: $isolated
    reserved: $reserved
  hugepages:
    defaultHugepagesSize: $defaultHugepagesSize
    pages:
      - size: $size
        count: $count
        node: $node
  machineConfigPoolSelector:
    pools.operator.machineconfiguration.openshift.io/$mcp: ""
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numa:
    topologyPolicy: "restricted"
  # To use the standard (non-realtime) kernel, set enabled to false
  realTimeKernel:
    enabled: true
  workloadHints:
    # WorkloadHints defines the set of upper level flags for different type of workloads.
    # See https://github.com/openshift/cluster-node-tuning-operator/blob/master/docs/performanceprofile/performance_profile.md#workloadhints
    # for detailed descriptions of each item.
    # The configuration below is set for a low latency, performance mode.
    realTime: true
    highPowerConsumption: false
    perPodPowerManagement: false

표 18.13. 단일 노드 OpenShift 클러스터에 대한 PerformanceProfile CR 옵션
PerformanceProfile CR 필드설명

metadata.name

name 이 관련 GitOps ZTP CR(사용자 정의 리소스)에 설정된 다음 필드와 일치하는지 확인합니다.

  • TunedPerformancePatch.yaml에서 include=openshift-node-performance-${PerformanceProfile.metadata.name}
  • 이름: validatorCRs/informDuValidator.yaml의 50-performance-${PerformanceProfile.metadata.name}

spec.additionalKernelArgs

"EFI=runtime" 은 클러스터 호스트에 대해 UEFI 보안 부팅을 구성합니다.

spec.cpu.isolated

분리된 CPU를 설정합니다. 모든 Hyper-Threading 쌍이 일치하는지 확인합니다.

중요

예약 및 격리된 CPU 풀은 겹치지 않아야 하며 함께 사용 가능한 모든 코어에 걸쳐 있어야 합니다. 에 대해 고려하지 않은 CPU 코어로 인해 시스템에서 정의되지 않은 동작이 발생합니다.

spec.cpu.reserved

예약된 CPU를 설정합니다. 워크로드 파티셔닝이 활성화되면 시스템 프로세스, 커널 스레드 및 시스템 컨테이너 스레드가 이러한 CPU로 제한됩니다. 분리되지 않은 모든 CPU를 예약해야 합니다.

spec.hugepages.pages

  • 대규모 페이지 수 설정 (count)
  • 대규모 페이지 크기(크기)를 설정합니다.
  • nodehugepages 가 할당된 NUMA 노드로 설정합니다(노드)

spec.realTimeKernel

실시간 커널을 사용하려면 enabledtrue 로 설정합니다.

spec.workloadHints

workloadHints 를 사용하여 다른 워크로드 유형에 대한 최상위 플래그 세트를 정의합니다. 예제 구성은 짧은 대기 시간과 높은 성능을 위해 클러스터를 구성합니다.

18.7.7.5. 클러스터 시간 동기화 구성

컨트롤 플레인 또는 작업자 노드에 대한 일회성 시스템 시간 동기화 작업을 실행합니다.

컨트롤 플레인 노드에 대해 한 번의 시간 동기화 (99-sync-time-once-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 99-sync-time-once-master
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Sync time once
            After=network.service
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service

작업자 노드에 대해 한 번의 시간 동기화 (99-sync-time-once-worker.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-sync-time-once-worker
spec:
  config:
    ignition:
      version: 3.2.0
    systemd:
      units:
        - contents: |
            [Unit]
            Description=Sync time once
            After=network.service
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service

18.7.7.6. PTP

단일 노드 OpenShift 클러스터는 네트워크 시간 동기화에 PTP(Precision Time Protocol)를 사용합니다. 다음 예제 PtpConfig CR은 일반 클럭, 경계 클럭 및 마스터 클록에 필요한 PTP 구성을 보여줍니다. 적용하는 정확한 구성은 노드 하드웨어 및 특정 사용 사례에 따라 다릅니다.

권장되는 PTP 일반 클럭 구성(PtpConfigSlave.yaml)

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: slave
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "slave"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 255
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type OC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "slave"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

권장 경계 클럭 구성 (PtpConfigBoundary.yaml)

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary"
      ptp4lOpts: "-2"
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        # The interface name is hardware-specific
        [$iface_slave]
        masterOnly 0
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 248
        clockAccuracy 0xFE
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval -4
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval 0
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 135
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        max_frequency 900000000
        clock_servo pi
        sanity_freq_limit 200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0xA0
  recommend:
    - profile: "boundary"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

권장 PTP Westport 채널 e810 grandmaster 클럭 구성 (PtpConfigGmWpc.yaml)

# The grandmaster profile is provided for testing only
# It is not installed on production clusters
apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: grandmaster
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "grandmaster"
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: -r -u 0 -m -O -37 -N 8 -R 16 -s $iface_master -n 24
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      plugins:
        e810:
          enableDefaultConfig: false
          settings:
            LocalMaxHoldoverOffSet: 1500
            LocalHoldoverTimeout: 14400
            MaxInSpecOffset: 100
          pins: $e810_pins
          #  "$iface_master":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "0 1"
          ublxCmds:
            - args: #ubxtool -P 29.20 -z CFG-HW-ANT_CFG_VOLTCTRL,1
                - "-P"
                - "29.20"
                - "-z"
                - "CFG-HW-ANT_CFG_VOLTCTRL,1"
              reportOutput: false
            - args: #ubxtool -P 29.20 -e GPS
                - "-P"
                - "29.20"
                - "-e"
                - "GPS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d Galileo
                - "-P"
                - "29.20"
                - "-d"
                - "Galileo"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d GLONASS
                - "-P"
                - "29.20"
                - "-d"
                - "GLONASS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d BeiDou
                - "-P"
                - "29.20"
                - "-d"
                - "BeiDou"
              reportOutput: false
            - args: #ubxtool -P 29.20 -d SBAS
                - "-P"
                - "29.20"
                - "-d"
                - "SBAS"
              reportOutput: false
            - args: #ubxtool -P 29.20 -t -w 5 -v 1 -e SURVEYIN,600,50000
                - "-P"
                - "29.20"
                - "-t"
                - "-w"
                - "5"
                - "-v"
                - "1"
                - "-e"
                - "SURVEYIN,600,50000"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p MON-HW
                - "-P"
                - "29.20"
                - "-p"
                - "MON-HW"
              reportOutput: true
            - args: #ubxtool -P 29.20 -p CFG-MSG,1,38,300
                - "-P"
                - "29.20"
                - "-p"
                - "CFG-MSG,1,38,300"
              reportOutput: true
      ts2phcOpts: " "
      ts2phcConf: |
        [nmea]
        ts2phc.master 1
        [global]
        use_syslog  0
        verbose 1
        logging_level 7
        ts2phc.pulsewidth 100000000
        #GNSS module s /dev/ttyGNSS* -al use _0
        #cat /dev/ttyGNSS_1700_0 to find available serial port
        #example value of gnss_serialport is /dev/ttyGNSS_1700_0
        ts2phc.nmea_serialport $gnss_serialport
        leapfile  /usr/share/zoneinfo/leap-seconds.list
        [$iface_master]
        ts2phc.extts_polarity rising
        ts2phc.extts_correction 0
      ptp4lConf: |
        [$iface_master]
        masterOnly 1
        [$iface_master_1]
        masterOnly 1
        [$iface_master_2]
        masterOnly 1
        [$iface_master_3]
        masterOnly 1
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        priority1 128
        priority2 128
        domainNumber 24
        #utc_offset 37
        clockClass 6
        clockAccuracy 0x27
        offsetScaledLogVariance 0xFFFF
        free_running 0
        freq_est_interval 1
        dscp_event 0
        dscp_general 0
        dataset_comparison G.8275.x
        G.8275.defaultDS.localPriority 128
        #
        # Port Data Set
        #
        logAnnounceInterval -3
        logSyncInterval -4
        logMinDelayReqInterval -4
        logMinPdelayReqInterval 0
        announceReceiptTimeout 3
        syncReceiptTimeout 0
        delayAsymmetry 0
        fault_reset_interval -4
        neighborPropDelayThresh 20000000
        masterOnly 0
        G.8275.portDS.localPriority 128
        #
        # Run time options
        #
        assume_two_step 0
        logging_level 6
        path_trace_enabled 0
        follow_up_info 0
        hybrid_e2e 0
        inhibit_multicast_service 0
        net_sync_monitor 0
        tc_spanning_tree 0
        tx_timestamp_timeout 50
        unicast_listen 0
        unicast_master_table 0
        unicast_req_duration 3600
        use_syslog 1
        verbose 0
        summary_interval -4
        kernel_leap 1
        check_fup_sync 0
        clock_class_threshold 7
        #
        # Servo Options
        #
        pi_proportional_const 0.0
        pi_integral_const 0.0
        pi_proportional_scale 0.0
        pi_proportional_exponent -0.3
        pi_proportional_norm_max 0.7
        pi_integral_scale 0.0
        pi_integral_exponent 0.4
        pi_integral_norm_max 0.3
        step_threshold 2.0
        first_step_threshold 0.00002
        clock_servo pi
        sanity_freq_limit  200000000
        ntpshm_segment 0
        #
        # Transport options
        #
        transportSpecific 0x0
        ptp_dst_mac 01:1B:19:00:00:00
        p2p_dst_mac 01:80:C2:00:00:0E
        udp_ttl 1
        udp6_scope 0x0E
        uds_address /var/run/ptp4l
        #
        # Default interface options
        #
        clock_type BC
        network_transport L2
        delay_mechanism E2E
        time_stamping hardware
        tsproc_mode filter
        delay_filter moving_median
        delay_filter_length 10
        egressLatency 0
        ingressLatency 0
        boundary_clock_jbod 0
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0x20
  recommend:
    - profile: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"

다음 선택적 PtpOperatorConfig CR은 노드에 대한 PTP 이벤트 보고를 구성합니다.

권장되는 PTP 이벤트 구성(PtpOperatorConfigForEvent.yaml)

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
  annotations: {}
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/$mcp: ""
  ptpEventConfig:
    enableEventPublisher: true
    transportHost: "http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043"

18.7.7.7. 확장된 Tuned 프로파일

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 고성능 워크로드에 필요한 추가 성능 튜닝 구성이 필요합니다. 다음 예제 Tuned CR은 Tuned 프로필을 확장합니다.

권장되는 확장 Tuned 프로파일 구성 (TunedPerformancePatch.yaml)

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: performance-patch
  namespace: openshift-cluster-node-tuning-operator
  annotations: {}
spec:
  profile:
    - name: performance-patch
      # Please note:
      # - The 'include' line must match the associated PerformanceProfile name, following below pattern
      #   include=openshift-node-performance-${PerformanceProfile.metadata.name}
      # - When using the standard (non-realtime) kernel, remove the kernel.timer_migration override from
      #   the [sysctl] section and remove the entire section if it is empty.
      data: |
        [main]
        summary=Configuration changes profile inherited from performance created tuned
        include=openshift-node-performance-openshift-node-performance-profile
        [sysctl]
        kernel.timer_migration=1
        [scheduler]
        group.ice-ptp=0:f:10:*:ice-ptp.*
        group.ice-gnss=0:f:10:*:ice-gnss.*
        [service]
        service.stalld=start,enable
        service.chronyd=stop,disable
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: "$mcp"
      priority: 19
      profile: performance-patch

표 18.14. 단일 노드 OpenShift 클러스터에 대한 tuned CR 옵션
tuned CR 필드설명

spec.profile.data

  • spec.profile.data 에서 설정한 include 행은 연결된 PerformanceProfile CR 이름과 일치해야 합니다. 예를 들어 include=openshift-node-performance-${PerformanceProfile.metadata.name}.
  • 비실시간 커널을 사용하는 경우 [sysctl] 섹션에서 timer_migration override 행을 제거합니다.
18.7.7.8. SR-IOV

SR-IOV(Single Root I/O Virtualization)는 일반적으로 프론트haul 및 midhaul 네트워크를 활성화하는 데 사용됩니다. 다음 YAML 예제에서는 단일 노드 OpenShift 클러스터에 대해 SR-IOV를 구성합니다.

참고

SriovNetwork CR의 구성은 특정 네트워크 및 인프라 요구 사항에 따라 다릅니다.

권장되는 SriovOperatorConfig CR 구성 (SriovOperatorConfig.yaml)

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  configDaemonNodeSelector:
    "node-role.kubernetes.io/$mcp": ""
  # Injector and OperatorWebhook pods can be disabled (set to "false") below
  # to reduce the number of management pods. It is recommended to start with the
  # webhook and injector pods enabled, and only disable them after verifying the
  # correctness of user manifests.
  #   If the injector is disabled, containers using sr-iov resources must explicitly assign
  #   them in the  "requests"/"limits" section of the container spec, for example:
  #    containers:
  #    - name: my-sriov-workload-container
  #      resources:
  #        limits:
  #          openshift.io/<resource_name>:  "1"
  #        requests:
  #          openshift.io/<resource_name>:  "1"
  enableInjector: true
  enableOperatorWebhook: true
  logLevel: 0

표 18.15. 단일 노드 OpenShift 클러스터의 SriovOperatorConfig CR 옵션
SriovOperatorConfig CR 필드설명

spec.enableInjector

Injector Pod를 비활성화하여 관리 Pod 수를 줄입니다. Injector Pod가 활성화된 상태에서 시작하고 사용자 매니페스트를 확인한 후에만 비활성화합니다. 인젝터가 비활성화된 경우 SR-IOV 리소스를 사용하는 컨테이너에서 컨테이너 사양의 요청제한 섹션에 명시적으로 할당해야 합니다.

예를 들면 다음과 같습니다.

containers:
- name: my-sriov-workload-container
  resources:
    limits:
      openshift.io/<resource_name>:  "1"
    requests:
      openshift.io/<resource_name>:  "1"

spec.enableOperatorWebhook

OperatorWebhook Pod를 비활성화하여 관리 Pod 수를 줄입니다. OperatorWebhook Pod가 활성화된 상태에서 시작하고 사용자 매니페스트를 확인한 후에만 비활성화합니다.

권장되는 SriovNetwork 구성 (SriovNetwork.yaml)

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: ""
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  #  resourceName: ""
  networkNamespace: openshift-sriov-network-operator
#  vlan: ""
#  spoofChk: ""
#  ipam: ""
#  linkState: ""
#  maxTxRate: ""
#  minTxRate: ""
#  vlanQoS: ""
#  trust: ""
#  capabilities: ""

표 18.16. 단일 노드 OpenShift 클러스터에 대한 SriovNetwork CR 옵션
SriovNetwork CR 필드설명

spec.vlan

midhaul 네트워크의 VLAN을 사용하여 vlan 을 구성합니다.

권장되는 SriovNetworkNodePolicy CR 구성 (SriovNetworkNodePolicy.yaml)

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: $name
  namespace: openshift-sriov-network-operator
  annotations: {}
spec:
  # The attributes for Mellanox/Intel based NICs as below.
  #     deviceType: netdevice/vfio-pci
  #     isRdma: true/false
  deviceType: $deviceType
  isRdma: $isRdma
  nicSelector:
    # The exact physical function name must match the hardware used
    pfNames: [$pfNames]
  nodeSelector:
    node-role.kubernetes.io/$mcp: ""
  numVfs: $numVfs
  priority: $priority
  resourceName: $resourceName

표 18.17. 단일 노드 OpenShift 클러스터의 SriovNetworkPolicy CR 옵션
SriovNetworkNodePolicy CR 필드설명

spec.deviceType

deviceTypevfio-pci 또는 netdevice 로 구성합니다. Mellanox NIC의 경우 deviceType: netdevice, isRdma: true 를 설정합니다. Intel 기반 NIC의 경우 deviceType: vfio-pciisRdma: false 를 설정합니다.

spec.nicSelector.pfNames

fronthaul 네트워크에 연결된 인터페이스를 지정합니다.

spec.numVfs

fronthaul 네트워크의 VF 수를 지정합니다.

spec.nicSelector.pfNames

물리적 기능의 정확한 이름은 하드웨어와 일치해야 합니다.

권장되는 SR-IOV 커널 구성 (07-sriov-related-kernel-args-master.yaml)

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 07-sriov-related-kernel-args-master
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
    - intel_iommu=on
    - iommu=pt

18.7.7.9. Console Operator

클러스터 기능 기능을 사용하여 Console Operator가 설치되지 않도록 합니다. 노드를 중앙 집중식으로 관리하면 필요하지 않습니다. Operator를 제거하면 애플리케이션 워크로드에 대한 추가 공간 및 용량이 제공됩니다.

관리 클러스터를 설치하는 동안 Console Operator를 비활성화하려면 siteConfig CR(사용자 정의 리소스)의 spec.clusters.0.install Config Overrides 필드에 다음을 설정합니다.

installConfigOverrides:  "{\"capabilities\":{\"baselineCapabilitySet\": \"None\" }}"
18.7.7.10. Alertmanager

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 OpenShift Container Platform 모니터링 구성 요소에서 사용하는 CPU 리소스가 감소해야 합니다. 다음 ConfigMap CR(사용자 정의 리소스)은 Alertmanager를 비활성화합니다.

권장 클러스터 모니터링 구성(ReduceMonitoringFootprint.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
  annotations: {}
data:
  config.yaml: |
    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    telemeterClient:
      enabled: false
    prometheusK8s:
       retention: 24h

18.7.7.11. Operator Lifecycle Manager

분산 단위 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 CPU 리소스에 대한 일관된 액세스 권한이 필요합니다. OLM(Operator Lifecycle Manager)은 정기적으로 Operator에서 성능 데이터를 수집하여 CPU 사용률이 증가합니다. 다음 ConfigMap CR(사용자 정의 리소스)은 OLM의 Operator 성능 데이터 수집을 비활성화합니다.

권장되는 클러스터 OLM 구성(ReduceOLMFootprint.yaml)

apiVersion: v1
kind: ConfigMap
metadata:
  name: collect-profiles-config
  namespace: openshift-operator-lifecycle-manager
data:
  pprof-config.yaml: |
    disabled: True

18.7.7.12. LVM 스토리지

LVM(Logical Volume Manager) 스토리지를 사용하여 단일 노드 OpenShift 클러스터에서 로컬 스토리지를 동적으로 프로비저닝할 수 있습니다.

참고

단일 노드 OpenShift에 권장되는 스토리지 솔루션은 Local Storage Operator입니다. 또는 LVM 스토리지를 사용할 수 있지만 추가 CPU 리소스를 할당해야 합니다.

다음 YAML 예제에서는 OpenShift Container Platform 애플리케이션에서 사용할 수 있도록 노드의 스토리지를 구성합니다.

권장되는 LVMCluster 구성(StorageLVMCluster.yaml)

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: odf-lvmcluster
  namespace: openshift-storage
spec:
  storage:
    deviceClasses:
    - name: vg1
      deviceSelector:
        paths:
        - /usr/disk/by-path/pci-0000:11:00.0-nvme-1
      thinPoolConfig:
        name: thin-pool-1
        overprovisionRatio: 10
        sizePercent: 90

표 18.18. 단일 노드 OpenShift 클러스터에 대한 LVMCluster CR 옵션
LVMCluster CR 필드설명

deviceSelector.paths

LVM 스토리지에 사용되는 디스크를 구성합니다. 디스크를 지정하지 않으면 LVM 스토리지에서 지정된 씬 풀에서 사용되지 않는 모든 디스크를 사용합니다.

18.7.7.13. 네트워크 진단

DU 워크로드를 실행하는 단일 노드 OpenShift 클러스터에는 이러한 Pod에서 생성한 추가 로드를 줄이기 위해 Pod 간 네트워크 연결 검사가 덜 필요합니다. 다음 CR(사용자 정의 리소스)에서는 이러한 검사를 비활성화합니다.

권장되는 네트워크 진단 구성 (DisableSnoNetworkDiag.yaml)

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  annotations: {}
spec:
  disableNetworkDiagnostics: true

18.8. vDU 애플리케이션 워크로드에 대한 단일 노드 OpenShift 클러스터 튜닝 검증

vDU(가상 분산 단위) 애플리케이션을 배포하려면 클러스터 호스트 펌웨어 및 기타 다양한 클러스터 구성 설정을 튜닝하고 구성해야 합니다. 다음 정보를 사용하여 vDU 워크로드를 지원하는 클러스터 구성을 검증합니다.

18.8.1. vDU 클러스터 호스트의 권장 펌웨어 구성

다음 표를 기반으로 OpenShift Container Platform 4.14에서 실행되는 vDU 애플리케이션의 클러스터 호스트 펌웨어를 구성합니다.

참고

다음 표는 vDU 클러스터 호스트 펌웨어 구성에 대한 일반적인 권장 사항입니다. 정확한 펌웨어 설정은 요구 사항과 특정 하드웨어 플랫폼에 따라 달라집니다. 펌웨어의 자동 설정은 제로 터치 프로비저닝 파이프라인에 의해 처리되지 않습니다.

표 18.19. 권장되는 클러스터 호스트 펌웨어 설정
펌웨어 설정설정설명

HyperTransport (HT)

enabled

HT(HyperTransport) 버스는 AMD에서 개발한 버스 기술입니다. HT는 호스트 메모리의 구성 요소와 다른 시스템 주변 장치 간의 고속 링크를 제공합니다.

UEFI

enabled

vDU 호스트에 대해 UEFI에서 부팅을 활성화합니다.

CPU 전원 및 성능 정책

성능

CPU 전원 및 성능 정책을 설정하여 에너지 효율성에 대한 성능을 위해 시스템을 최적화합니다.

코어 빈도 확장 해제

비활성화됨

Uncore Frequency Scaling을 비활성화하여 CPU의 코어가 아닌 부분 및 빈도가 독립적으로 설정되지 않도록 합니다.

Uncore frequency

최대

캐시 및 메모리 컨트롤러와 같은 CPU의 코어가 아닌 부분을 최대 작업 빈도로 설정합니다.

성능 P-limit

비활성화됨

프로세서의 Uncore 빈도 조정을 방지하려면 성능 P 제한을 비활성화합니다.

향상된 Intel® SpeedStep Tech

enabled

향상된 Intel SpeedStep을 활성화하여 시스템의 프로세서 마운드 및 코어 빈도를 동적으로 조정하여 호스트의 전력 소비 및 열 생산량을 줄일 수 있습니다.

Intel® Cryostat Boost Technology

enabled

Intel 기반 CPU용 Cryostat Boost Technology를 사용하면 전력, 현재 및 온도 사양 제한 미만으로 작동하는 경우 프로세서 코어가 정격된 작동 빈도보다 빠르게 실행될 수 있습니다.

Intel Configurable TDP

enabled

CPU에 대해 TDP(rmal Design Power)를 활성화합니다.

구성 가능한 TDP 수준

수준 2

TDP 수준은 특정 성능 평가에 필요한 CPU 전력 소비를 설정합니다. TDP 수준 2는 전력 소비로 CPU를 가장 안정적인 성능 수준으로 설정합니다.

에너지 효율성:

비활성화됨

프로세서는 에너지 효율성 기반 정책을 사용하지 못하도록 energy Efficient Cryostat를 비활성화합니다.

하드웨어 P-States

활성화 또는 비활성화

OS가 제어하는 P-States를 활성화하여 전원 저장 구성을 허용합니다. P 상태(성능 상태 )를 비활성화하여 전력 소비에 따른 성능을 위해 운영 체제 및 CPU를 최적화합니다.

패키지 C-State

C0/C1 상태

C0 또는 C1 상태를 사용하여 프로세서를 완전히 활성 상태(C0)로 설정하거나 소프트웨어(C1)에서 실행되는 CPU 내부 시계를 중지합니다.

C1E

비활성화됨

CPU Enhanced Halt(C1E)는 Intel 칩의 전원 저장 기능입니다. C1E를 비활성화하면 비활성 상태에서 운영 체제가 CPU에 halt 명령을 보내지 않습니다.

프로세서 C6

비활성화됨

C6 전원은 유휴 CPU 코어 및 캐시를 자동으로 비활성화하는 CPU 기능입니다. C6을 비활성화하면 시스템 성능이 향상됩니다.

하위 NUMA

비활성화됨

하위 NUMA 클러스터링은 프로세서 코어, 캐시 및 메모리를 여러 NUMA 도메인으로 나눕니다. 이 옵션을 비활성화하면 대기 시간에 민감한 워크로드의 성능이 향상될 수 있습니다.

참고

호스트의 펌웨어에서 글로벌 SR-IOV 및 VT-d 설정을 활성화합니다. 이러한 설정은 베어 메탈 환경과 관련이 있습니다.

참고

C-states 및 OS가 제어하는 P-States 를 모두 활성화하여 Pod 전원 관리를 허용합니다.

18.8.2. vDU 애플리케이션을 실행하기 위한 권장 클러스터 구성

vDU(가상 분산 장치) 애플리케이션을 실행하는 클러스터에는 고도로 조정되고 최적화된 구성이 필요합니다. 다음 정보는 OpenShift Container Platform 4.14 클러스터에서 vDU 워크로드를 지원하는 데 필요한 다양한 요소를 설명합니다.

18.8.2.4. 실시간 커널 버전 확인

항상 OpenShift Container Platform 클러스터에서 최신 버전의 실시간 커널을 사용하십시오. 클러스터에서 사용 중인 커널 버전을 잘 모를 경우 현재 실시간 커널 버전을 릴리스 버전과 다음 절차와 비교할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • podman 을 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 클러스터 버전을 가져옵니다.

    $ OCP_VERSION=$(oc get clusterversion version -o jsonpath='{.status.desired.version}{"\n"}')
  2. 릴리스 이미지 SHA 번호를 가져옵니다.

    $ DTK_IMAGE=$(oc adm release info --image-for=driver-toolkit quay.io/openshift-release-dev/ocp-release:$OCP_VERSION-x86_64)
  3. 릴리스 이미지 컨테이너를 실행하고 클러스터의 현재 릴리스와 함께 패키지된 커널 버전을 추출합니다.

    $ podman run --rm $DTK_IMAGE rpm -qa | grep 'kernel-rt-core-' | sed 's#kernel-rt-core-##'

    출력 예

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

    이는 릴리스와 함께 제공되는 기본 실시간 커널 버전입니다.

    참고

    실시간 커널은 커널 버전의 .rt 문자열로 표시됩니다.

검증

클러스터의 현재 릴리스에 대해 나열된 커널 버전이 클러스터에서 실행 중인 실제 실시간 커널과 일치하는지 확인합니다. 다음 명령을 실행하여 실행 중인 실시간 커널 버전을 확인합니다.

  1. 클러스터 노드에 대한 원격 쉘 연결을 엽니다.

    $ oc debug node/<node_name>
  2. 실시간 커널 버전을 확인합니다.

    sh-4.4# uname -r

    출력 예

    4.18.0-305.49.1.rt7.121.el8_4.x86_64

18.8.3. 권장 클러스터 구성이 적용되었는지 확인

클러스터가 올바른 구성을 실행하고 있는지 확인할 수 있습니다. 다음 절차에서는 OpenShift Container Platform 4.14 클러스터에서 DU 애플리케이션을 배포하는 데 필요한 다양한 구성을 확인하는 방법을 설명합니다.

사전 요구 사항

  • 클러스터를 배포하고 vDU 워크로드에 맞게 조정했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. 기본 OperatorHub 소스가 비활성화되어 있는지 확인합니다. 다음 명령을 실행합니다.

    $ oc get operatorhub cluster -o yaml

    출력 예

    spec:
        disableAllDefaultSources: true

  2. 다음 명령을 실행하여 모든 필요한 CatalogSource 리소스에 워크로드 파티셔닝(PreferredDuringScheduling)에 대한 주석이 있는지 확인합니다.

    $ oc get catalogsource -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.target\.workload\.openshift\.io/management}{"\n"}{end}'

    출력 예

    certified-operators -- {"effect": "PreferredDuringScheduling"}
    community-operators -- {"effect": "PreferredDuringScheduling"}
    ran-operators 1
    redhat-marketplace -- {"effect": "PreferredDuringScheduling"}
    redhat-operators -- {"effect": "PreferredDuringScheduling"}

    1
    주석이 없는 CatalogSource 리소스도 반환됩니다. 이 예에서 ran-operators CatalogSource 리소스에는 주석이 추가되지 않으며 PreferredDuringScheduling 주석이 없습니다.
    참고

    올바르게 구성된 vDU 클러스터에는 주석이 지정된 단일 카탈로그 소스만 나열됩니다.

  3. 워크로드 파티셔닝을 위해 해당하는 모든 OpenShift Container Platform Operator 네임스페이스에 주석이 추가되었는지 확인합니다. 여기에는 코어 OpenShift Container Platform과 함께 설치된 모든 Operator 및 참조 DU 튜닝 구성에 포함된 추가 Operator 세트가 포함됩니다. 다음 명령을 실행합니다.

    $ oc get namespaces -A -o jsonpath='{range .items[*]}{.metadata.name}{" -- "}{.metadata.annotations.workload\.openshift\.io/allowed}{"\n"}{end}'

    출력 예

    default --
    openshift-apiserver -- management
    openshift-apiserver-operator -- management
    openshift-authentication -- management
    openshift-authentication-operator -- management

    중요

    추가 Operator는 워크로드 파티셔닝을 위해 주석을 달 수 없습니다. 이전 명령의 출력에서 -- separator 오른쪽에 값을 지정하지 않고 추가 Operator를 나열해야 합니다.

  4. ClusterLogging 구성이 올바른지 확인합니다. 다음 명령을 실행합니다.

    1. 적절한 입력 및 출력 로그가 구성되어 있는지 확인합니다.

      $ oc get -n openshift-logging ClusterLogForwarder instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogForwarder
      metadata:
        creationTimestamp: "2022-07-19T21:51:41Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "1030342"
        uid: 8c1a842d-80c5-447a-9150-40350bdf40f0
      spec:
        inputs:
        - infrastructure: {}
          name: infra-logs
        outputs:
        - name: kafka-open
          type: kafka
          url: tcp://10.46.55.190:9092/test
        pipelines:
        - inputRefs:
          - audit
          name: audit-logs
          outputRefs:
          - kafka-open
        - inputRefs:
          - infrastructure
          name: infrastructure-logs
          outputRefs:
          - kafka-open
      ...

    2. 큐레이션 일정이 애플리케이션에 적합한지 확인합니다.

      $ oc get -n openshift-logging clusterloggings.logging.openshift.io instance -o yaml

      출력 예

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        creationTimestamp: "2022-07-07T18:22:56Z"
        generation: 1
        name: instance
        namespace: openshift-logging
        resourceVersion: "235796"
        uid: ef67b9b8-0e65-4a10-88ff-ec06922ea796
      spec:
        collection:
          logs:
            fluentd: {}
            type: fluentd
        curation:
          curator:
            schedule: 30 3 * * *
          type: curator
        managementState: Managed
      ...

  5. 다음 명령을 실행하여 웹 콘솔이 비활성화(managementState: Removed)인지 확인합니다.

    $ oc get consoles.operator.openshift.io cluster -o jsonpath="{ .spec.managementState }"

    출력 예

    Removed

  6. 다음 명령을 실행하여 클러스터 노드에서 chronyd 가 비활성화되어 있는지 확인합니다.

    $ oc debug node/<node_name>

    노드에서 chronyd 의 상태를 확인합니다.

    sh-4.4# chroot /host
    sh-4.4# systemctl status chronyd

    출력 예

    ● 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)

  7. linuxptp-daemon 컨테이너 및 PTP 관리 클라이언트(pmc) 툴에 대한 원격 쉘 연결을 사용하여 PTP 인터페이스가 기본 클록에 성공적으로 동기화되었는지 확인합니다.

    1. 다음 명령을 실행하여 linuxptp-daemon Pod의 이름으로 $PTP_POD_NAME 변수를 설정합니다.

      $ PTP_POD_NAME=$(oc get pods -n openshift-ptp -l app=linuxptp-daemon -o name)
    2. 다음 명령을 실행하여 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'

      출력 예

      sending: GET PORT_DATA_SET
        3cecef.fffe.7a7020-1 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-1
          portState               SLAVE
          logMinDelayReqInterval  -4
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2
        3cecef.fffe.7a7020-2 seq 0 RESPONSE MANAGEMENT PORT_DATA_SET
          portIdentity            3cecef.fffe.7a7020-2
          portState               LISTENING
          logMinDelayReqInterval  0
          peerMeanPathDelay       0
          logAnnounceInterval     1
          announceReceiptTimeout  3
          logSyncInterval         0
          delayMechanism          1
          logMinPdelayReqInterval 0
          versionNumber           2

    3. 다음 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'

      출력 예

      sending: GET TIME_STATUS_NP
        3cecef.fffe.7a7020-0 seq 0 RESPONSE MANAGEMENT TIME_STATUS_NP
          master_offset              10 1
          ingress_time               1657275432697400530
          cumulativeScaledRateOffset +0.000000000
          scaledLastGmPhaseChange    0
          gmTimeBaseIndicator        0
          lastGmPhaseChange          0x0000'0000000000000000.0000
          gmPresent                  true 2
          gmIdentity                 3c2c30.ffff.670e00

      1
      master_offset 은 -100과 100 ns 사이여야 합니다.
      2
      PTP 시계가 마스터에 동기화되고 로컬 클록이 마스터 클록이 아님을 나타냅니다.
    4. /var/run/ptp4l.0.config 의 값에 해당하는 예상 마스터 오프셋 값이 linuxptp-daemon-container 로그에 있는지 확인합니다.

      $ oc logs $PTP_POD_NAME -n openshift-ptp -c linuxptp-daemon-container

      출력 예

      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

  8. 다음 명령을 실행하여 SR-IOV 구성이 올바른지 확인합니다.

    1. SriovOperatorConfig 리소스의 disableDrain 값이 true 로 설정되어 있는지 확인합니다.

      $ oc get sriovoperatorconfig -n openshift-sriov-network-operator default -o jsonpath="{.spec.disableDrain}{'\n'}"

      출력 예

      true

    2. 다음 명령을 실행하여 SriovNetworkNodeState 동기화 상태가 Succeeded 인지 확인합니다.

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o jsonpath="{.items[*].status.syncStatus}{'\n'}"

      출력 예

      Succeeded

    3. SR-IOV용으로 구성된 각 인터페이스에서Vfs(가상 기능)의 예상 수와 구성이 있고 .status.interfaces 필드에 올바른지 확인합니다. 예를 들면 다음과 같습니다.

      $ oc get SriovNetworkNodeStates -n openshift-sriov-network-operator -o yaml

      출력 예

      apiVersion: v1
      items:
      - apiVersion: sriovnetwork.openshift.io/v1
        kind: SriovNetworkNodeState
      ...
        status:
          interfaces:
          ...
          - Vfs:
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.0
              vendor: "8086"
              vfID: 0
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.1
              vendor: "8086"
              vfID: 1
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.2
              vendor: "8086"
              vfID: 2
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.3
              vendor: "8086"
              vfID: 3
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.4
              vendor: "8086"
              vfID: 4
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.5
              vendor: "8086"
              vfID: 5
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.6
              vendor: "8086"
              vfID: 6
            - deviceID: 154c
              driver: vfio-pci
              pciAddress: 0000:3b:0a.7
              vendor: "8086"
              vfID: 7

  9. 클러스터 성능 프로필이 올바른지 확인합니다. cpuhugepages 섹션은 하드웨어 구성에 따라 다릅니다. 다음 명령을 실행합니다.

    $ oc get PerformanceProfile openshift-node-performance-profile -o yaml

    출력 예

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      creationTimestamp: "2022-07-19T21:51:31Z"
      finalizers:
      - foreground-deletion
      generation: 1
      name: openshift-node-performance-profile
      resourceVersion: "33558"
      uid: 217958c0-9122-4c62-9d4d-fdc27c31118c
    spec:
      additionalKernelArgs:
      - idle=poll
      - rcupdate.rcu_normal_after_boot=0
      - efi=runtime
      cpu:
        isolated: 2-51,54-103
        reserved: 0-1,52-53
      hugepages:
        defaultHugepagesSize: 1G
        pages:
        - count: 32
          size: 1G
      machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/master: ""
      net:
        userLevelNetworking: true
      nodeSelector:
        node-role.kubernetes.io/master: ""
      numa:
        topologyPolicy: restricted
      realTimeKernel:
        enabled: true
    status:
      conditions:
      - lastHeartbeatTime: "2022-07-19T21:51:31Z"
        lastTransitionTime: "2022-07-19T21:51:31Z"
        status: "True"
        type: Available
      - lastHeartbeatTime: "2022-07-19T21:51:31Z"
        lastTransitionTime: "2022-07-19T21:51:31Z"
        status: "True"
        type: Upgradeable
      - lastHeartbeatTime: "2022-07-19T21:51:31Z"
        lastTransitionTime: "2022-07-19T21:51:31Z"
        status: "False"
        type: Progressing
      - lastHeartbeatTime: "2022-07-19T21:51:31Z"
        lastTransitionTime: "2022-07-19T21:51:31Z"
        status: "False"
        type: Degraded
      runtimeClass: performance-openshift-node-performance-profile
      tuned: openshift-cluster-node-tuning-operator/openshift-node-performance-openshift-node-performance-profile

    참고

    CPU 설정은 서버에서 사용 가능한 코어 수에 따라 다르며 워크로드 파티셔닝 설정과 일치해야 합니다. hugepages 구성은 서버와 애플리케이션에 따라 다릅니다.

  10. 다음 명령을 실행하여 PerformanceProfile 이 클러스터에 성공적으로 적용되었는지 확인합니다.

    $ oc get performanceprofile openshift-node-performance-profile -o jsonpath="{range .status.conditions[*]}{ @.type }{' -- '}{@.status}{'\n'}{end}"

    출력 예

    Available -- True
    Upgradeable -- True
    Progressing -- False
    Degraded -- False

  11. 다음 명령을 실행하여 Tuned 성능 패치 설정을 확인합니다.

    $ oc get tuneds.tuned.openshift.io -n openshift-cluster-node-tuning-operator performance-patch -o yaml

    출력 예

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      creationTimestamp: "2022-07-18T10:33:52Z"
      generation: 1
      name: performance-patch
      namespace: openshift-cluster-node-tuning-operator
      resourceVersion: "34024"
      uid: f9799811-f744-4179-bf00-32d4436c08fd
    spec:
      profile:
      - data: |
          [main]
          summary=Configuration changes profile inherited from performance created tuned
          include=openshift-node-performance-openshift-node-performance-profile
          [bootloader]
          cmdline_crash=nohz_full=2-23,26-47 1
          [sysctl]
          kernel.timer_migration=1
          [scheduler]
          group.ice-ptp=0:f:10:*:ice-ptp.*
          [service]
          service.stalld=start,enable
          service.chronyd=stop,disable
        name: performance-patch
      recommend:
      - machineConfigLabels:
          machineconfiguration.openshift.io/role: master
        priority: 19
        profile: performance-patch

    1
    cmdline=nohz_full= 의 cpu 목록은 하드웨어 구성에 따라 다릅니다.
  12. 다음 명령을 실행하여 클러스터 네트워킹 진단이 비활성화되었는지 확인합니다.

    $ oc get networks.operator.openshift.io cluster -o jsonpath='{.spec.disableNetworkDiagnostics}'

    출력 예

    true

  13. Kubelet 하우스키핑 간격이 느린 속도로 조정되었는지 확인합니다. 이는 containerMountNS 머신 구성에 설정됩니다. 다음 명령을 실행합니다.

    $ oc describe machineconfig container-mount-namespace-and-kubelet-conf-master | grep OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION

    출력 예

    Environment="OPENSHIFT_MAX_HOUSEKEEPING_INTERVAL_DURATION=60s"

  14. 다음 명령을 실행하여 Grafana 및 alertManagerMain 이 비활성화되어 Prometheus 보존 기간이 24h로 설정되어 있는지 확인합니다.

    $ oc get configmap cluster-monitoring-config -n openshift-monitoring -o jsonpath="{ .data.config\.yaml }"

    출력 예

    grafana:
      enabled: false
    alertmanagerMain:
      enabled: false
    prometheusK8s:
       retention: 24h

    1. 다음 명령을 사용하여 Grafana 및 alertManagerMain 경로가 클러스터에 없는지 확인합니다.

      $ oc get route -n openshift-monitoring alertmanager-main
      $ oc get route -n openshift-monitoring grafana

      두 쿼리 모두 서버 오류(NotFound) 메시지를 반환해야 합니다.

  15. 다음 명령을 실행하여 PerformanceProfile,Tuned performance-patch, 워크로드 파티셔닝 및 커널 명령줄 인수에 대해 예약된 CPU가 최소 4개 이상 있는지 확인합니다.

    $ oc get performanceprofile -o jsonpath="{ .items[0].spec.cpu.reserved }"

    출력 예

    0-3

    참고

    워크로드 요구 사항에 따라 추가 예약된 CPU를 할당해야 할 수 있습니다.

18.9. SiteConfig 리소스를 사용한 고급 관리 클러스터 구성

SiteConfig CR(사용자 정의 리소스)을 사용하여 설치 시 관리 클러스터에 사용자 정의 기능 및 구성을 배포할 수 있습니다.

18.9.1. GitOps ZTP 파이프라인에서 추가 설치 매니페스트 사용자 정의

GitOps ZTP(ZTP) 파이프라인의 설치 단계에 포함할 추가 매니페스트 세트를 정의할 수 있습니다. 이러한 매니페스트는 site Config CR (사용자 정의 리소스)에 연결되며 설치 중에 클러스터에 적용됩니다. 설치 시 MachineConfig CR을 포함하면 설치 프로세스의 효율성이 향상됩니다.

사전 요구 사항

  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. GitOps ZTP 파이프라인에서 클러스터 설치를 사용자 정의하는 데 사용하는 추가 매니페스트 CR 세트를 생성합니다.
  2. 사용자 지정 /siteconfig 디렉터리에서 추가 매니페스트를 위한 하위 디렉터리 /custom-manifest 를 생성합니다. 다음 예제에서는 /custom-manifest 폴더가 있는 샘플 /siteconfig 를 보여줍니다.

    siteconfig
    ├── site1-sno-du.yaml
    ├── site2-standard-du.yaml
    ├── extra-manifest/
    └── custom-manifest
        └── 01-example-machine-config.yaml
    참고

    전체에서 사용되는 하위 디렉터리 이름 /custom-manifest/extra-manifest 는 예제 이름 전용입니다. 이러한 이름을 사용할 필요는 없으며 이러한 하위 디렉터리의 이름을 지정하는 방법에 대한 제한은 없습니다. 이 예에서 /extra-manifestztp-site-generate 컨테이너에서 /extra-manifest 의 콘텐츠를 저장하는 Git 하위 디렉터리를 나타냅니다.

  3. 사용자 정의 매니페스트 CR을 siteconfig/custom-manifest 디렉터리에 추가합니다.
  4. SiteConfig CR에서 extraManifests.searchPaths 필드에 디렉터리 이름을 입력합니다. 예를 들면 다음과 같습니다.

    clusters:
    - clusterName: "example-sno"
      networkType: "OVNKubernetes"
      extraManifests:
        searchPaths:
          - extra-manifest/ 1
          - custom-manifest/ 2
    1
    ztp-site-generate 컨테이너에서 복사한 매니페스트의 폴더입니다.
    2
    사용자 정의 매니페스트용 폴더입니다.
  5. SiteConfig,/extra-manifest CR 및 /custom-manifest CR을 저장하고 사이트 구성 리포지터리로 푸시합니다.

클러스터 프로비저닝 중에 GitOps ZTP 파이프라인은 /custom-manifest 디렉터리의 CR을 extra-manifest /에 저장된 추가 매니페스트 세트에 추가합니다.

참고

4.14 버전의 extraManifestPath 에는 사용 중단 경고가 적용됩니다.

extraManifestPath 는 계속 지원되지만 extraManifests.searchPaths 를 사용하는 것이 좋습니다. SiteConfig 파일에 extraManifests.searchPaths 를 정의하는 경우 GitOps ZTP 파이프라인은 사이트 설치 중에 ztp-site-generate 컨테이너에서 매니페스트를 가져오지 않습니다.

Siteconfig CR에서 extraManifestPathextraManifests.searchPaths 를 모두 정의하는 경우 extraManifests.searchPaths 에 정의된 설정이 우선합니다.

ztp-site-generate 컨테이너에서 /extra-manifest 의 내용을 추출하여 GIT 리포지토리로 내보내는 것이 좋습니다.

18.9.2. siteConfig 필터를 사용하여 사용자 정의 리소스 필터링

필터를 사용하면 GitOps ZTP(ZTP) 파이프라인의 설치 단계에서 사용할 다른 CR을 포함하거나 제외하도록 SiteConfig CR(사용자 정의 리소스)을 쉽게 사용자 지정할 수 있습니다.

SiteConfig CR의 include 또는 exclude 기본값 을 포함하거나 제외하려는 특정 추가Manifest RAN CR 목록과 함께 지정할 수 있습니다. include Default를 포함 으로 설정하면 GitOps ZTP 파이프라인이 설치 중에 /source-crs/extra-manifest 의 모든 파일을 적용합니다. excludeinclusionDefault 를 설정하면 그 반대입니다.

기본적으로 포함된 /source-crs/extra-manifest 폴더에서 개별 CR을 제외할 수 있습니다. 다음 예제에서는 설치 시 /source-crs/extra-manifest/03-sctp-machine-config-worker.yaml CR을 제외하도록 사용자 정의 단일 노드 OpenShift SiteConfig CR을 구성합니다.

일부 추가 필터링 시나리오도 설명되어 있습니다.

사전 요구 사항

  • 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. GitOps ZTP 파이프라인이 03-sctp-machine-config-worker.yaml CR 파일을 적용하지 못하도록 site Config CR에 다음 YAML을 적용합니다.

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    metadata:
      name: "site1-sno-du"
      namespace: "site1-sno-du"
    spec:
      baseDomain: "example.com"
      pullSecretRef:
        name: "assisted-deployment-pull-secret"
      clusterImageSetNameRef: "openshift-4.14"
      sshPublicKey: "<ssh_public_key>"
      clusters:
    - clusterName: "site1-sno-du"
      extraManifests:
        filter:
          exclude:
            - 03-sctp-machine-config-worker.yaml

    GitOps ZTP 파이프라인은 설치 중에 03-sctp-machine-config-worker.yaml CR을 건너뜁니다. /source-crs/extra-manifest 의 다른 모든 CR이 적용됩니다.

  2. SiteConfig CR을 저장하고 사이트 구성 리포지토리로 변경 사항을 내보냅니다.

    GitOps ZTP 파이프라인은 site Config 필터 명령에 따라 적용되는 CR을 모니터링하고 조정합니다.

  3. 선택 사항: GitOps ZTP 파이프라인이 클러스터 설치 중에 모든 /source-crs/extra-manifest CR을 적용하지 않도록 하려면 site Config CR에서 다음 YAML을 적용합니다.

    - clusterName: "site1-sno-du"
      extraManifests:
        filter:
          inclusionDefault: exclude
  4. 선택 사항: /source-crs/extra-manifest RAN CR을 모두 제외하고 설치 중에 사용자 지정 CR 파일을 포함하려면 사용자 정의 SiteConfig CR을 편집하여 사용자 정의 매니페스트 폴더 및 포함 파일을 설정합니다. 예를 들면 다음과 같습니다.

    clusters:
    - clusterName: "site1-sno-du"
      extraManifestPath: "<custom_manifest_folder>" 1
      extraManifests:
        filter:
          inclusionDefault: exclude  2
          include:
            - custom-sctp-machine-config-worker.yaml
    1
    < custom_manifest_folder >를 사용자 정의 설치 CR이 포함된 폴더의 이름으로 바꿉니다(예: user-custom-manifest/ ).
    2
    GitOps ZTP 파이프라인이 설치 중에 /source-crs/extra-manifest 에 파일을 적용하지 못하도록 inclusionDefaultexclude 로 설정합니다.

    다음 예제에서는 사용자 지정 폴더 구조를 보여줍니다.

    siteconfig
      ├── site1-sno-du.yaml
      └── user-custom-manifest
            └── custom-sctp-machine-config-worker.yaml

18.9.3. SiteConfig CR을 사용하여 노드 삭제

SiteConfig CR(사용자 정의 리소스)을 사용하면 노드를 삭제하고 다시 프로비저닝할 수 있습니다. 이 방법은 노드를 수동으로 삭제하는 것보다 효율적입니다.

사전 요구 사항

  • 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리할 수 있는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. bmac.agent-install.openshift.io/remove-agent-and-node-on-delete=true 주석을 포함하도록 SiteConfig CR을 업데이트하고 변경 사항을 Git 리포지토리로 내보냅니다.

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    metadata:
      name: "cnfdf20"
      namespace: "cnfdf20"
    spec:
      clusters:
        nodes:
        - hostname: node6
          role: "worker"
          crAnnotations:
            add:
              BareMetalHost:
                bmac.agent-install.openshift.io/remove-agent-and-node-on-delete: true
    # ...
  2. 다음 명령을 실행하여 BareMetalHost 오브젝트에 주석이 추가되었는지 확인합니다.

    oc get bmh -n <managed-cluster-namespace> <bmh-object> -ojsonpath='{.metadata}' | jq -r '.annotations["bmac.agent-install.openshift.io/remove-agent-and-node-on-delete"]'

    출력 예

    true

  3. crSuppression.BareMetalHost 주석을 포함하도록 SiteConfig CR을 업데이트하여 BareMetalHost CR 생성을 비활성화합니다.

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    metadata:
      name: "cnfdf20"
      namespace: "cnfdf20"
    spec:
      clusters:
      - nodes:
        - hostName: node6
          role: "worker"
          crSuppression:
          - BareMetalHost
    # ...
  4. 변경 사항을 Git 리포지토리로 푸시하고 프로비저닝 해제가 시작될 때까지 기다립니다. BareMetalHost CR의 상태는 프로비저닝 해제 로 변경되어야 합니다. BareMetalHost 가 프로비저닝 해제가 완료될 때까지 기다린 후 완전히 삭제됩니다.

검증

  1. 다음 명령을 실행하여 작업자 노드의 BareMetalHostAgent CR이 hub 클러스터에서 삭제되었는지 확인합니다.

    $ oc get bmh -n <cluster-ns>
    $ oc get agent -n <cluster-ns>
  2. 다음 명령을 실행하여 노드 레코드가 spoke 클러스터에서 삭제되었는지 확인합니다.

    $ oc get nodes
    참고

    시크릿을 사용하여 작업하는 경우 ArgoCD에는 삭제 후 다시 동기화를 완료하기 위해 시크릿이 필요하므로 시크릿을 너무 빨리 삭제하면 문제가 발생할 수 있습니다. 현재 ArgoCD 동기화가 완료되면 노드 정리 후에만 보안을 삭제합니다.

다음 단계

노드를 다시 프로비저닝하려면 이전에 SiteConfig 에 추가된 변경 사항을 삭제하고, 변경 사항을 Git 리포지토리로 푸시하고 동기화가 완료될 때까지 기다립니다. 이렇게 하면 작업자 노드의 BareMetalHost CR이 다시 생성되고 노드를 다시 설치합니다.

18.10. PolicyGenTemplate 리소스를 사용한 고급 관리 클러스터 구성

PolicyGenTemplate CR을 사용하여 관리 클러스터에 사용자 지정 기능을 배포할 수 있습니다.

18.10.1. 클러스터에 추가 변경 사항 배포

기본 GitOps ZTP(ZTP) 파이프라인 구성 외부에서 클러스터 구성을 변경해야 하는 경우 다음 세 가지 옵션이 있습니다.

GitOps ZTP 파이프라인이 완료된 후 추가 구성을 적용합니다.
GitOps ZTP 파이프라인 배포가 완료되면 배포된 클러스터가 애플리케이션 워크로드에 대해 준비됩니다. 이 시점에서 추가 Operator를 설치하고 요구 사항과 관련된 구성을 적용할 수 있습니다. 추가 구성이 플랫폼 성능 또는 할당된 CPU 예산에 부정적인 영향을 미치지 않도록 합니다.
GitOps ZTP 라이브러리에 콘텐츠 추가
GitOps ZTP 파이프라인을 사용하여 배포하는 기본 소스 CR(사용자 정의 리소스)은 필요에 따라 사용자 정의 콘텐츠를 사용하여 보강할 수 있습니다.
클러스터 설치에 대한 추가 매니페스트 생성
추가 매니페스트는 설치 중에 적용되며 설치 프로세스를 보다 효율적으로 만듭니다.
중요

추가 소스 CR을 제공하거나 기존 소스 CR을 수정하면 OpenShift Container Platform의 성능 또는 CPU 프로필에 큰 영향을 미칠 수 있습니다.

18.10.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의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. 기존 콘텐츠의 기본 소스 CR을 검토합니다. ZTP(ZTP) 컨테이너에서 해당 CR을 추출하여 참조 PolicyGenTemplate CR에 나열된 소스 CR을 검토할 수 있습니다.

    1. /out 폴더를 생성합니다.

      $ mkdir -p ./out
    2. 소스 CR을 추출합니다.

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.14.1 extract /home/ztp --tar | tar x -C ./out
  2. ./out/source-crs/ PerformanceProfile.yaml 의 기준 PerformanceProfile CR을 검토합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: $name
      annotations:
        ran.openshift.io/ztp-deploy-wave: "10"
    spec:
      additionalKernelArgs:
      - "idle=poll"
      - "rcupdate.rcu_normal_after_boot=0"
      cpu:
        isolated: $isolated
        reserved: $reserved
      hugepages:
        defaultHugepagesSize: $defaultHugepagesSize
        pages:
          - size: $size
            count: $count
            node: $node
      machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/$mcp: ""
      net:
        userLevelNetworking: true
      nodeSelector:
        node-role.kubernetes.io/$mcp: ''
      numa:
        topologyPolicy: "restricted"
      realTimeKernel:
        enabled: true
    참고

    $…​ 이 포함된 소스 CR의 모든 필드는 PolicyGenTemplate CR에 제공되지 않는 경우 생성된 CR에서 제거됩니다.

  3. group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfilePolicyGenTemplate 항목을 업데이트합니다. 다음 예제 PolicyGenTemplate CR 스탠자는 적절한 CPU 사양을 제공하고 hugepages 구성을 설정하며 globallyDisableIrqLoadBalancing 을 false로 설정하는 새 필드를 추가합니다.

    - fileName: PerformanceProfile.yaml
      policyName: "config-policy"
      metadata:
        name: openshift-node-performance-profile
      spec:
        cpu:
          # These must be tailored for the specific hardware platform
          isolated: "2-19,22-39"
          reserved: "0-1,20-21"
        hugepages:
          defaultHugepagesSize: 1G
          pages:
            - size: 1G
              count: 10
        globallyDisableIrqLoadBalancing: false
  4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

출력 예

GitOps ZTP 애플리케이션은 생성된 PerformanceProfile CR을 포함하는 RHACM 정책을 생성합니다. 해당 CR의 내용은 PolicyGenTemplatePerformanceProfile 항목의 메타데이터사양 콘텐츠를 소스 CR에 병합하여 파생됩니다. 결과 CR에는 다음과 같은 내용이 있습니다.

---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
    name: openshift-node-performance-profile
spec:
    additionalKernelArgs:
        - idle=poll
        - rcupdate.rcu_normal_after_boot=0
    cpu:
        isolated: 2-19,22-39
        reserved: 0-1,20-21
    globallyDisableIrqLoadBalancing: false
    hugepages:
        defaultHugepagesSize: 1G
        pages:
            - count: 10
              size: 1G
    machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/master: ""
    net:
        userLevelNetworking: true
    nodeSelector:
        node-role.kubernetes.io/master: ""
    numa:
        topologyPolicy: restricted
    realTimeKernel:
        enabled: true
참고

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"

policyGen 툴은 출력 CR에서 $mcp 의 인스턴스를 worker 로 바꿉니다.

18.10.3. GitOps ZTP 파이프라인에 사용자 정의 콘텐츠 추가

다음 절차에 따라 GitOps ZTP 파이프라인에 새 콘텐츠를 추가합니다.

프로세스

  1. PolicyGenTemplate CR(사용자 정의 리소스)에 대한 kustomization.yaml 파일이 포함된 디렉터리에 source-crs 라는 하위 디렉터리를 생성합니다.
  2. 다음 예와 같이 사용자 제공 CR을 source-crs 하위 디렉터리에 추가합니다.

    example
    └── policygentemplates
        ├── dev.yaml
        ├── kustomization.yaml
        ├── mec-edge-sno1.yaml
        ├── sno.yaml
        └── source-crs 1
            ├── PaoCatalogSource.yaml
            ├── PaoSubscription.yaml
            ├── custom-crs
            |   ├── apiserver-config.yaml
            |   └── disable-nic-lldp.yaml
            └── elasticsearch
                ├── ElasticsearchNS.yaml
                └── ElasticsearchOperatorGroup.yaml
    1
    source-crs 하위 디렉터리는 kustomization.yaml 파일과 동일한 디렉터리에 있어야 합니다.
  3. source-crs/custom-crssource-crs/elasticsearch 디렉터리에 추가한 콘텐츠에 대한 참조를 포함하도록 필요한 PolicyGenTemplate CR을 업데이트합니다. 예를 들면 다음과 같습니다.

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "group-dev"
      namespace: "ztp-clusters"
    spec:
      bindingRules:
        dev: "true"
      mcp: "master"
      sourceFiles:
        # These policies/CRs come from the internal container Image
        #Cluster Logging
        - fileName: ClusterLogNS.yaml
          remediationAction: inform
          policyName: "group-dev-cluster-log-ns"
        - fileName: ClusterLogOperGroup.yaml
          remediationAction: inform
          policyName: "group-dev-cluster-log-operator-group"
        - fileName: ClusterLogSubscription.yaml
          remediationAction: inform
          policyName: "group-dev-cluster-log-sub"
        #Local Storage Operator
        - fileName: StorageNS.yaml
          remediationAction: inform
          policyName: "group-dev-lso-ns"
        - fileName: StorageOperGroup.yaml
          remediationAction: inform
          policyName: "group-dev-lso-operator-group"
        - fileName: StorageSubscription.yaml
          remediationAction: inform
          policyName: "group-dev-lso-sub"
        #These are custom local polices that come from the source-crs directory in the git repo
        # Performance Addon Operator
        - fileName: PaoSubscriptionNS.yaml
          remediationAction: inform
          policyName: "group-dev-pao-ns"
        - fileName: PaoSubscriptionCatalogSource.yaml
          remediationAction: inform
          policyName: "group-dev-pao-cat-source"
          spec:
            image: <image_URL_here>
        - fileName: PaoSubscription.yaml
          remediationAction: inform
          policyName: "group-dev-pao-sub"
        #Elasticsearch Operator
        - fileName: elasticsearch/ElasticsearchNS.yaml 1
          remediationAction: inform
          policyName: "group-dev-elasticsearch-ns"
        - fileName: elasticsearch/ElasticsearchOperatorGroup.yaml
          remediationAction: inform
          policyName: "group-dev-elasticsearch-operator-group"
        #Custom Resources
        - fileName: custom-crs/apiserver-config.yaml 2
          remediationAction: inform
          policyName: "group-dev-apiserver-config"
        - fileName: custom-crs/disable-nic-lldp.yaml
          remediationAction: inform
          policyName: "group-dev-disable-nic-lldp"
    1 2
    /source-crs 상위 디렉터리에서 파일의 상대 경로를 포함하도록 fileName 을 설정합니다.
  4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 정책 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  5. 변경된 PolicyGenTemplate 을 포함하도록 ClusterGroupUpgrade CR을 업데이트하고 cgu-test.yaml 로 저장합니다. 다음 예제는 생성된 cgu-test.yaml 파일을 보여줍니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: custom-source-cr
      namespace: ztp-clusters
    spec:
      managedPolicies:
        - group-dev-config-policy
      enable: true
      clusters:
      - cluster1
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
  6. 다음 명령을 실행하여 업데이트된 ClusterGroupUpgrade CR을 적용합니다.

    $ oc apply -f cgu-test.yaml

검증

  • 다음 명령을 실행하여 업데이트가 성공했는지 확인합니다.

    $ oc get cgu -A

    출력 예

    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

18.10.4. PolicyGenTemplate CR에 대한 정책 준수 평가 시간 초과 구성

hub 클러스터에 설치된 RHACM(Red Hat Advanced Cluster Management)을 사용하여 관리 클러스터가 적용된 정책을 준수하는지 여부를 모니터링하고 보고합니다. RHACM은 정책 템플릿을 사용하여 사전 정의된 정책 컨트롤러 및 정책을 적용합니다. 정책 컨트롤러는 Kubernetes CRD(사용자 정의 리소스 정의) 인스턴스입니다.

PolicyGenTemplate CR(사용자 정의 리소스)을 사용하여 기본 정책 평가 간격을 덮어쓸 수 있습니다. RHACM이 적용된 클러스터 정책을 다시 평가하기 전에 ConfigurationPolicy CR이 정책 준수 또는 비준수 상태에 있을 수 있는 기간을 정의하는 기간을 구성합니다.

GitOps ZTP(ZTP) 정책 생성기는 사전 정의된 정책 평가 간격을 사용하여 ConfigurationPolicy CR 정책을 생성합니다. 비준수 상태의 기본값은 10초입니다. 규정 준수 상태의 기본값은 10분입니다. 평가 간격을 비활성화하려면 값을 never 로 설정합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

프로세스

  1. PolicyGenTemplate CR의 모든 정책에 대한 평가 간격을 구성하려면 spec 필드에 evaluationInterval 를 추가한 다음 적절한 준수비준수 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
      evaluationInterval:
        compliant: 30m
        noncompliant: 20s
  2. PolicyGenTemplate CR에서 spec.sourceFiles 오브젝트의 평가 간격을 구성하려면 sourceFiles 필드에 evaluationInterval 을 추가합니다. 예를 들면 다음과 같습니다.

    spec:
      sourceFiles:
       - fileName: SriovSubscription.yaml
         policyName: "sriov-sub-policy"
         evaluationInterval:
           compliant: never
           noncompliant: 10s
  3. Git 리포지토리에서 PolicyGenTemplate CR 파일을 커밋하고 변경 사항을 내보냅니다.

검증

관리형 spoke 클러스터 정책이 예상 간격으로 모니터링되는지 확인합니다.

  1. 관리 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  2. open-cluster-management-agent-addon 네임스페이스에서 실행 중인 Pod를 가져옵니다. 다음 명령을 실행합니다.

    $ oc get pods -n open-cluster-management-agent-addon

    출력 예

    NAME                                         READY   STATUS    RESTARTS        AGE
    config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

  3. config-policy-controller Pod에 대한 로그에서 적용된 정책이 예상 간격으로 평가되고 있는지 확인합니다.

    $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

    출력 예

    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"}

18.10.5. 검증기 정보 정책을 사용하여 GitOps ZTP 클러스터 배포 완료 신호

GitOps ZTP(ZTP) 설치 및 배포된 클러스터의 구성이 완료된 경우 신호를 알리는 검증기 정보를 생성합니다. 이 정책은 단일 노드 OpenShift 클러스터, 3-노드 클러스터 및 표준 클러스터의 배포에 사용할 수 있습니다.

프로세스

  1. 소스 파일 validatorCRs/informDuValidator.yaml 을 포함하는 독립 실행형 PolicyGenTemplate CR(사용자 정의 리소스)을 생성합니다. 각 클러스터 유형에 대해 하나의 독립 실행형 PolicyGenTemplate CR만 있으면 됩니다. 예를 들어 이 CR은 단일 노드 OpenShift 클러스터에 대한 검증기 정보 정책을 적용합니다.

    single-node 클러스터 검증기 정보 정책 CR의 예 (group-du-sno-validator-ranGen.yaml)

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "group-du-sno-validator" 1
      namespace: "ztp-group" 2
    spec:
      bindingRules:
        group-du-sno: "" 3
      bindingExcludedRules:
        ztp-done: "" 4
      mcp: "master" 5
      sourceFiles:
        - fileName: validatorCRs/informDuValidator.yaml
          remediationAction: inform 6
          policyName: "du-policy" 7

    1
    PolicyGenTemplates 오브젝트의 이름입니다. 이 이름은 요청된 네임스페이스에 생성된 placementBinding,placementRule정책의 일부로 사용됩니다.
    2
    이 값은 PolicyGenTemplates 그룹에 사용된 네임스페이스 와 일치해야 합니다.
    3
    bindingRules 에 정의된 group-du-* 레이블은 site Config 파일에 있어야 합니다.
    4
    bindingExcludedRules 에 정의된 레이블은'ztp-done:'이어야 합니다. ztp-done 레이블은 토폴로지 Aware Lifecycle Manager와의 조정에 사용됩니다.
    5
    MCP 는 소스 파일 validatorCRs/informDuValidator.yaml 에 사용되는 MachineConfigPool 오브젝트를 정의합니다. 단일 노드와 3-노드 클러스터 배포의 경우 마스터 이고 표준 클러스터 배포의 경우 worker 여야 합니다.
    6
    선택 사항: 기본값은 inform 입니다.
    7
    이 값은 생성된 RHACM 정책의 이름으로 사용됩니다. 단일 노드 예에 대해 생성된 검증 검증 정책은 group-du-sno-validator-du-policy 입니다.
  2. Git 리포지토리에서 PolicyGenTemplate CR 파일을 커밋하고 변경 사항을 내보냅니다.

추가 리소스

18.10.6. PolicyGenTemplates CR을 사용하여 전원 상태 구성

대기 시간이 짧고 고성능 에지 배포를 위해 C-state 및 P-state를 비활성화하거나 제한해야 합니다. 이 구성을 사용하면 CPU가 일정한 빈도로 실행되며 일반적으로 최대 turbo 빈도입니다. 이렇게 하면 CPU가 항상 최대 속도로 실행되므로 높은 성능과 대기 시간이 단축됩니다. 이로 인해 워크로드에 대한 최적의 대기 시간이 발생합니다. 그러나 이는 또한 가장 높은 전력 소비를 초래하며, 이는 모든 워크로드에 필요하지 않을 수 있습니다.

워크로드는 높은 성능 및 낮은 대기 시간을 위해 C-state 및 P-state 설정을 비활성화해야 하는 중요한 워크로드로 분류할 수 있지만 중요하지 않은 워크로드는 C-state 및 P-state 설정을 사용하여 일부 대기 시간 및 성능을 저하시킵니다. ZTP(ZTP)를 사용하여 다음 세 가지 전원 상태를 구성할 수 있습니다.

  • 고성능 모드는 가장 높은 전력 소비에서 매우 낮은 대기 시간을 제공합니다.
  • 성능 모드는 비교적 높은 전력 소비로 짧은 대기 시간을 제공합니다.
  • 전력 절감은 대기 시간이 증가하여 전력 소비를 줄일 수 있습니다.

기본 구성은 대기 시간이 짧은 성능 모드입니다.

PolicyGenTemplate CR(사용자 정의 리소스)을 사용하면 ztp-site-generate 컨테이너의 GitOps 플러그인과 함께 제공된 기본 소스 CR에 추가 구성 세부 정보를 오버레이할 수 있습니다.

group-du-sno-ranGen.yamlPolicyGenTemplate CR을 기반으로 생성된 PerformanceProfile CR의 workloadHints 필드를 업데이트하여 전원 상태를 구성합니다.

다음과 같은 일반적인 사전 요구 사항은 세 가지 전원 상태를 모두 구성하는 데 적용됩니다.

사전 요구 사항

  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD의 소스 리포지토리로 정의해야 합니다.
  • " GitOps ZTP 사이트 구성 리포지토리 준비"에 설명된 절차를 수행했습니다.
18.10.6.1. PolicyGenTemplate CR을 사용하여 성능 모드 구성

이 예제에 따라 group-du-sno-ranGen.yamlPolicyGenTemplate CR을 기반으로 생성된 PerformanceProfile CR의 workloadHints 필드를 업데이트하여 성능 모드를 설정합니다.

성능 모드는 비교적 높은 전력 소비로 짧은 대기 시간을 제공합니다.

사전 요구 사항

  • "낮은 대기 시간과 고성능을 위해 호스트 펌웨어 구성"의 지침에 따라 성능 관련 설정으로 BIOS를 구성했습니다.

프로세스

  1. 다음과 같이 out/argocd/example/policygentemplates 에서 group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfilePolicyGenTemplate 항목을 업데이트합니다.

    - fileName: PerformanceProfile.yaml
      policyName: "config-policy"
      metadata:
        [...]
      spec:
        [...]
        workloadHints:
             realTime: true
             highPowerConsumption: false
             perPodPowerManagement: false
  2. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
18.10.6.2. PolicyGenTemplate CR을 사용하여 고성능 모드 구성

다음 예제에서는 group-du-sno-ranGen.yamlPolicyGenTemplate CR을 기반으로 생성된 PerformanceProfile CR의 workloadHints 필드를 업데이트하여 고성능 모드를 설정합니다.

고성능 모드는 가장 높은 전력 소비에서 매우 짧은 대기 시간을 제공합니다.

사전 요구 사항

  • "낮은 대기 시간과 고성능을 위해 호스트 펌웨어 구성"의 지침에 따라 성능 관련 설정으로 BIOS를 구성했습니다.

프로세스

  1. 다음과 같이 out/argocd/example/policygentemplates 에서 group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfilePolicyGenTemplate 항목을 업데이트합니다.

    - fileName: PerformanceProfile.yaml
      policyName: "config-policy"
      metadata:
        [...]
      spec:
        [...]
        workloadHints:
             realTime: true
             highPowerConsumption: true
             perPodPowerManagement: false
  2. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
18.10.6.3. PolicyGenTemplate CR을 사용하여 전원 저장 모드 구성

다음 예제에서는 group-du-sno-ranGen.yamlPolicyGenTemplate CR을 기반으로 생성된 PerformanceProfile CR의 workloadHints 필드를 업데이트하여 전원 저장 모드를 설정합니다.

절전 모드는 대기 시간이 증가하여 전력 소비를 줄입니다.

사전 요구 사항

  • BIOS에서 C-states 및 OS 제어 P-states를 활성화했습니다.

프로세스

  1. 다음과 같이 out/argocd/example/policygentemplates 에서 group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfilePolicyGenTemplate 항목을 업데이트합니다. 추가 커널 인수 오브젝트를 통해 전원 저장 모드에 대한 CPU governor를 구성하는 것이 좋습니다.

    - fileName: PerformanceProfile.yaml
      policyName: "config-policy"
      metadata:
        [...]
      spec:
        [...]
        workloadHints:
             realTime: true
             highPowerConsumption: false
             perPodPowerManagement: true
        [...]
        additionalKernelArgs:
           - [...]
           - "cpufreq.default_governor=schedutil" 1
    1
    그러나 schedutil governor를 사용하는 것이 좋습니다. 그러나 사용 가능한 다른 governor에는 온디맨드전원 세이프가 포함됩니다.
  2. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

검증

  1. 다음 명령을 사용하여 식별된 노드 목록에서 배포된 클러스터에서 작업자 노드를 선택합니다.

    $ oc get nodes
  2. 다음 명령을 사용하여 노드에 로그인합니다.

    $ oc debug node/<node-name>

    & lt;node-name >을 전원 상태를 확인할 노드의 이름으로 바꿉니다.

  3. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host 로 변경하면 다음 예와 같이 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

    # chroot /host
  4. 다음 명령을 실행하여 적용된 전원 상태를 확인합니다.

    # cat /proc/cmdline

예상 출력

  • 절전 모드의 경우 intel_pstate=passive 입니다.
18.10.6.4. 전원 비용 절감 극대화

최대 CPU 빈도를 제한하면 최대 전력 절감이 권장됩니다. 최대 CPU 빈도를 제한하지 않고 중요하지 않은 워크로드 CPU에서 C 상태를 활성화하면 중요한 CPU의 빈도를 높임으로써 전력 절감이 거의 발생하지 않습니다.

sysfs 플러그인 필드를 업데이트하여 전력 절감을 극대화하고 참조 구성에 대한 TunedPerformancePatch CR의 max_perf_pct 에 대한 적절한 값을 설정합니다. group-du-sno-ranGen.yaml 을 기반으로 하는 이 예제에서는 최대 CPU 빈도를 제한하는 절차를 설명합니다.

사전 요구 사항

  • " PolicyGenTemplate CR 사용으로 전원 절약 모드"에 설명된 대로 전원 절감 모드를 구성했습니다.

프로세스

  1. group-du-sno-ranGen.yaml 참조 파일에서 TunedPerformancePatchPolicyGenTemplate 항목을 out/argocd/example/policygentemplates 에서 업데이트합니다. 전원 절감을 극대화하려면 다음 예와 같이 max_perf_pct 를 추가합니다.

    - fileName: TunedPerformancePatch.yaml
          policyName: "config-policy"
          spec:
            profile:
              - name: performance-patch
                data: |
                  [...]
                  [sysfs]
                  /sys/devices/system/cpu/intel_pstate/max_perf_pct=<x> 1
    1
    max_perf_pctcpufreq 드라이버가 지원되는 최대 CPU 빈도의 백분율로 설정할 수 있는 최대 빈도를 제어합니다. 이 값은 모든 CPU에 적용됩니다. /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq 에서 지원되는 최대 빈도를 확인할 수 있습니다. 시작점으로 모든 CPU를 모든 코어 frequency로 제한하는 백분율로 사용할 수 있습니다. 모든 코어의 frequency는 코어가 완전히 비어 있을 때 모든 코어가 실행되는 빈도입니다.
    참고

    전력 절감을 극대화하려면 더 낮은 가치를 설정하십시오. max_perf_pct 에 대한 더 낮은 값을 설정하면 최대 CPU 빈도가 제한되므로 전력 소비가 줄어들지만 잠재적으로 성능에 영향을 미칠 수 있습니다. 다양한 값을 실험하고 시스템의 성능 및 전력 소비를 모니터링하여 사용 사례에 가장 적합한 설정을 찾습니다.

  2. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

18.10.7. PolicyGenTemplate CR을 사용하여 LVM 스토리지 구성

ZTP(ZTP)를 사용하여 배포하는 관리형 클러스터에 대해 LVM(Logical Volume Manager) 스토리지를 구성할 수 있습니다.

참고

HTTP 전송과 함께 PTP 이벤트 또는 베어 메탈 하드웨어 이벤트를 사용할 때 LVM 스토리지를 사용하여 이벤트 서브스크립션을 유지합니다.

분산 단위로 로컬 볼륨을 사용하는 영구 스토리지에 Local Storage Operator를 사용합니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다.

프로세스

  1. 새 관리 클러스터에 대해 LVM 스토리지를 구성하려면 common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가합니다.

    - fileName: StorageLVMOSubscriptionNS.yaml
      policyName: subscription-policies
    - fileName: StorageLVMOSubscriptionOperGroup.yaml
      policyName: subscription-policies
    - fileName: StorageLVMOSubscription.yaml
      spec:
        name: lvms-operator
        channel: stable-4.14
      policyName: subscription-policies
    참고

    스토리지 LVMO 서브스크립션은 더 이상 사용되지 않습니다. 향후 OpenShift Container Platform 릴리스에서는 스토리지 LVMO 서브스크립션을 사용할 수 없습니다. 대신 Storage LVMS 서브스크립션을 사용해야 합니다.

    OpenShift Container Platform 4.14에서는 LVMO 서브스크립션 대신 스토리지 LVMS 서브스크립션을 사용할 수 있습니다. LVMS 서브스크립션에는 common-ranGen.yaml 파일의 수동 덮어쓰기가 필요하지 않습니다. 스토리지 LVMS 서브스크립션을 사용하려면 common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가합니다.

    - fileName: StorageLVMSubscriptionNS.yaml
      policyName: subscription-policies
    - fileName: StorageLVMSubscriptionOperGroup.yaml
      policyName: subscription-policies
    - fileName: StorageLVMSubscription.yaml
      policyName: subscription-policies
  2. 특정 그룹 또는 개별 사이트 구성 파일의 spec.sourceFilesLVMCluster CR을 추가합니다. 예를 들어 group-du-sno-ranGen.yaml 파일에서 다음을 추가합니다.

    - fileName: StorageLVMCluster.yaml
      policyName: "lvms-config" 1
      spec:
        storage:
          deviceClasses:
          - name: vg1
            thinPoolConfig:
              name: thin-pool-1
              sizePercent: 90
              overprovisionRatio: 10
    1
    이 예제 구성은 OpenShift Container Platform이 설치된 디스크를 제외하고 사용 가능한 모든 장치가 포함된 볼륨 그룹( Cryostat1)을 생성합니다. thin-pool 논리 볼륨도 생성됩니다.
  3. 기타 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
  4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 사이트 구성 리포지토리로 변경 사항을 내보내 GitOps ZTP를 사용하여 새 사이트에 LVM 스토리지를 배포합니다.

18.10.8. 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 지원 상태를 참조하십시오.

18.10.8.1. HTTP 전송을 사용하는 PTP 이벤트 구성

ZTP(ZTP) 파이프라인으로 배포하는 관리형 클러스터에서 HTTP 전송을 사용하는 PTP 이벤트를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

프로세스

  1. 요구 사항에 따라 group-du-3node-ranGen.yaml,group-du-sno-ranGen.yaml 또는 group-du-standard-ranGen.yaml 파일에 다음 PolicyGenTemplate 변경 사항을 적용합니다.

    1. .sourceFiles 에서 전송 호스트를 구성하는 PtpOperatorConfig CR 파일을 추가합니다.

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"
        spec:
          daemonNodeSelector: {}
          ptpEventConfig:
            enableEventPublisher: true
            transportHost: http://ptp-event-publisher-service-NODE_NAME.openshift-ptp.svc.cluster.local:9043
      참고

      OpenShift Container Platform 4.13 이상에서는 PTP 이벤트와 함께 HTTP 전송을 사용할 때 PtpOperatorConfig 리소스에서 transportHost 필드를 설정할 필요가 없습니다.

    2. PTP 클럭 유형 및 인터페이스에 대해 linuxptpphc2sys 를 구성합니다. 예를 들어 다음 스탠자를 .sourceFiles 에 추가합니다.

      - fileName: PtpConfigSlave.yaml 1
        policyName: "config-policy"
        metadata:
          name: "du-ptp-slave"
        spec:
          profile:
          - name: "slave"
            interface: "ens5f1" 2
            ptp4lOpts: "-2 -s --summary_interval -4" 3
            phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
          ptpClockThreshold: 5
            holdOverTimeout: 30 #secs
            maxOffsetThreshold: 100  #nano secs
            minOffsetThreshold: -100 #nano secs
      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.profileptp4lOpts--summary_interval -4 값을 추가해야 합니다.
      4
      필수 phc2sysOpts 값. -m 은 메시지를 stdout 에 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
      5
      선택 사항: ptpClockThreshold 스탠자가 없으면 ptpClockThreshold 필드에 기본값이 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클록의 연결이 해제된 후의 시간을 구성합니다. holdOverTimeout 은 PTP 마스터 클록의 연결이 끊어지면 PTP 클럭 이벤트 상태가 Free RUN 으로 변경되기 전의 시간(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 master 오프셋(ptp4l)의 값과 비교하는 오프셋 값을 나노초로 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 Free RUN으로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.
  2. 기타 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
  3. GitOps ZTP를 사용하여 새 사이트에 PTP 빠른 이벤트를 배포하려면 사이트 구성 리포지토리로 변경 사항을 푸시합니다.
18.10.8.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 리포지토리를 생성했습니다.

프로세스

  1. common-ranGen.yaml 파일의 .spec.sourceFiles 에 다음 YAML을 추가하여 AMQP Operator를 구성합니다.

    #AMQ interconnect operator for fast events
    - fileName: AmqSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscription.yaml
      policyName: "subscriptions-policy"
  2. 요구 사항에 따라 group-du-3node-ranGen.yaml,group-du-sno-ranGen.yaml 또는 group-du-standard-ranGen.yaml 파일에 다음 PolicyGenTemplate 변경 사항을 적용합니다.

    1. .sourceFiles 에서 AMQ 전송 호스트를 config-policy 에 구성하는 PtpOperatorConfig CR 파일을 추가합니다.

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"
        spec:
          daemonNodeSelector: {}
          ptpEventConfig:
            enableEventPublisher: true
            transportHost: "amqp://amq-router.amq-router.svc.cluster.local"
    2. PTP 클럭 유형 및 인터페이스에 대해 linuxptpphc2sys 를 구성합니다. 예를 들어 다음 스탠자를 .sourceFiles 에 추가합니다.

      - fileName: PtpConfigSlave.yaml 1
        policyName: "config-policy"
        metadata:
          name: "du-ptp-slave"
        spec:
          profile:
          - name: "slave"
            interface: "ens5f1" 2
            ptp4lOpts: "-2 -s --summary_interval -4" 3
            phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
          ptpClockThreshold: 5
            holdOverTimeout: 30 #secs
            maxOffsetThreshold: 100  #nano secs
            minOffsetThreshold: -100 #nano secs
      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.profileptp4lOpts--summary_interval -4 값을 추가해야 합니다.
      4
      필수 phc2sysOpts 값. -m 은 메시지를 stdout 에 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
      5
      선택 사항: ptpClockThreshold 스탠자가 없으면 ptpClockThreshold 필드에 기본값이 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클록의 연결이 해제된 후의 시간을 구성합니다. holdOverTimeout 은 PTP 마스터 클록의 연결이 끊어지면 PTP 클럭 이벤트 상태가 Free RUN 으로 변경되기 전의 시간(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 master 오프셋(ptp4l)의 값과 비교하는 오프셋 값을 나노초로 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 Free RUN으로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.
  3. 특정 사이트 YAML 파일에 다음 PolicyGenTemplate 변경 사항을 적용합니다(예: example-sno-site.yaml ).

    1. .sourceFiles 에서 AMQ 라우터를 config-policy 에 구성하는 Interconnect CR 파일을 추가합니다.

      - fileName: AmqInstance.yaml
        policyName: "config-policy"
  4. 기타 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
  5. GitOps ZTP를 사용하여 새 사이트에 PTP 빠른 이벤트를 배포하려면 사이트 구성 리포지토리로 변경 사항을 푸시합니다.

추가 리소스

18.10.9. 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 지원 상태를 참조하십시오.

18.10.9.1. HTTP 전송을 사용하는 베어 메탈 이벤트 구성

ZTP(ZTP) 파이프라인으로 배포하는 관리형 클러스터에서 HTTP 전송을 사용하는 베어 메탈 이벤트를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

프로세스

  1. common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가하여 Bare Metal Event Relay Operator를 구성합니다.

    # Bare Metal Event Relay operator
    - fileName: BareMetalEventRelaySubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: BareMetalEventRelaySubscription.yaml
      policyName: "subscriptions-policy"
  2. 특정 그룹 구성 파일의 spec.sourceFilesHardwareEvent CR을 추가합니다(예: group-du-sno-ranGen.yaml 파일).

    - fileName: HardwareEvent.yaml 1
      policyName: "config-policy"
      spec:
        nodeSelector: {}
        transportHost: "http://hw-event-publisher-service.openshift-bare-metal-events.svc.cluster.local:9043"
        logLevel: "info"
    1
    각 BMC(Baseboard Management Controller)에는 단일 HardwareEvent CR만 필요합니다.
    참고

    OpenShift Container Platform 4.13 이상에서는 베어 메탈 이벤트와 함께 HTTP 전송을 사용할 때 HardwareEvent CR(사용자 정의 리소스)에서 transportHost 필드를 설정할 필요가 없습니다.

  3. 기타 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
  4. 변경 사항을 사이트 구성 리포지토리로 내보내 GitOps ZTP가 있는 새 사이트에 베어 메탈 이벤트를 배포합니다.
  5. 다음 명령을 실행하여 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>"
18.10.9.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 리포지토리를 생성했습니다.

프로세스

  1. AMQ Interconnect Operator 및 Bare Metal Event Relay Operator를 구성하려면 common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가합니다.

    # AMQ interconnect operator for fast events
    - fileName: AmqSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscription.yaml
      policyName: "subscriptions-policy"
    # Bare Metal Event Rely operator
    - fileName: BareMetalEventRelaySubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: BareMetalEventRelaySubscription.yaml
      policyName: "subscriptions-policy"
  2. 사이트 구성 파일의 .spec.sourceFilesInterconnect CR을 추가합니다(예: example-sno-site.yaml 파일).

    - fileName: AmqInstance.yaml
      policyName: "config-policy"
  3. 특정 그룹 구성 파일의 spec.sourceFilesHardwareEvent CR을 추가합니다(예: group-du-sno-ranGen.yaml 파일).

    - fileName: HardwareEvent.yaml
      policyName: "config-policy"
      spec:
        nodeSelector: {}
        transportHost: "amqp://<amq_interconnect_name>.<amq_interconnect_namespace>.svc.cluster.local" 1
        logLevel: "info"
    1
    transportHost URL은 기존 AMQ Interconnect CR 이름과 네임스페이스 로 구성됩니다. 예를 들어 transportHost: "amqp://amq-router.amq-router.svc.cluster.local" 에서 AMQ 상호 연결 이름과 네임스페이스 는 모두 amq-router 로 설정됩니다.
    참고

    각 BMC(Baseboard Management Controller)에는 단일 HardwareEvent 리소스만 필요합니다.

  4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 사이트 구성 리포지토리로 변경 사항을 푸시하여 GitOps ZTP를 사용하여 베어 메탈 이벤트 모니터링을 새 사이트에 배포합니다.
  5. 다음 명령을 실행하여 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>"

18.10.10. 이미지 로컬 캐싱을 위해 Image Registry Operator 구성

OpenShift Container Platform은 로컬 레지스트리를 사용하여 이미지 캐싱을 관리합니다. 에지 컴퓨팅 사용 사례에서 클러스터는 중앙 집중식 이미지 레지스트리와 통신할 때 대역폭 제한의 영향을 받는 경우가 많기 때문에 이미지 다운로드 시간이 길어질 수 있습니다.

초기 배포 중에 다운로드 시간이 오래 걸릴 수 없습니다. 시간이 지남에 따라 CRI-O에서 예기치 않은 종료의 경우 /var/lib/containers/storage 디렉터리를 지울 위험이 있습니다. 긴 이미지 다운로드 시간을 해결하기 위해ZTP( GitOps Zero Touch Provisioning)를 사용하여 원격 관리 클러스터에 로컬 이미지 레지스트리를 생성할 수 있습니다. 이는 클러스터가 네트워크의 맨 에지에 배포되는 에지 컴퓨팅 시나리오에서 유용합니다.

GitOps ZTP를 사용하여 로컬 이미지 레지스트리를 설정하려면 원격 관리 클러스터를 설치하는 데 사용하는 SiteConfig CR에서 디스크 파티션을 구성해야 합니다. 설치 후 PolicyGenTemplate CR을 사용하여 로컬 이미지 레지스트리를 구성합니다. 그런 다음 GitOps ZTP 파이프라인은 PV(영구 볼륨) 및 PVC(영구 볼륨 클레임) CR을 생성하고 imageregistry 구성을 패치합니다.

참고

로컬 이미지 레지스트리는 사용자 애플리케이션 이미지에만 사용할 수 있으며 OpenShift Container Platform 또는 Operator Lifecycle Manager Operator 이미지에는 사용할 수 없습니다.

18.10.10.1. siteConfig를 사용하여 디스크 파티션 구성

SiteConfig CR 및 GitOps ZTP(ZTP)를 사용하여 관리 클러스터에 대한 디스크 파티션을 구성합니다. SiteConfig CR의 디스크 파티션 세부 정보는 기본 디스크와 일치해야 합니다.

중요

설치 시 이 절차를 완료해야 합니다.

사전 요구 사항

  • Butane을 설치합니다.

프로세스

  1. 다음 예제 YAML 파일을 사용하여 storage.bu 파일을 생성합니다.

    variant: fcos
    version: 1.3.0
    storage:
      disks:
      - device: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0 1
        wipe_table: false
        partitions:
        - label: var-lib-containers
          start_mib: <start_of_partition> 2
          size_mib: <partition_size> 3
      filesystems:
        - path: /var/lib/containers
          device: /dev/disk/by-partlabel/var-lib-containers
          format: xfs
          wipe_filesystem: true
          with_mount_unit: true
          mount_options:
            - defaults
            - prjquota
    1
    root 디스크를 지정합니다.
    2
    MiB로 파티션의 시작을 지정합니다. 값이 너무 작으면 설치에 실패합니다.
    3
    파티션의 크기를 지정합니다. 값이 너무 작으면 배포에 실패합니다.
  2. 다음 명령을 실행하여 storage.bu 를 Ignition 파일로 변환합니다.

    $ butane storage.bu

    출력 예

    {"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"}]}}

  3. JSON Pretty Print 와 같은 도구를 사용하여 출력을 JSON 형식으로 변환합니다.
  4. 출력을 SiteConfig CR의 .spec.clusters.nodes.ignitionConfigOverride 필드에 복사합니다.

    예제

    [...]
    spec:
      clusters:
        - nodes:
            - ignitionConfigOverride: |
              {
                "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"
                    }
                  ]
                }
              }
    [...]

    참고

    .spec.clusters.nodes.ignitionConfigOverride 필드가 없는 경우 생성합니다.

검증

  1. 설치 중 또는 설치 후 hub 클러스터에서 BareMetalHost 오브젝트가 다음 명령을 실행하여 주석을 표시하는지 확인합니다.

    $ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]

    출력 예

    "{\"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\"}]}}"

  2. 설치 후 단일 노드 OpenShift 디스크 상태를 확인합니다.

    1. 다음 명령을 실행하여 단일 노드 OpenShift 노드에서 디버그 세션에 들어갑니다.

      이 단계는 <node_name>-debug라는 디버그 Pod를 인스턴스화합니다.

      $ oc debug node/my-sno-node
      1. 다음 명령을 실행하여 디버그 쉘 내에서 /host 를 root 디렉터리로 설정합니다.

        디버그 Pod는 Pod 내의 /host에 호스트의 루트 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트의 실행 경로에 포함된 바이너리를 실행할 수 있습니다.

        # chroot /host
      2. 다음 명령을 실행하여 사용 가능한 모든 블록 장치에 대한 정보를 나열합니다.

        # lsblk

        출력 예

        NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
        sda      8:0    0 446.6G  0 disk
        ├─sda1   8:1    0     1M  0 part
        ├─sda2   8:2    0   127M  0 part
        ├─sda3   8:3    0   384M  0 part /boot
        ├─sda4   8:4    0 243.6G  0 part /var
        │                                /sysroot/ostree/deploy/rhcos/var
        │                                /usr
        │                                /etc
        │                                /
        │                                /sysroot
        └─sda5   8:5    0 202.5G  0 part /var/lib/containers

      3. 다음 명령을 실행하여 파일 시스템 디스크 공간 사용량에 대한 정보를 표시합니다.

        # df -h

        출력 예

        Filesystem      Size  Used Avail Use% Mounted on
        devtmpfs        4.0M     0  4.0M   0% /dev
        tmpfs           126G   84K  126G   1% /dev/shm
        tmpfs            51G   93M   51G   1% /run
        /dev/sda4       244G  5.2G  239G   3% /sysroot
        tmpfs           126G  4.0K  126G   1% /tmp
        /dev/sda5       203G  119G   85G  59% /var/lib/containers
        /dev/sda3       350M  110M  218M  34% /boot
        tmpfs            26G     0   26G   0% /run/user/1000

18.10.10.2. PolicyGenTemplate CR을 사용하여 이미지 레지스트리 구성

PGT( PolicyGenTemplate ) CR을 사용하여 이미지 레지스트리를 구성하고 imageregistry 구성을 패치하는 데 필요한 CR을 적용합니다.

사전 요구 사항

  • 관리 클러스터에 디스크 파티션을 구성했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • GitOps ZTP(ZTP)와 함께 사용할 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

프로세스

  1. 적절한 PolicyGenTemplate CR에서 스토리지 클래스, 영구 볼륨 클레임, 영구 볼륨 및 이미지 레지스트리 구성을 구성합니다. 예를 들어 개별 사이트를 구성하려면 example-sno-site.yaml 파일에 다음 YAML을 추가합니다.

    sourceFiles:
      # storage class
      - fileName: StorageClass.yaml
        policyName: "sc-for-image-registry"
        metadata:
          name: image-registry-sc
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100" 1
      # persistent volume claim
      - fileName: StoragePVC.yaml
        policyName: "pvc-for-image-registry"
        metadata:
          name: image-registry-pvc
          namespace: openshift-image-registry
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
        spec:
          accessModes:
            - ReadWriteMany
          resources:
            requests:
              storage: 100Gi
          storageClassName: image-registry-sc
          volumeMode: Filesystem
      # persistent volume
      - fileName: ImageRegistryPV.yaml 2
        policyName: "pv-for-image-registry"
        metadata:
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
      - fileName: ImageRegistryConfig.yaml
        policyName: "config-for-image-registry"
        complianceType: musthave
        metadata:
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
        spec:
          storage:
            pvc:
              claim: "image-registry-pvc"
    1
    사이트, 일반 또는 그룹 수준에서 이미지 레지스트리를 구성하는지 여부에 따라 ztp-deploy- ECDSA에 대한 적절한 값을 설정합니다. ztp-deploy-ECDHE: "100" 은 참조된 소스 파일을 함께 그룹화할 수 있으므로 개발 또는 테스트에 적합합니다.
    2
    ImageRegistryPV.yaml 에서는 SiteConfig CR의 mount_point 필드에 설정된 값과 일치하도록 spec.local.path 필드가 /var/imageregistry 로 설정되어 있는지 확인합니다.
    중요

    complianceType: mustonlyhave for the - fileName: ImageRegistryConfig.yaml 설정을 설정하지 마십시오. 이로 인해 레지스트리 Pod 배포가 실패할 수 있습니다.

  2. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

검증

다음 단계를 사용하여 관리 클러스터의 로컬 이미지 레지스트리의 오류를 해결합니다.

  • 관리 클러스터에 로그인하는 동안 레지스트리에 성공적으로 로그인했는지 확인합니다. 다음 명령을 실행합니다.

    1. 관리 클러스터 이름을 내보냅니다.

      $ cluster=<managed_cluster_name>
    2. 관리 클러스터 kubeconfig 세부 정보를 가져옵니다.

      $ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
    3. 클러스터 kubeconfig 를 다운로드하여 내보냅니다.

      $ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
    4. 관리 클러스터에서 이미지 레지스트리에 대한 액세스를 확인합니다. " registry 액세스"를 참조하십시오.
  • imageregistry.operator.openshift.io 그룹 인스턴스의 Config CRD가 오류를 보고하지 않는지 확인합니다. 관리 클러스터에 로그인하는 동안 다음 명령을 실행합니다.

    $ oc get image.config.openshift.io cluster -o yaml

    출력 예

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        include.release.openshift.io/ibm-cloud-managed: "true"
        include.release.openshift.io/self-managed-high-availability: "true"
        include.release.openshift.io/single-node-developer: "true"
        release.openshift.io/create-only: "true"
      creationTimestamp: "2021-10-08T19:02:39Z"
      generation: 5
      name: cluster
      resourceVersion: "688678648"
      uid: 0406521b-39c0-4cda-ba75-873697da75a4
    spec:
      additionalTrustedCA:
        name: acm-ice

  • 관리 클러스터의 PersistentVolumeClaim 이 데이터로 채워져 있는지 확인합니다. 관리 클러스터에 로그인하는 동안 다음 명령을 실행합니다.

    $ oc get pv image-registry-sc
  • registry* 포드가 실행 중이고 openshift-image-registry 네임스페이스에 있는지 확인합니다.

    $ oc get pods -n openshift-image-registry | grep registry*

    출력 예

    cluster-image-registry-operator-68f5c9c589-42cfg   1/1     Running     0          8d
    image-registry-5f8987879-6nx6h                     1/1     Running     0          8d

  • 관리 클러스터의 디스크 파티션이 올바른지 확인합니다.

    1. 관리 클러스터에 대한 디버그 쉘을 엽니다.

      $ oc debug node/sno-1.example.com
    2. lsblk 를 실행하여 호스트 디스크 파티션을 확인합니다.

      sh-4.4# lsblk
      NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
      sda      8:0    0 446.6G  0 disk
        |-sda1   8:1    0     1M  0 part
        |-sda2   8:2    0   127M  0 part
        |-sda3   8:3    0   384M  0 part /boot
        |-sda4   8:4    0 336.3G  0 part /sysroot
        `-sda5   8:5    0 100.1G  0 part /var/imageregistry 1
      sdb      8:16   0 446.6G  0 disk
      sr0     11:0    1   104M  0 rom
      1
      /var/imageregistry 는 디스크가 올바르게 분할되었음을 나타냅니다.

추가 리소스

18.10.11. PolicyGenTemplate CR에서 허브 템플릿 사용

토폴로지 Aware Lifecycle Manager는 GitOps ZTP(ZTP)와 함께 사용되는 구성 정책에서 partial Red Hat Advanced Cluster Management(RHACM) 허브 클러스터 템플릿 기능을 지원합니다.

Hub-side 클러스터 템플릿을 사용하면 대상 클러스터에 동적으로 사용자 지정할 수 있는 구성 정책을 정의할 수 있습니다. 이렇게 하면 similiar 구성이 있지만 값이 다른 많은 클러스터에 대해 별도의 정책을 만들 필요가 줄어듭니다.

중요

정책 템플릿은 정책이 정의된 네임스페이스와 동일한 네임스페이스로 제한됩니다. 즉, 정책이 생성되는 동일한 네임스페이스의 hub 템플릿에서 참조되는 오브젝트를 생성해야 합니다.

다음과 같은 지원되는 허브 템플릿 함수는 TALM을 사용하여 GitOps ZTP에서 사용할 수 있습니다.

  • fromConfigmap 은 이름이 지정된 ConfigMap 리소스에 제공된 데이터 키 값을 반환합니다.

    참고

    ConfigMap CR에는 1MiB 크기 제한이 있습니다. ConfigMap CR의 유효 크기는 last-applied-configuration 주석으로 추가로 제한됩니다. last-applied-configuration 제한을 방지하려면 템플릿 ConfigMap 에 다음 주석을 추가합니다.

    argocd.argoproj.io/sync-options: Replace=true
  • base64enc 는 입력 문자열의 base64 인코딩 값을 반환합니다.
  • base64dec 은 base64로 인코딩된 입력 문자열의 디코딩된 값을 반환합니다.
  • 들여쓰기 는 추가된 들여쓰기 공백을 사용하여 입력 문자열을 반환합니다.
  • autoindent 는 상위 템플릿에 사용된 간격에 따라 추가 들여쓰기가 포함된 입력 문자열을 반환합니다.
  • ToInt 입력 값의 정수 값을 캐스팅하고 반환합니다.
  • toBool 입력 문자열을 부울 값으로 변환하고 부울을 반환합니다.

GitOps ZTP에서 다양한 오픈 소스 커뮤니티 기능 도 사용할 수 있습니다.

18.10.11.1. hub 템플릿 예

다음 코드 예제는 유효한 허브 템플릿입니다. 이러한 각 템플릿은 기본 네임스페이스에 test-config 라는 이름으로 ConfigMap CR의 값을 반환합니다.

  • common-key 키를 사용하여 값을 반환합니다.

    {{hub fromConfigMap "default" "test-config" "common-key" hub}}
  • .ManagedClusterName 필드의 연결된 값과 -name 문자열을 사용하여 문자열을 반환합니다.

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}
  • .ManagedClusterName 필드의 연결된 값 및 문자열 -name:에서 부울 값을 캐스팅하고 반환합니다.

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}
  • .ManagedClusterName 필드의 연결된 값 및 문자열 -name:에서 정수 값을 캐스팅하고 반환합니다.

    {{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}
18.10.11.2. 허브 클러스터 템플릿을 사용하여 사이트 PolicyGenTemplate CR에 호스트 NIC 지정

단일 ConfigMap CR에서 호스트 NIC를 관리하고 hub 클러스터 템플릿을 사용하여 클러스터 호스트에 적용되는 생성된 정책에서 사용자 정의 NIC 값을 채울 수 있습니다. 사이트 PolicyGenTemplate (PGT) CR에서 허브 클러스터 템플릿을 사용하면 각 사이트에 대해 여러 개의 단일 사이트 PGT CR을 생성할 필요가 없습니다.

다음 예제에서는 단일 ConfigMap CR을 사용하여 클러스터 호스트 NIC를 관리하고 단일 PolicyGenTemplate 사이트 CR을 사용하여 클러스터에 정책을 적용하는 방법을 보여줍니다.

참고

fromConfigmap 함수를 사용하면 템플릿 리소스 데이터 키 필드에만 Cryostat 변수를 사용할 수 있습니다. namenamespace 필드에는 사용할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 GitOps ZTP ArgoCD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. 호스트 그룹의 NIC를 설명하는 ConfigMap 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: sriovdata
      namespace: ztp-site
      annotations:
        argocd.argoproj.io/sync-options: Replace=true 1
    data:
      example-sno-du_fh-numVfs: "8"
      example-sno-du_fh-pf: ens1f0
      example-sno-du_fh-priority: "10"
      example-sno-du_fh-vlan: "140"
      example-sno-du_mh-numVfs: "8"
      example-sno-du_mh-pf: ens3f0
      example-sno-du_mh-priority: "10"
      example-sno-du_mh-vlan: "150"
    1
    ConfigMap 이 크기가 1MiB를 초과하는 경우에만 argocd.argoproj.io/sync-options 주석이 필요합니다.
    참고

    ConfigMap 은 허브 템플릿 대체가 있는 정책과 동일한 네임스페이스에 있어야 합니다.

  2. Git에서 ConfigMap CR을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  3. 템플릿을 사용하여 ConfigMap 오브젝트에서 필요한 데이터를 가져오는 사이트 PGT CR을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "site"
      namespace: "ztp-site"
    spec:
      remediationAction: inform
      bindingRules:
        group-du-sno: ""
      mcp: "master"
      sourceFiles:
        - fileName: SriovNetwork.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nw-du-fh"
          spec:
            resourceName: du_fh
            vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-vlan" .ManagedClusterName) | toInt hub}}'
        - fileName: SriovNetworkNodePolicy.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nnp-du-fh"
          spec:
            deviceType: netdevice
            isRdma: true
            nicSelector:
              pfNames:
              - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-pf" .ManagedClusterName) | autoindent hub}}'
            numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-numVfs" .ManagedClusterName) | toInt hub}}'
            priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-priority" .ManagedClusterName) | toInt hub}}'
            resourceName: du_fh
        - fileName: SriovNetwork.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nw-du-mh"
          spec:
            resourceName: du_mh
            vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-vlan" .ManagedClusterName) | toInt hub}}'
        - fileName: SriovNetworkNodePolicy.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nnp-du-mh"
          spec:
            deviceType: vfio-pci
            isRdma: false
            nicSelector:
              pfNames:
              - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-pf" .ManagedClusterName)  hub}}'
            numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-numVfs" .ManagedClusterName) | toInt hub}}'
            priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-priority" .ManagedClusterName) | toInt hub}}'
            resourceName: du_mh
  4. Git에서 사이트 PolicyGenTemplate CR을 커밋하고 ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

    참고

    참조된 ConfigMap CR에 대한 후속 변경 사항은 적용된 정책과 자동으로 동기화되지 않습니다. 새 ConfigMap 변경 사항을 수동으로 동기화하여 기존 PolicyGenTemplate CR을 업데이트해야 합니다. "기존 PolicyGenTemplate CR에 새 ConfigMap 변경 동기화"를 참조하십시오.

18.10.11.3. hub 클러스터 템플릿을 사용하여 그룹 PolicyGenTemplate CR에서 VLAN ID 지정

단일 ConfigMap CR에서 관리 클러스터의 VLAN ID를 관리하고 hub 클러스터 템플릿을 사용하여 클러스터에 적용되는 생성된 정책의 VLAN ID를 채울 수 있습니다.

다음 예제에서는 단일 ConfigMap CR에서 VLAN ID를 관리하고 단일 PolicyGenTemplate 그룹 CR을 사용하여 개별 클러스터 정책에 적용하는 방법을 보여줍니다.

참고

fromConfigmap 함수를 사용하는 경우 Cryo stat 변수는 템플릿 리소스 데이터 키 필드에만 사용할 수 있습니다. namenamespace 필드에는 사용할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

프로세스

  1. 클러스터 호스트 그룹의 VLAN ID를 설명하는 ConfigMap CR을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: site-data
      namespace: ztp-group
      annotations:
        argocd.argoproj.io/sync-options: Replace=true 1
    data:
      site-1-vlan: "101"
      site-2-vlan: "234"
    1
    ConfigMap 이 크기가 1MiB를 초과하는 경우에만 argocd.argoproj.io/sync-options 주석이 필요합니다.
    참고

    ConfigMap 은 허브 템플릿 대체가 있는 정책과 동일한 네임스페이스에 있어야 합니다.

  2. Git에서 ConfigMap CR을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  3. hub 템플릿을 사용하여 ConfigMap 오브젝트에서 필요한 VLAN ID를 가져오는 그룹 PGT CR을 생성합니다. 예를 들어 다음 YAML 스니펫을 PGT CR 그룹에 추가합니다.

    - fileName: SriovNetwork.yaml
        policyName: "config-policy"
        metadata:
          name: "sriov-nw-du-mh"
          annotations:
            ran.openshift.io/ztp-deploy-wave: "10"
        spec:
          resourceName: du_mh
          vlan: '{{hub fromConfigMap "" "site-data" (printf "%s-vlan" .ManagedClusterName) | toInt hub}}'
  4. Git에서 PolicyGenTemplate CR 그룹을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

    참고

    참조된 ConfigMap CR에 대한 후속 변경 사항은 적용된 정책과 자동으로 동기화되지 않습니다. 새 ConfigMap 변경 사항을 수동으로 동기화하여 기존 PolicyGenTemplate CR을 업데이트해야 합니다. "기존 PolicyGenTemplate CR에 새 ConfigMap 변경 동기화"를 참조하십시오.

18.10.11.4. 기존 PolicyGenTemplate CR에 새 ConfigMap 변경 사항 동기화

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • hub 클러스터 템플릿을 사용하여 ConfigMap CR에서 정보를 가져오는 PolicyGenTemplate CR을 생성했습니다.

프로세스

  1. ConfigMap CR의 콘텐츠를 업데이트하고 hub 클러스터의 변경 사항을 적용합니다.
  2. 업데이트된 ConfigMap CR의 콘텐츠를 배포된 정책에 동기화하려면 다음 중 하나를 수행하십시오.

    1. 옵션 1: 기존 정책을 삭제합니다. rgocd는 PolicyGenTemplate CR을 사용하여 삭제된 정책을 즉시 다시 생성합니다. 예를 들어 다음 명령을 실행합니다.

      $ oc delete policy <policy_name> -n <policy_namespace>
    2. 옵션 2: ConfigMap 을 업데이트할 때마다 다른 값을 사용하여 정책에 특수 주석 정책.open-cluster-management.io/trigger-update 를 적용합니다. 예를 들면 다음과 같습니다.

      $ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
      참고

      변경 사항을 적용하려면 업데이트된 정책을 적용해야 합니다. 자세한 내용은 재처리를 위한 특수 주석을 참조하십시오.

  3. 선택 사항: 존재하는 경우 정책이 포함된 ClusterGroupUpdate CR을 삭제합니다. 예를 들면 다음과 같습니다.

    $ oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
    1. 업데이트된 ConfigMap 변경 사항에 적용할 정책이 포함된 새 ClusterGroupUpdate CR을 생성합니다. 예를 들어 cgr-example.yaml 파일에 다음 YAML을 추가합니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: <cgr_name>
        namespace: <policy_namespace>
      spec:
        managedPolicies:
          - <managed_policy>
        enable: true
        clusters:
        - <managed_cluster_1>
        - <managed_cluster_2>
        remediationStrategy:
          maxConcurrency: 2
          timeout: 240
    2. 업데이트된 정책을 적용합니다.

      $ oc apply -f cgr-example.yaml

18.11. 토폴로지 Aware Lifecycle Manager를 사용하여 관리형 클러스터 업데이트

Topology Aware Lifecycle Manager(TALM)를 사용하여 여러 클러스터의 소프트웨어 라이프사이클을 관리할 수 있습니다. TALM은 RHACM(Red Hat Advanced Cluster Management) 정책을 사용하여 대상 클러스터에서 변경 사항을 수행합니다.

18.11.1. 토폴로지 Aware Lifecycle Manager 구성 정보

Topology Aware Lifecycle Manager(TALM)는 하나 이상의 OpenShift Container Platform 클러스터에 대한 RHACM(Red Hat Advanced Cluster Management) 정책 배포를 관리합니다. 대규모 클러스터 네트워크에서 TALM을 사용하면 제한된 배치로 클러스터에 정책을 단계적으로 롤아웃할 수 있습니다. 이를 통해 업데이트 시 가능한 서비스 중단을 최소화할 수 있습니다. TALM을 사용하면 다음 작업을 제어할 수 있습니다.

  • 업데이트의 타이밍
  • RHACM 관리 클러스터 수
  • 정책을 적용할 관리 클러스터의 하위 세트
  • 클러스터의 업데이트 순서
  • 클러스터에 적용되는 정책 세트
  • 클러스터에 대한 정책 업데이트 순서
  • 카나리아 클러스터 할당

단일 노드 OpenShift의 경우 Topology Aware Lifecycle Manager(TALM)는 다음과 같은 기능을 제공합니다.

  • 업그레이드하기 전에 배포 백업 생성
  • 대역폭이 제한된 클러스터의 이미지 사전 캐싱

TALM은 OpenShift Container Platform y-stream 및 z-stream 업데이트의 오케스트레이션과 y-stream 및 z-streams에 대한 Day-two 작업을 지원합니다.

18.11.2. 토폴로지 Aware Lifecycle Manager와 함께 사용되는 관리형 정책 정보

TALM( Topology Aware Lifecycle Manager)은 클러스터 업데이트에 RHACM 정책을 사용합니다.

TALM을 사용하여 remediationAction 필드가 알리는 모든 정책 CR의 롤아웃을 관리할 수 있습니다. 지원되는 사용 사례는 다음과 같습니다.

  • 정책 CR 수동 사용자 생성
  • PolicyGenTemplate CRD(사용자 정의 리소스 정의)에서 자동으로 생성된 정책

Operator 서브스크립션을 수동 승인으로 업데이트하는 정책의 경우 TALM은 업데이트된 Operator 설치를 승인하는 추가 기능을 제공합니다.

관리 정책에 대한 자세한 내용은 RHACM 설명서의 정책 개요 를 참조하십시오.

PolicyGenTemplate CRD에 대한 자세한 내용은 "policy 및 PolicyGenTemplate 리소스를 사용하여 관리 클러스터 구성"의 " PolicyGenTemplate CRD 설명" 섹션을 참조하십시오.

18.11.3. 웹 콘솔을 사용하여 토폴로지 Aware Lifecycle Manager 설치

OpenShift Container Platform 웹 콘솔을 사용하여 토폴로지 Aware Lifecycle Manager를 설치할 수 있습니다.

사전 요구 사항

  • 최신 버전의 RHACM Operator를 설치합니다.
  • 연결이 끊긴 regitry를 사용하여 허브 클러스터를 설정합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub로 이동합니다.
  2. 사용 가능한 Operator 목록에서 토폴로지 Aware Lifecycle Manager 를 검색한 다음 설치를 클릭합니다.
  3. 기본 설치 모드 ["기본"] 및 설치된 네임스페이스("openshift-operators")를 계속 선택하여 Operator가 올바르게 설치되었는지 확인합니다.
  4. 설치를 클릭합니다.

검증

설치에 성공했는지 확인하려면 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. Operator가 모든 네임스페이스 네임스페이스에 설치되어 있고 해당 상태가 Succeeded 인지 확인합니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
  2. 워크로드Pod 페이지로 이동하여 문제를 보고하는 cluster-group-upgrades-controller-manager Pod에서 컨테이너의 로그를 확인합니다.

18.11.4. CLI를 사용하여 토폴로지 인식 라이프사이클 관리자 설치

OpenShift CLI(oc)를 사용하여 Topology Aware Lifecycle Manager(TALM)를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • 최신 버전의 RHACM Operator를 설치합니다.
  • 연결이 끊긴 레지스트리를 사용하여 허브 클러스터를 설정합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 서브스크립션 CR을 생성합니다.

    1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: talm-subscription.yaml ):

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다.

      $ oc create -f talm-subscription.yaml

검증

  1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

    $ oc get csv -n openshift-operators

    출력 예

    NAME                                                   DISPLAY                            VERSION               REPLACES                           PHASE
    topology-aware-lifecycle-manager.4.14.x   Topology Aware Lifecycle Manager   4.14.x                                      Succeeded

  2. TALM이 실행 중인지 확인합니다.

    $ oc get deploy -n openshift-operators

    출력 예

    NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
    openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s

18.11.5. ClusterGroupUpgrade CR 정보

Topology Aware Lifecycle Manager(TALM)는 클러스터 그룹의 ClusterGroupUpgrade CR에서 수정 계획을 빌드합니다. ClusterGroupUpgrade CR에서 다음 사양을 정의할 수 있습니다.

  • 그룹의 클러스터
  • ClusterGroupUpgrade CR 차단
  • 적용 가능한 관리 정책 목록
  • 동시 업데이트 수
  • 적용 가능한 카나리아 업데이트
  • 업데이트 전후에 수행할 작업
  • 업데이트 타이밍

ClusterGroupUpgrade CR의 enable 필드를 사용하여 업데이트 시작 시간을 제어할 수 있습니다. 예를 들어 스케줄링된 유지 관리 기간이 4시간인 경우 enable 필드가 false 로 설정된 ClusterGroupUpgrade CR을 준비할 수 있습니다.

spec.remediationStrategy.timeout 설정을 다음과 같이 구성하여 시간 제한을 설정할 수 있습니다.

spec
  remediationStrategy:
          maxConcurrency: 1
          timeout: 240

batchTimeoutAction 을 사용하여 클러스터에 대한 업데이트가 실패하면 어떤 일이 발생하는지 확인할 수 있습니다. 실패한 클러스터를 계속 건너뛰고 다른 클러스터를 계속 업그레이드하거나 모든 클러스터의 정책 수정을 중지하도록 중단할 수 있습니다. 시간 초과가 경과하면 TALM은 모든 적용 정책을 제거하여 클러스터에 대한 추가 업데이트가 없는지 확인합니다.

변경 사항을 적용하려면 enabled 필드를 true 로 설정합니다.

자세한 내용은 "관리된 클러스터에 업데이트 정책 적용" 섹션을 참조하십시오.

TALM은 지정된 클러스터에 대한 정책 수정을 통해 작동하므로 ClusterGroupUpgrade CR은 여러 조건에 대해 true 또는 false 상태를 보고할 수 있습니다.

참고

TALM이 클러스터 업데이트를 완료한 후 동일한 ClusterGroupUpgrade CR 제어 하에서 클러스터가 다시 업데이트되지 않습니다. 다음과 같은 경우 새 ClusterGroupUpgrade CR을 생성해야 합니다.

  • 클러스터를 다시 업데이트해야 하는 경우
  • 클러스터가 업데이트 후 알림 정책과 호환되지 않는 경우
18.11.5.1. 클러스터 선택

TALM은 수정 계획을 빌드하고 다음 필드를 기반으로 클러스터를 선택합니다.

  • clusterLabelSelector 필드는 업데이트할 클러스터의 레이블을 지정합니다. k8s.io/apimachinery/pkg/apis/meta/v1 의 표준 라벨 선택기 목록으로 구성됩니다. 목록의 각 선택기는 레이블 값 쌍 또는 레이블 표현식을 사용합니다. 각 선택기의 일치 항목은 clusterSelector 필드 및 cluster 필드의 일치 항목과 함께 최종 클러스터 목록에 추가됩니다.
  • cluster 필드는 업데이트할 클러스터 목록을 지정합니다.
  • canaries 필드는 카나리아 업데이트를 위한 클러스터를 지정합니다.
  • maxConcurrency 필드는 배치에서 업데이트할 클러스터 수를 지정합니다.
  • actions 필드는 TALM이 업데이트 프로세스를 시작할 때 TALM이 수행하는 작업 및 각 클러스터에 대한 정책 수정을 완료할 때 TALM이 수행하는 afterCompletion 작업을 지정합니다.

클러스터 , cluster LabelSelectorclusterSelector 필드를 함께 사용하여 결합된 클러스터 목록을 생성할 수 있습니다.

수정 계획은 canaries 필드에 나열된 클러스터로 시작합니다. 각 카나리아 클러스터는 단일 클러스터 배치를 형성합니다.

enabled 필드false로 설정된 샘플 ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
Spec:
  actions:
    afterCompletion: 1
      addClusterLabels:
        upgrade-done: ""
      deleteClusterLabels:
        upgrade-running: ""
      deleteObjects: true
    beforeEnable: 2
      addClusterLabels:
        upgrade-running: ""
  backup: false
  clusters: 3
    - spoke1
  enable: false 4
  managedPolicies: 5
    - talm-policy
  preCaching: false
  remediationStrategy: 6
    canaries: 7
        - spoke1
    maxConcurrency: 2 8
    timeout: 240
  clusterLabelSelectors: 9
    - matchExpressions:
      - key: label1
      operator: In
      values:
        - value1a
        - value1b
  batchTimeoutAction: 10
status: 11
    computedMaxConcurrency: 2
    conditions:
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: 'True'
        type: ClustersSelected 12
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: Completed validation
        reason: ValidationCompleted
        status: 'True'
        type: Validated 13
      - lastTransitionTime: '2022-11-18T16:37:16Z'
        message: Not enabled
        reason: NotEnabled
        status: 'False'
        type: Progressing
    managedPoliciesForUpgrade:
      - name: talm-policy
        namespace: talm-namespace
    managedPoliciesNs:
      talm-policy: talm-namespace
    remediationPlan:
      - - spoke1
      - - spoke2
        - spoke3
    status:

1
각 클러스터에 대한 정책 수정을 완료할 때 TALM이 수행하는 작업을 지정합니다.
2
업데이트 프로세스를 시작할 때 TALM이 수행하는 작업을 지정합니다.
3
업데이트할 클러스터 목록을 정의합니다.
4
enable 필드는 false 로 설정됩니다.
5
수정할 사용자 정의 정책 집합을 나열합니다.
6
클러스터 업데이트의 세부 사항을 정의합니다.
7
카나리아 업데이트를 위한 클러스터를 정의합니다.
8
일괄 처리의 최대 동시 업데이트 수를 정의합니다. 수정 배치 수는 카나리아 클러스터 수와 카나리아 클러스터를 제외하고 maxConcurrency 값으로 나눈 클러스터 수입니다. 이미 모든 관리 정책과 호환되는 클러스터는 수정 계획에서 제외됩니다.
9
클러스터 선택을 위한 매개변수를 표시합니다.
10
일괄 처리가 시간 초과되는 경우 발생하는 작업을 제어합니다. 가능한 값은 abort 또는 continue 입니다. 지정되지 않은 경우 기본값은 계속됩니다.
11
업데이트 상태에 대한 정보를 표시합니다.
12
ClustersSelected 조건은 선택한 모든 클러스터가 유효한 것으로 표시됩니다.
13
검증됨 조건은 선택한 모든 클러스터가 검증되었음을 보여줍니다.
참고

카나리아 클러스터를 업데이트하는 동안 오류가 발생하면 업데이트 프로세스가 중지됩니다.

수정 계획이 성공적으로 생성되면 enable 필드를 true 로 설정하고 TALM이 지정된 관리 정책으로 호환되지 않는 클러스터를 업데이트하기 시작할 수 있습니다.

참고

ClusterGroupUpgrade CR의 enable 필드가 false 로 설정된 경우에만 spec 필드를 변경할 수 있습니다.

18.11.5.2. 검증

TALM은 지정된 모든 관리 정책이 사용 가능하고 올바른지 확인하고 검증 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.

  • true

    검증이 완료되었습니다.

  • false

    정책이 없거나 유효하지 않거나 잘못된 플랫폼 이미지가 지정되었습니다.

18.11.5.3. 사전 캐싱

클러스터는 컨테이너 이미지 레지스트리에 액세스하기 위한 대역폭이 제한될 수 있으므로 업데이트가 완료되기 전에 시간 초과가 발생할 수 있습니다. 단일 노드 OpenShift 클러스터에서는 사전 캐싱을 사용하여 이 문제를 방지할 수 있습니다. preCaching 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성할 때 컨테이너 이미지 사전 캐싱이 시작됩니다. TALM은 사용 가능한 디스크 공간을 예상 OpenShift Container Platform 이미지 크기와 비교하여 충분한 공간이 있는지 확인합니다. 클러스터에 공간이 충분하지 않으면 TALM은 해당 클러스터의 사전 캐싱을 취소하고 정책을 수정하지 않습니다.

TALM은 PrecacheSpecValid 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.

  • true

    사전 캐싱 사양은 유효하고 일관되게 유지됩니다.

  • false

    사전 캐싱 사양은 불완전합니다.

TALM은 PrecachingSucceeded 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.

  • true

    TALM은 사전 캐싱 프로세스를 완료했습니다. 클러스터에 대한 사전 캐싱이 실패하면 해당 클러스터에 대한 업데이트가 실패하지만 다른 모든 클러스터를 진행합니다. 클러스터에 대해 사전 캐싱이 실패한 경우 메시지가 표시됩니다.

  • false

    하나 이상의 클러스터에 대해 아직 진행 중이거나 모든 클러스터에서 실패했습니다.

자세한 내용은 "컨테이너 이미지 사전 캐시 기능 사용" 섹션을 참조하십시오.

18.11.5.4. 백업 생성

단일 노드 OpenShift의 경우 TALM은 업데이트 전에 배포 백업을 생성할 수 있습니다. 업데이트가 실패하면 이전 버전을 복구하고 애플리케이션을 다시 프로비저닝하지 않고도 클러스터를 작동 상태로 복원할 수 있습니다. 백업 기능을 사용하려면 먼저 backup 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성합니다. 백업 내용이 최신 상태인지 확인하기 위해 ClusterGroupUpgrade CR의 enable 필드를 true 로 설정할 때까지 백업이 수행되지 않습니다.

TALM은 BackupSucceeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.

  • true

    모든 클러스터 또는 백업 실행이 완료되었지만 하나 이상의 클러스터에 대해 백업이 완료되었습니다. 클러스터에 대한 백업이 실패하면 해당 클러스터에 대한 업데이트가 실패하지만 다른 모든 클러스터를 진행합니다.

  • false

    하나 이상의 클러스터에 대한 백업이 진행 중이거나 모든 클러스터에 실패했습니다.

자세한 내용은 "업그레이드 전에 클러스터 리소스의 백업 생성" 섹션을 참조하십시오.

18.11.5.5. 클러스터 업데이트

TALM은 수정 계획에 따라 정책을 적용합니다. 현재 배치의 모든 클러스터가 모든 관리 정책을 준수한 직후 후속 배치에 대한 정책을 강제 적용합니다. 배치 시간이 초과되면 TALM은 다음 일괄 처리로 이동합니다. 배치의 시간 초과 값은 수정 계획의 배치 수로 나눈 spec.timeout 필드입니다.

TALM은 Progressing 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.

  • true

    TALM은 준수하지 않는 정책을 수정하고 있습니다.

  • false

    업데이트가 진행 중이 아닙니다. 가능한 이유는 다음과 같습니다.

    • 모든 클러스터는 모든 관리 정책을 준수합니다.
    • 정책 수정이 너무 오래 걸리기 때문에 업데이트가 시간 초과되었습니다.
    • 차단 CR이 시스템에서 누락되었거나 아직 완료되지 않았습니다.
    • ClusterGroupUpgrade CR이 활성화되지 않습니다.
    • 백업은 아직 진행 중입니다.
참고

관리되는 정책은 ClusterGroupUpgrade CR의 managedPolicies 필드에 나열된 순서에 적용됩니다. 한 번에 지정된 클러스터에 하나의 관리 정책이 적용됩니다. 클러스터가 현재 정책을 준수하면 다음 관리 정책이 적용됩니다.

Progressing 상태의 샘플 ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
Spec:
  actions:
    afterCompletion:
      deleteObjects: true
    beforeEnable: {}
  backup: false
  clusters:
    - spoke1
  enable: true
  managedPolicies:
    - talm-policy
  preCaching: true
  remediationStrategy:
    canaries:
        - spoke1
    maxConcurrency: 2
    timeout: 240
  clusterLabelSelectors:
    - matchExpressions:
      - key: label1
      operator: In
      values:
        - value1a
        - value1b
  batchTimeoutAction:
status:
    clusters:
      - name: spoke1
        state: complete
    computedMaxConcurrency: 2
    conditions:
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: 'True'
        type: ClustersSelected
      - lastTransitionTime: '2022-11-18T16:27:15Z'
        message: Completed validation
        reason: ValidationCompleted
        status: 'True'
        type: Validated
      - lastTransitionTime: '2022-11-18T16:37:16Z'
        message: Remediating non-compliant policies
        reason: InProgress
        status: 'True'
        type: Progressing 1
    managedPoliciesForUpgrade:
      - name: talm-policy
        namespace: talm-namespace
    managedPoliciesNs:
      talm-policy: talm-namespace
    remediationPlan:
      - - spoke1
      - - spoke2
        - spoke3
    status:
      currentBatch: 2
      currentBatchRemediationProgress:
        spoke2:
          state: Completed
        spoke3:
          policyIndex: 0
          state: InProgress
      currentBatchStartedAt: '2022-11-18T16:27:16Z'
      startedAt: '2022-11-18T16:27:15Z'

1
진행 중 필드에 TALM이 정책을 수정하는 중입니다.
18.11.5.6. 업데이트 상태

TALM은 Succeeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.

  • true

    모든 클러스터는 지정된 관리 정책을 준수합니다.

  • false

    수정에 사용할 수 있는 클러스터가 없으므로 정책 수정이 실패했거나 다음과 같은 이유 중 하나에 정책 수정을 수행하는 데 시간이 너무 오래 걸리기 때문입니다.

    • 현재 배치에는 카나리아 업데이트가 포함되어 있으며 일괄 처리의 클러스터는 배치 시간 초과 내의 모든 관리 정책을 준수하지는 않습니다.
    • 클러스터는 remediationStrategy 필드에 지정된 타임아웃 값 내의 관리 정책을 준수하지 않았습니다.

Succeeded 상태의 샘플 ClusterGroupUpgrade CR

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-upgrade-complete
      namespace: default
    spec:
      clusters:
      - spoke1
      - spoke4
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status: 1
      clusters:
        - name: spoke1
          state: complete
        - name: spoke4
          state: complete
      conditions:
      - message: All selected clusters are valid
        reason: ClusterSelectionCompleted
        status: "True"
        type: ClustersSelected
      - message: Completed validation
        reason: ValidationCompleted
        status: "True"
        type: Validated
      - message: All clusters are compliant with all the managed policies
        reason: Completed
        status: "False"
        type: Progressing 2
      - message: All clusters are compliant with all the managed policies
        reason: Completed
        status: "True"
        type: Succeeded 3
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      remediationPlan:
      - - spoke1
      - - spoke4
      status:
        completedAt: '2022-11-18T16:27:16Z'
        startedAt: '2022-11-18T16:27:15Z'

2
업데이트가 완료되면 Progressing 필드에서 상태는 false 입니다. 클러스터는 모든 관리 정책을 준수합니다.
3
Succeeded 필드에 검증이 성공적으로 완료되었음을 보여줍니다.
1
status 필드에는 클러스터 목록과 해당 상태가 포함됩니다. 클러스터 상태는 완료 되거나 시간 초과 될 수 있습니다.

timedout 상태의 샘플 ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  creationTimestamp: '2022-11-18T16:27:15Z'
  finalizers:
    - ran.openshift.io/cleanup-finalizer
  generation: 1
  name: talm-cgu
  namespace: talm-namespace
  resourceVersion: '40451823'
  uid: cca245a5-4bca-45fa-89c0-aa6af81a596c
spec:
  actions:
    afterCompletion:
      deleteObjects: true
    beforeEnable: {}
  backup: false
  clusters:
    - spoke1
    - spoke2
  enable: true
  managedPolicies:
    - talm-policy
  preCaching: false
  remediationStrategy:
    maxConcurrency: 2
    timeout: 240
status:
  clusters:
    - name: spoke1
      state: complete
    - currentPolicy: 1
        name: talm-policy
        status: NonCompliant
      name: spoke2
      state: timedout
  computedMaxConcurrency: 2
  conditions:
    - lastTransitionTime: '2022-11-18T16:27:15Z'
      message: All selected clusters are valid
      reason: ClusterSelectionCompleted
      status: 'True'
      type: ClustersSelected
    - lastTransitionTime: '2022-11-18T16:27:15Z'
      message: Completed validation
      reason: ValidationCompleted
      status: 'True'
      type: Validated
    - lastTransitionTime: '2022-11-18T16:37:16Z'
      message: Policy remediation took too long
      reason: TimedOut
      status: 'False'
      type: Progressing
    - lastTransitionTime: '2022-11-18T16:37:16Z'
      message: Policy remediation took too long
      reason: TimedOut
      status: 'False'
      type: Succeeded 2
  managedPoliciesForUpgrade:
    - name: talm-policy
      namespace: talm-namespace
  managedPoliciesNs:
    talm-policy: talm-namespace
  remediationPlan:
    - - spoke1
      - spoke2
  status:
        startedAt: '2022-11-18T16:27:15Z'
        completedAt: '2022-11-18T20:27:15Z'

1
클러스터 상태가 timedout 인 경우 currentPolicy 필드에 정책 이름과 정책 상태가 표시됩니다.
2
success는 false 이며 메시지는 정책 수정이 너무 오래 걸리는 것을 나타냅니다.
18.11.5.7. Blocking ClusterGroupUpgrade CRs

ClusterGroupUpgrade CR을 여러 개 생성하고 애플리케이션 순서를 제어할 수 있습니다.

예를 들어 ClusterGroupUpgrade CR A의 시작을 차단하는 ClusterGroupUpgrade CR C를 생성하는 경우 ClusterGroupUpgrade CR C의 상태가 UpgradeComplete 가 될 때까지 ClusterGroupUpgrade CR A를 시작할 수 없습니다.

하나의 ClusterGroupUpgrade CR에는 차단 CR이 여러 개 있을 수 있습니다. 이 경우 현재 CR의 업그레이드가 시작되기 전에 차단 CR을 모두 완료해야 합니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

프로세스

  1. ClusterGroupUpgrade CR의 내용을 cgu-a.yaml,cgu-b.yamlcgu-c.yaml 파일에 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-a
      namespace: default
    spec:
      blockingCRs: 1
      - name: cgu-c
        namespace: default
      clusters:
      - spoke1
      - spoke2
      - spoke3
      enable: false
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      remediationStrategy:
        canaries:
        - spoke1
        maxConcurrency: 2
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR is not enabled
        reason: UpgradeNotStarted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      placementBindings:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      placementRules:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      remediationPlan:
      - - spoke1
      - - spoke2
    1
    blocking CR을 정의합니다. cgu-a 업데이트는 cgu-c 가 완료될 때까지 시작할 수 없습니다.
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-b
      namespace: default
    spec:
      blockingCRs: 1
      - name: cgu-a
        namespace: default
      clusters:
      - spoke4
      - spoke5
      enable: false
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR is not enabled
        reason: UpgradeNotStarted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke4
      - - spoke5
      status: {}
    1
    cgu-b 업데이트는 cgu-a 가 완료될 때까지 시작할 수 없습니다.
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-c
      namespace: default
    spec: 1
      clusters:
      - spoke6
      enable: false
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR is not enabled
        reason: UpgradeNotStarted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      managedPoliciesCompliantBeforeUpgrade:
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke6
      status: {}
    1
    cgu-c 업데이트에는 차단 CR이 없습니다. enable 필드가 true 로 설정된 경우 TALM은 cgu-c 업데이트를 시작합니다.
  2. 각 관련 CR에 대해 다음 명령을 실행하여 ClusterGroupUpgrade CR을 생성합니다.

    $ oc apply -f <name>.yaml
  3. 각 관련 CR에 대해 다음 명령을 실행하여 업데이트 프로세스를 시작합니다.

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \
    --type merge -p '{"spec":{"enable":true}}'

    다음 예제에서는 enable 필드가 true 로 설정된 ClusterGroupUpgrade CR을 보여줍니다.

    CR 차단이 있는 cgu-a 의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-a
      namespace: default
    spec:
      blockingCRs:
      - name: cgu-c
        namespace: default
      clusters:
      - spoke1
      - spoke2
      - spoke3
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      remediationStrategy:
        canaries:
        - spoke1
        maxConcurrency: 2
        timeout: 240
    status:
      conditions:
      - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
          completed: [cgu-c]' 1
        reason: UpgradeCannotStart
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      placementBindings:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      placementRules:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      remediationPlan:
      - - spoke1
      - - spoke2
      status: {}

    1
    차단 CR 목록을 표시합니다.

    CR 차단이 있는 cgu-b 의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-b
      namespace: default
    spec:
      blockingCRs:
      - name: cgu-a
        namespace: default
      clusters:
      - spoke4
      - spoke5
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
          completed: [cgu-a]' 1
        reason: UpgradeCannotStart
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke4
      - - spoke5
      status: {}

    1
    차단 CR 목록을 표시합니다.

    CR 차단이 있는 cgu-c 의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-c
      namespace: default
    spec:
      clusters:
      - spoke6
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant 1
        reason: UpgradeNotCompleted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      managedPoliciesCompliantBeforeUpgrade:
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke6
      status:
        currentBatch: 1
        remediationPlanForBatch:
          spoke6: 0

    1
    cgu-c 업데이트에는 차단 CR이 없습니다.

18.11.6. 관리 클러스터에서 정책 업데이트

TALM( Topology Aware Lifecycle Manager)은 ClusterGroupUpgrade CR에 지정된 클러스터에 대한 정보 정책 세트를 수정합니다. TALM은 관리 RHACM 정책의 사본을 적용하여 정보 정책을 해결합니다. 복사된 각 정책에는 고유한 RHACM 배치 규칙과 RHACM 배치 바인딩이 있습니다.

TALM은 현재 배치의 각 클러스터를 적용 가능한 관리 정책에 해당하는 배치 규칙에 추가합니다. 클러스터가 이미 정책과 호환되는 경우 TALM은 규정 준수 클러스터에 해당 정책 적용을 건너뜁니다. 그런 다음 TALM은 호환되지 않는 클러스터에 다음 정책을 적용하기 위해 계속 이동합니다. TALM이 배치의 업데이트를 완료하면 복사된 정책과 연결된 배치 규칙에서 모든 클러스터가 제거됩니다. 그런 다음 다음 배치의 업데이트가 시작됩니다.

spoke 클러스터에서 RHACM에 호환되는 상태를 보고하지 않으면 허브 클러스터의 관리 정책에 TALM에 필요한 상태 정보가 누락될 수 있습니다. TALM은 다음과 같은 방법으로 이러한 사례를 처리합니다.

  • 정책의 status.compliant 필드가 없는 경우 TALM은 정책을 무시하고 로그 항목을 추가합니다. 그런 다음 TALM은 정책의 status.status 필드를 계속 확인합니다.
  • 정책의 status.status 가 없으면 TALM에서 오류가 발생합니다.
  • 정책의 status.status 필드에 클러스터의 규정 준수 상태가 없는 경우 TALM은 해당 클러스터가 해당 정책과 호환되지 않는 것으로 간주합니다.

ClusterGroupUpgrade CR의 batchTimeoutAction 에 따라 클러스터에 대한 업그레이드가 실패하는 경우 발생하는 상황이 결정됩니다. 실패한 클러스터를 계속 건너뛰고 다른 클러스터를 계속 업그레이드하거나 모든 클러스터의 정책 수정을 중지하려면 중단을 지정할 수 있습니다. 시간 초과가 경과하면 TALM은 모든 적용 정책을 제거하여 클러스터에 대한 추가 업데이트가 없는지 확인합니다.

업그레이드 정책의 예

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: ocp-4.4.14.4
  namespace: platform-upgrade
spec:
  disabled: false
  policy-templates:
  - objectDefinition:
      apiVersion: policy.open-cluster-management.io/v1
      kind: ConfigurationPolicy
      metadata:
        name: upgrade
      spec:
        namespaceselector:
          exclude:
          - kube-*
          include:
          - '*'
        object-templates:
        - complianceType: musthave
          objectDefinition:
            apiVersion: config.openshift.io/v1
            kind: ClusterVersion
            metadata:
              name: version
            spec:
              channel: stable-4.14
              desiredUpdate:
                version: 4.4.14.4
              upstream: https://api.openshift.com/api/upgrades_info/v1/graph
            status:
              history:
                - state: Completed
                  version: 4.4.14.4
        remediationAction: inform
        severity: low
  remediationAction: inform

RHACM 정책에 대한 자세한 내용은 정책 개요 를 참조하십시오.

추가 리소스

PolicyGenTemplate CRD에 대한 자세한 내용은 PolicyGenTemplate CRD 정보를 참조하십시오.

18.11.6.1. TALM을 사용하여 설치하는 관리형 클러스터에 대한 Operator 서브스크립션 구성

Operator의 Subscription CR(사용자 정의 리소스)에 status.state.AtLatestKnown 필드가 포함된 경우에만 TALM( topology Aware Lifecycle Manager)은 Operator에 대한 설치 계획을 승인할 수 있습니다.

프로세스

  1. status.state.AtLatestKnown 필드를 Operator의 Subscription CR에 추가합니다.

    서브스크립션 CR의 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: cluster-logging
      namespace: openshift-logging
      annotations:
        ran.openshift.io/ztp-deploy-wave: "2"
    spec:
      channel: "stable"
      name: cluster-logging
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      installPlanApproval: Manual
    status:
      state: AtLatestKnown 1

    1
    status.state: AtLatestKnown 필드는 Operator 카탈로그에서 사용 가능한 최신 Operator 버전에 사용됩니다.
    참고

    레지스트리에서 새 버전의 Operator를 사용할 수 있으면 연결된 정책이 호환되지 않습니다.

  2. ClusterGroupUpgrade CR이 있는 관리 클러스터에 변경된 서브스크립션 정책을 적용합니다.
18.11.6.2. 관리 클러스터에 업데이트 정책 적용

정책을 적용하여 관리 클러스터를 업데이트할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

프로세스

  1. ClusterGroupUpgrade CR의 내용을 cgu-1.yaml 파일에 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-1
      namespace: default
    spec:
      managedPolicies: 1
        - policy1-common-cluster-version-policy
        - policy2-common-nto-sub-policy
        - policy3-common-ptp-sub-policy
        - policy4-common-sriov-sub-policy
      enable: false
      clusters: 2
      - spoke1
      - spoke2
      - spoke5
      - spoke6
      remediationStrategy:
        maxConcurrency: 2 3
        timeout: 240 4
      batchTimeoutAction: 5
    1
    적용할 정책의 이름입니다.
    2
    업데이트할 클러스터 목록입니다.
    3
    maxConcurrency 필드는 동시에 업데이트되는 클러스터 수를 나타냅니다.
    4
    업데이트 제한 시간(분)입니다.
    5
    일괄 처리가 시간 초과되는 경우 발생하는 작업을 제어합니다. 가능한 값은 abort 또는 continue 입니다. 지정되지 않은 경우 기본값은 계속됩니다.
  2. 다음 명령을 실행하여 ClusterGroupUpgrade CR을 생성합니다.

    $ oc create -f cgu-1.yaml
    1. 다음 명령을 실행하여 Hub 클러스터에서 ClusterGroupUpgrade CR이 생성되었는지 확인합니다.

      $ oc get cgu --all-namespaces

      출력 예

      NAMESPACE   NAME  AGE  STATE      DETAILS
      default     cgu-1 8m55 NotEnabled Not Enabled

    2. 다음 명령을 실행하여 업데이트 상태를 확인합니다.

      $ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq

      출력 예

      {
        "computedMaxConcurrency": 2,
        "conditions": [
          {
            "lastTransitionTime": "2022-02-25T15:34:07Z",
            "message": "Not enabled", 1
            "reason": "NotEnabled",
            "status": "False",
            "type": "Progressing"
          }
        ],
        "copiedPolicies": [
          "cgu-policy1-common-cluster-version-policy",
          "cgu-policy2-common-nto-sub-policy",
          "cgu-policy3-common-ptp-sub-policy",
          "cgu-policy4-common-sriov-sub-policy"
        ],
        "managedPoliciesContent": {
          "policy1-common-cluster-version-policy": "null",
          "policy2-common-nto-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"node-tuning-operator\",\"namespace\":\"openshift-cluster-node-tuning-operator\"}]",
          "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
          "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
        },
        "managedPoliciesForUpgrade": [
          {
            "name": "policy1-common-cluster-version-policy",
            "namespace": "default"
          },
          {
            "name": "policy2-common-nto-sub-policy",
            "namespace": "default"
          },
          {
            "name": "policy3-common-ptp-sub-policy",
            "namespace": "default"
          },
          {
            "name": "policy4-common-sriov-sub-policy",
            "namespace": "default"
          }
        ],
        "managedPoliciesNs": {
          "policy1-common-cluster-version-policy": "default",
          "policy2-common-nto-sub-policy": "default",
          "policy3-common-ptp-sub-policy": "default",
          "policy4-common-sriov-sub-policy": "default"
        },
        "placementBindings": [
          "cgu-policy1-common-cluster-version-policy",
          "cgu-policy2-common-nto-sub-policy",
          "cgu-policy3-common-ptp-sub-policy",
          "cgu-policy4-common-sriov-sub-policy"
        ],
        "placementRules": [
          "cgu-policy1-common-cluster-version-policy",
          "cgu-policy2-common-nto-sub-policy",
          "cgu-policy3-common-ptp-sub-policy",
          "cgu-policy4-common-sriov-sub-policy"
        ],
        "precaching": {
          "spec": {}
        },
        "remediationPlan": [
          [
            "spoke1",
            "spoke2"
          ],
          [
            "spoke5",
            "spoke6"
          ]
        ],
        "status": {}
      }

      1
      ClusterGroupUpgrade CR의 spec.enable 필드는 false 로 설정됩니다.
    3. 다음 명령을 실행하여 정책의 상태를 확인합니다.

      $ oc get policies -A

      출력 예

      NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
      default     cgu-policy1-common-cluster-version-policy            enforce                                 17m 1
      default     cgu-policy2-common-nto-sub-policy                    enforce                                 17m
      default     cgu-policy3-common-ptp-sub-policy                    enforce                                 17m
      default     cgu-policy4-common-sriov-sub-policy                  enforce                                 17m
      default     policy1-common-cluster-version-policy                inform               NonCompliant       15h
      default     policy2-common-nto-sub-policy                        inform               NonCompliant       15h
      default     policy3-common-ptp-sub-policy                        inform               NonCompliant       18m
      default     policy4-common-sriov-sub-policy                      inform               NonCompliant       18m

      1
      클러스터에 현재 적용된 정책의 spec.remediationAction 필드는 적용 하도록 설정되어 있습니다. 업데이트 중에 ClusterGroupUpgrade CR의 알림 모드에서 관리되는 정책은 알림 모드로 유지됩니다.
  3. 다음 명령을 실행하여 spec.enable 필드의 값을 true 로 변경합니다.

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \
    --patch '{"spec":{"enable":true}}' --type=merge

검증

  1. 다음 명령을 실행하여 업데이트 상태를 다시 확인합니다.

    $ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq

    출력 예

    {
      "computedMaxConcurrency": 2,
      "conditions": [ 1
        {
          "lastTransitionTime": "2022-02-25T15:33:07Z",
          "message": "All selected clusters are valid",
          "reason": "ClusterSelectionCompleted",
          "status": "True",
          "type": "ClustersSelected",
          "lastTransitionTime": "2022-02-25T15:33:07Z",
          "message": "Completed validation",
          "reason": "ValidationCompleted",
          "status": "True",
          "type": "Validated",
          "lastTransitionTime": "2022-02-25T15:34:07Z",
          "message": "Remediating non-compliant policies",
          "reason": "InProgress",
          "status": "True",
          "type": "Progressing"
        }
      ],
      "copiedPolicies": [
        "cgu-policy1-common-cluster-version-policy",
        "cgu-policy2-common-nto-sub-policy",
        "cgu-policy3-common-ptp-sub-policy",
        "cgu-policy4-common-sriov-sub-policy"
      ],
      "managedPoliciesContent": {
        "policy1-common-cluster-version-policy": "null",
        "policy2-common-nto-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"node-tuning-operator\",\"namespace\":\"openshift-cluster-node-tuning-operator\"}]",
        "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
        "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
      },
      "managedPoliciesForUpgrade": [
        {
          "name": "policy1-common-cluster-version-policy",
          "namespace": "default"
        },
        {
          "name": "policy2-common-nto-sub-policy",
          "namespace": "default"
        },
        {
          "name": "policy3-common-ptp-sub-policy",
          "namespace": "default"
        },
        {
          "name": "policy4-common-sriov-sub-policy",
          "namespace": "default"
        }
      ],
      "managedPoliciesNs": {
        "policy1-common-cluster-version-policy": "default",
        "policy2-common-nto-sub-policy": "default",
        "policy3-common-ptp-sub-policy": "default",
        "policy4-common-sriov-sub-policy": "default"
      },
      "placementBindings": [
        "cgu-policy1-common-cluster-version-policy",
        "cgu-policy2-common-nto-sub-policy",
        "cgu-policy3-common-ptp-sub-policy",
        "cgu-policy4-common-sriov-sub-policy"
      ],
      "placementRules": [
        "cgu-policy1-common-cluster-version-policy",
        "cgu-policy2-common-nto-sub-policy",
        "cgu-policy3-common-ptp-sub-policy",
        "cgu-policy4-common-sriov-sub-policy"
      ],
      "precaching": {
        "spec": {}
      },
      "remediationPlan": [
        [
          "spoke1",
          "spoke2"
        ],
        [
          "spoke5",
          "spoke6"
        ]
      ],
      "status": {
        "currentBatch": 1,
        "currentBatchStartedAt": "2022-02-25T15:54:16Z",
        "remediationPlanForBatch": {
          "spoke1": 0,
          "spoke2": 1
        },
        "startedAt": "2022-02-25T15:54:16Z"
      }
    }

    1
    현재 배치의 업데이트 진행 상황을 반영합니다. 이 명령을 다시 실행하여 진행 상황에 대한 업데이트된 정보를 수신합니다.
  2. 정책에 Operator 서브스크립션이 포함된 경우 단일 노드 클러스터에서 직접 설치 진행 상황을 확인할 수 있습니다.

    1. 다음 명령을 실행하여 설치 진행 상황을 확인할 단일 노드 클러스터의 KUBECONFIG 파일을 내보냅니다.

      $ export KUBECONFIG=<cluster_kubeconfig_absolute_path>
    2. 단일 노드 클러스터에 있는 모든 서브스크립션을 확인하고 다음 명령을 실행하여 ClusterGroupUpgrade CR을 통해 설치하려는 정책에서 해당 서브스크립션을 찾습니다.

      $ oc get subs -A | grep -i <subscription_name>

      cluster-logging 정책의 출력 예

      NAMESPACE                              NAME                         PACKAGE                      SOURCE             CHANNEL
      openshift-logging                      cluster-logging              cluster-logging              redhat-operators   stable

  3. 관리 정책 중 하나에 ClusterVersion CR이 포함된 경우 spoke 클러스터에 대해 다음 명령을 실행하여 현재 일괄 처리에서 플랫폼 업데이트 상태를 확인합니다.

    $ oc get clusterversion

    출력 예

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    version   4.4.14.5     True        True          43s     Working towards 4.4.14.7: 71 of 735 done (9% complete)

  4. 다음 명령을 실행하여 Operator 서브스크립션을 확인합니다.

    $ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"
  5. 다음 명령을 실행하여 원하는 서브스크립션과 연결된 단일 노드 클러스터에 있는 설치 계획을 확인합니다.

    $ oc get installplan -n <subscription_namespace>

    cluster-logging Operator의 출력 예

    NAMESPACE                              NAME            CSV                                 APPROVAL   APPROVED
    openshift-logging                      install-6khtw   cluster-logging.5.3.3-4             Manual     true 1

    1
    설치 계획의 승인 필드가 Manual 로 설정되고 TALM에서 설치 계획을 승인한 후 승인 필드가 false 에서 true 로 변경됩니다.
    참고

    TALM이 서브스크립션이 포함된 정책을 수정하면 해당 서브스크립션에 연결된 모든 설치 계획을 자동으로 승인합니다. Operator를 최신 알려진 버전으로 가져오기 위해 여러 설치 계획이 필요한 경우 TALM은 여러 설치 계획을 승인하여 하나 이상의 중간 버전을 통해 최종 버전으로 업그레이드할 수 있습니다.

  6. 다음 명령을 실행하여 ClusterGroupUpgradeSucceeded 단계에 도달한 정책의 Operator의 클러스터 서비스 버전이 있는지 확인합니다.

    $ oc get csv -n <operator_namespace>

    OpenShift Logging Operator의 출력 예

    NAME                    DISPLAY                     VERSION   REPLACES   PHASE
    cluster-logging.5.4.2   Red Hat OpenShift Logging   5.4.2                Succeeded

18.11.7. 업그레이드하기 전에 클러스터 리소스의 백업 생성

단일 노드 OpenShift의 경우 TALM(토폴로지 Aware Lifecycle Manager)은 업그레이드하기 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 이전 버전을 복구하고 애플리케이션을 다시 프로비저닝하지 않고도 클러스터를 작동 상태로 복원할 수 있습니다.

백업 기능을 사용하려면 먼저 backup 필드가 true 로 설정된 ClusterGroupUpgrade CR을 생성합니다. 백업 내용이 최신 상태인지 확인하기 위해 ClusterGroupUpgrade CR의 enable 필드를 true 로 설정할 때까지 백업이 수행되지 않습니다.

TALM은 BackupSucceeded 조건을 사용하여 다음과 같이 상태 및 이유를 보고합니다.

  • true

    모든 클러스터 또는 백업 실행이 완료되었지만 하나 이상의 클러스터에 대해 백업이 완료되었습니다. 클러스터에 대한 백업이 실패하면 해당 클러스터를 업데이트하지 않습니다.

  • false

    하나 이상의 클러스터에 대한 백업이 진행 중이거나 모든 클러스터에 실패했습니다. spoke 클러스터에서 실행되는 백업 프로세스는 다음과 같은 상태를 가질 수 있습니다.

    • preparingToStart

      첫 번째 조정 단계는 진행 중입니다. TALM은 업그레이드 실패 시 생성된 모든 spoke 백업 네임스페이스 및 허브 뷰 리소스를 삭제합니다.

    • Starting

      백업 사전 요구 사항 및 백업 작업이 생성 중입니다.

    • 활성 상태

      백업이 진행 중입니다.

    • succeeded

      백업에 성공했습니다.

    • BackupTimeout

      아티팩트 백업은 부분적으로 수행됩니다.

    • UnrecoverableError

      백업이 0이 아닌 종료 코드로 종료되었습니다.

참고

클러스터 백업에 실패하고 BackupTimeout 또는 UnrecoverableError 상태를 입력하면 클러스터 업데이트가 해당 클러스터를 진행하지 않습니다. 다른 클러스터의 업데이트는 영향을 받지 않으며 계속됩니다.

18.11.7.1. 백업을 사용하여 ClusterGroupUpgrade CR 생성

단일 노드 OpenShift 클러스터에서 업그레이드하기 전에 배포 백업을 생성할 수 있습니다. 업그레이드에 실패하면 Topology Aware Lifecycle Manager(TALM)에서 생성한 upgrade-recovery.sh 스크립트를 사용하여 시스템을 사전 업그레이드 상태로 되돌릴 수 있습니다. 백업은 다음 항목으로 구성됩니다.

클러스터 백업
etcd 및 정적 pod 매니페스트의 스냅샷입니다.
콘텐츠 백업
폴더의 백업(예: /etc,/usr/local,/var/lib/kubelet ).
변경된 파일 백업
변경된 machine-config 에서 관리하는 모든 파일입니다.
Deployment
고정된 ostree 배포입니다.
이미지(선택 사항)
사용 중인 컨테이너 이미지입니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • RHACM(Red Hat Advanced Cluster Management)을 설치합니다.
참고

복구 파티션을 만드는 것이 좋습니다. 다음은 50GB의 복구 파티션에 대한 SiteConfig CR(사용자 정의 리소스)의 예입니다.

nodes:
    - hostName: "node-1.example.com"
    role: "master"
    rootDeviceHints:
        hctl: "0:2:0:0"
        deviceName: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
...
    #Disk /dev/disk/by-id/scsi-3600508b400105e210000900000490000:
    #893.3 GiB, 959119884288 bytes, 1873281024 sectors
    diskPartition:
        - device: /dev/disk/by-id/scsi-3600508b400105e210000900000490000
        partitions:
        - mount_point: /var/recovery
            size: 51200
            start: 800000

프로세스

  1. clustergroupupgrades-group-du.yaml 파일에서 backupenable 필드를 true 로 설정하여 ClusterGroupUpgrade CR의 내용을 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: du-upgrade-4918
      namespace: ztp-group-du-sno
    spec:
      preCaching: true
      backup: true
      clusters:
      - cnfdb1
      - cnfdb2
      enable: true
      managedPolicies:
      - du-upgrade-platform-upgrade
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
  2. 업데이트를 시작하려면 다음 명령을 실행하여 ClusterGroupUpgrade CR을 적용합니다.

    $ oc apply -f clustergroupupgrades-group-du.yaml

검증

  • 다음 명령을 실행하여 hub 클러스터에서 업그레이드 상태를 확인합니다.

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    출력 예

    {
        "backup": {
            "clusters": [
                "cnfdb2",
                "cnfdb1"
        ],
        "status": {
            "cnfdb1": "Succeeded",
            "cnfdb2": "Failed" 1
        }
    },
    "computedMaxConcurrency": 1,
    "conditions": [
        {
            "lastTransitionTime": "2022-04-05T10:37:19Z",
            "message": "Backup failed for 1 cluster", 2
            "reason": "PartiallyDone", 3
            "status": "True", 4
            "type": "Succeeded"
        }
    ],
    "precaching": {
        "spec": {}
    },
    "status": {}

    1
    하나의 클러스터에 대한 백업이 실패했습니다.
    2
    이 메시지는 하나의 클러스터에 대한 백업이 실패했음을 확인합니다.
    3
    백업은 부분적으로 성공적으로 수행되었습니다.
    4
    백업 프로세스가 완료되었습니다.
18.11.7.2. 업그레이드 실패 후 클러스터 복구

클러스터 업그레이드가 실패하면 클러스터에 수동으로 로그인하고 백업을 사용하여 클러스터를 업그레이드 전 상태로 되돌릴 수 있습니다. 두 단계가 있습니다.

rollback
시도한 업그레이드에 플랫폼 OS 배포 변경 사항이 포함된 경우 복구 스크립트를 실행하기 전에 이전 버전으로 롤백해야 합니다.
중요

롤백은 TALM 및 단일 노드 OpenShift에서 업그레이드하는 경우에만 사용할 수 있습니다. 이 프로세스는 다른 업그레이드 유형의 롤백에는 적용되지 않습니다.

복구
복구는 컨테이너를 종료하고 백업 파티션의 파일을 사용하여 컨테이너를 다시 시작하고 클러스터를 복원합니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • RHACM(Red Hat Advanced Cluster Management)을 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 백업용으로 구성된 업그레이드를 실행합니다.

프로세스

  1. 다음 명령을 실행하여 이전에 생성한 ClusterGroupUpgrade CR(사용자 정의 리소스)을 삭제합니다.

    $ oc delete cgu/du-upgrade-4918 -n ztp-group-du-sno
  2. 복구할 클러스터에 로그인합니다.
  3. 다음 명령을 실행하여 플랫폼 OS 배포의 상태를 확인합니다.

    $ ostree admin status

    출력 예

    [root@lab-test-spoke2-node-0 core]# ostree admin status
    * rhcos c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9.0
        Version: 49.84.202202230006-0
        Pinned: yes 1
        origin refspec: c038a8f08458bbed83a77ece033ad3c55597e3f64edad66ea12fda18cbdceaf9

    1
    현재 배포가 고정되어 있습니다. 플랫폼 OS 배포 롤백은 필요하지 않습니다.
    [root@lab-test-spoke2-node-0 core]# ostree admin status
    * rhcos f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa.0
        Version: 410.84.202204050541-0
        origin refspec: f750ff26f2d5550930ccbe17af61af47daafc8018cd9944f2a3a6269af26b0fa
    rhcos ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca.0 (rollback) 1
        Version: 410.84.202203290245-0
        Pinned: yes 2
        origin refspec: ad8f159f9dc4ea7e773fd9604c9a16be0fe9b266ae800ac8470f63abc39b52ca
    1
    이 플랫폼 OS 배포는 롤백용으로 표시됩니다.
    2
    이전 배포가 고정되어 롤백할 수 있습니다.
  4. 플랫폼 OS 배포의 롤백을 트리거하려면 다음 명령을 실행합니다.

    $ rpm-ostree rollback -r
  5. 복구의 첫 번째 단계는 컨테이너를 종료하고 백업 파티션에서 대상 디렉터리로 파일을 복원합니다. 복구를 시작하려면 다음 명령을 실행합니다.

    $ /var/recovery/upgrade-recovery.sh
  6. 메시지가 표시되면 다음 명령을 실행하여 클러스터를 재부팅합니다.

    $ systemctl reboot
  7. 재부팅 후 다음 명령을 실행하여 복구를 다시 시작합니다.

    $ /var/recovery/upgrade-recovery.sh  --resume
참고

복구 유틸리티가 실패하면 --restart 옵션을 사용하여 다시 시도할 수 있습니다.

$ /var/recovery/upgrade-recovery.sh --restart

검증

  • 복구 상태를 확인하려면 다음 명령을 실행합니다.

    $ oc get clusterversion,nodes,clusteroperator

    출력 예

    NAME                                         VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    clusterversion.config.openshift.io/version   4.4.14.23    True        False         86d     Cluster version is 4.4.14.23 1
    
    
    NAME                          STATUS   ROLES           AGE   VERSION
    node/lab-test-spoke1-node-0   Ready    master,worker   86d   v1.22.3+b93fd35 2
    
    NAME                                                                           VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
    clusteroperator.config.openshift.io/authentication                             4.4.14.23    True        False         False      2d7h    3
    clusteroperator.config.openshift.io/baremetal                                  4.4.14.23    True        False         False      86d
    
    
    ..............

    1
    클러스터 버전을 사용할 수 있으며 올바른 버전이 있습니다.
    2
    노드 상태가 Ready 입니다.
    3
    ClusterOperator 오브젝트의 가용성은 True 입니다.

18.11.8. 컨테이너 이미지 사전 캐시 기능 사용

단일 노드 OpenShift 클러스터는 컨테이너 이미지 레지스트리에 액세스하기 위해 대역폭이 제한될 수 있으므로 업데이트가 완료되기 전에 시간 초과가 발생할 수 있습니다.

참고

업데이트 시간은 TALM에 의해 설정되지 않습니다. 수동 애플리케이션 또는 외부 자동화를 통해 업데이트 시작 시 ClusterGroupUpgrade CR을 적용할 수 있습니다.

ClusterGroupUpgrade CR에서 preCaching 필드가 true 로 설정된 경우 컨테이너 이미지 사전 캐싱이 시작됩니다.

TALM은 PrecacheSpecValid 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.

  • true

    사전 캐싱 사양은 유효하고 일관되게 유지됩니다.

  • false

    사전 캐싱 사양은 불완전합니다.

TALM은 PrecachingSucceeded 조건을 사용하여 다음과 같이 상태 정보를 보고합니다.

  • true

    TALM은 사전 캐싱 프로세스를 완료했습니다. 클러스터에 대한 사전 캐싱이 실패하면 해당 클러스터에 대한 업데이트가 실패하지만 다른 모든 클러스터를 진행합니다. 클러스터에 대해 사전 캐싱이 실패한 경우 메시지가 표시됩니다.

  • false

    하나 이상의 클러스터에 대해 아직 진행 중이거나 모든 클러스터에서 실패했습니다.

성공적인 사전 캐싱 프로세스 후 정책 수정을 시작할 수 있습니다. 수정 작업은 enable 필드가 true 로 설정된 경우 시작됩니다. 클러스터에 사전 캐싱 오류가 발생하면 해당 클러스터에 대한 업그레이드가 실패합니다. 업그레이드 프로세스는 사전 캐시가 성공한 다른 모든 클러스터에서 계속됩니다.

사전 캐싱 프로세스는 다음과 같은 상태에 있을 수 있습니다.

  • NotStarted

    이는 ClusterGroupUpgrade CR의 첫 번째 조정 패스에서 모든 클러스터가 자동으로 할당됩니다. 이 상태에서 TALM은 이전에 불완전한 업데이트에서 남아 있는 spoke 클러스터의 모든 사전 캐싱 네임스페이스 및 허브 뷰 리소스를 삭제합니다. 그런 다음 TALM은 PrecachePreparing 상태에서 삭제를 확인하기 위해 spoke pre-caching 네임스페이스에 대한 새 ManagedClusterView 리소스를 생성합니다.

  • preparingToStart

    이전 불완전한 업데이트의 나머지 리소스를 정리하는 작업이 진행 중입니다.

  • Starting

    작업 사전 캐싱 사전 요구 사항 및 작업이 생성됩니다.

  • 활성 상태

    작업은 "활성" 상태입니다.

  • succeeded

    pre-cache 작업이 성공했습니다.

  • PrecacheTimeout

    아티팩트 사전 캐싱은 부분적으로 수행됩니다.

  • UnrecoverableError

    작업은 0이 아닌 종료 코드로 끝납니다.

18.11.8.1. 컨테이너 이미지 사전 캐시 필터 사용

사전 캐시 기능은 일반적으로 업데이트에 필요한 클러스터보다 많은 이미지를 다운로드합니다. 클러스터에 다운로드되는 사전 캐시 이미지를 제어할 수 있습니다. 이렇게 하면 다운로드 시간이 줄어들고 대역폭과 스토리지를 절약할 수 있습니다.

다음 명령을 사용하여 다운로드할 모든 이미지 목록을 확인할 수 있습니다.

$ oc adm release info <ocp-version>

다음 ConfigMap 예제에서는 excludePrecachePatterns 필드를 사용하여 이미지를 제외하는 방법을 보여줍니다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-group-upgrade-overrides
data:
  excludePrecachePatterns: |
    azure 1
    aws
    vsphere
    alibaba
1
TALM은 여기에 나열된 패턴이 포함된 이름이 있는 모든 이미지를 제외합니다.
18.11.8.2. 사전 캐싱을 사용하여 ClusterGroupUpgrade CR 생성

단일 노드 OpenShift의 경우 사전 캐시 기능을 사용하면 업데이트가 시작되기 전에 필요한 컨테이너 이미지를 spoke 클러스터에 표시할 수 있습니다.

참고

사전 캐싱의 경우 TALM은 ClusterGroupUpgrade CR의 spec.remediationStrategy.timeout 값을 사용합니다. 사전 캐싱 작업을 완료하는 데 충분한 시간을 허용하는 시간 초과 값을 설정해야 합니다. 사전 캐싱이 완료된 후 ClusterGroupUpgrade CR을 활성화하면 시간 초과 값을 업데이트에 적합한 기간으로 변경할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. clustergroupupgrades-group-du.yaml 파일에서 preCaching 필드를 true 로 설정하여 ClusterGroupUpgrade CR의 내용을 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: du-upgrade-4918
      namespace: ztp-group-du-sno
    spec:
      preCaching: true 1
      clusters:
      - cnfdb1
      - cnfdb2
      enable: false
      managedPolicies:
      - du-upgrade-platform-upgrade
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
    1
    preCaching 필드는 true 로 설정되어 업데이트를 시작하기 전에 TALM에서 컨테이너 이미지를 가져올 수 있습니다.
  2. 사전 캐싱을 시작하려면 다음 명령을 실행하여 ClusterGroupUpgrade CR을 적용합니다.

    $ oc apply -f clustergroupupgrades-group-du.yaml

검증

  1. 다음 명령을 실행하여 Hub 클러스터에 ClusterGroupUpgrade CR이 있는지 확인합니다.

    $ oc get cgu -A

    출력 예

    NAMESPACE          NAME              AGE   STATE        DETAILS
    ztp-group-du-sno   du-upgrade-4918   10s   InProgress   Precaching is required and not done 1

    1
    CR이 생성됩니다.
  2. 다음 명령을 실행하여 사전 캐싱 작업의 상태를 확인합니다.

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    출력 예

    {
      "conditions": [
        {
          "lastTransitionTime": "2022-01-27T19:07:24Z",
          "message": "Precaching is required and not done",
          "reason": "InProgress",
          "status": "False",
          "type": "PrecachingSucceeded"
        },
        {
          "lastTransitionTime": "2022-01-27T19:07:34Z",
          "message": "Pre-caching spec is valid and consistent",
          "reason": "PrecacheSpecIsWellFormed",
          "status": "True",
          "type": "PrecacheSpecValid"
        }
      ],
      "precaching": {
        "clusters": [
          "cnfdb1" 1
          "cnfdb2"
        ],
        "spec": {
          "platformImage": "image.example.io"},
        "status": {
          "cnfdb1": "Active"
          "cnfdb2": "Succeeded"}
        }
    }

    1
    식별된 클러스터 목록을 표시합니다.
  3. spoke 클러스터에서 다음 명령을 실행하여 사전 캐싱 작업의 상태를 확인합니다.

    $ oc get jobs,pods -n openshift-talo-pre-cache

    출력 예

    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

  4. 다음 명령을 실행하여 ClusterGroupUpgrade CR의 상태를 확인합니다.

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    출력 예

    "conditions": [
        {
          "lastTransitionTime": "2022-01-27T19:30:41Z",
          "message": "The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies",
          "reason": "UpgradeCompleted",
          "status": "True",
          "type": "Ready"
        },
        {
          "lastTransitionTime": "2022-01-27T19:28:57Z",
          "message": "Precaching is completed",
          "reason": "PrecachingCompleted",
          "status": "True",
          "type": "PrecachingSucceeded" 1
        }

    1
    사전 캐시 작업이 수행됩니다.

18.11.9. 토폴로지 인식 라이프사이클 관리자 문제 해결

Topology Aware Lifecycle Manager (TALM)는 RHACM 정책을 수정하는 OpenShift Container Platform Operator입니다. 문제가 발생하면 oc adm must-gather 명령을 사용하여 세부 정보 및 로그를 수집하고 문제를 디버깅하는 단계를 수행합니다.

관련 항목에 대한 자세한 내용은 다음 설명서를 참조하십시오.

18.11.9.1. 일반 문제 해결

다음 질문을 검토하여 문제의 원인을 확인할 수 있습니다.

ClusterGroupUpgrade 구성이 작동하는지 확인하려면 다음을 수행할 수 있습니다.

  1. spec.enable 필드가 false 로 설정된 ClusterGroupUpgrade CR을 생성합니다.
  2. 상태가 업데이트될 때까지 기다린 후 문제 해결 질문을 진행합니다.
  3. 모든 항목이 예상대로 표시되면 ClusterGroupUpgrade CR에서 spec.enable 필드를 true 로 설정합니다.
주의

ClusterUpgradeGroup CR에서 spec.enable 필드를 true 로 설정한 후에는 업데이트 절차가 시작되고 CR의 spec 필드를 더 이상 편집할 수 없습니다.

18.11.9.2. ClusterUpgradeGroup CR을 수정할 수 없음
문제
업데이트를 활성화한 후에는 ClusterUpgradeGroup CR을 편집할 수 없습니다.
해결

다음 단계를 수행하여 절차를 다시 시작합니다.

  1. 다음 명령을 실행하여 이전 ClusterGroupUpgrade CR을 제거합니다.

    $ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>
  2. 관리 클러스터 및 정책의 기존 문제를 확인하고 수정합니다.

    1. 모든 클러스터가 관리 클러스터이고 사용 가능한지 확인합니다.
    2. 모든 정책이 존재하고 spec.remediationAction 필드가 설정되어 있는지 확인합니다.
  3. 올바른 구성으로 새 ClusterGroupUpgrade CR을 생성합니다.

    $ oc apply -f <ClusterGroupUpgradeCR_YAML>
18.11.9.3. 관리형 정책
시스템에서 관리되는 정책 확인
문제
시스템에 올바른 관리 정책이 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'

출력 예

["group-du-sno-validator-du-validator-policy", "policy2-common-nto-sub-policy", "policy3-common-ptp-sub-policy"]

수정 모드 확인
문제
관리 정책의 사양에 알리 도록 remediationAction 필드가 설정되어 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get policies --all-namespaces

출력 예

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

정책 규정 준수 상태 확인
문제
정책의 규정 준수 상태를 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get policies --all-namespaces

출력 예

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

18.11.9.4. 클러스터
관리 클러스터가 있는지 확인
문제
ClusterGroupUpgrade CR의 클러스터가 관리 클러스터인지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get managedclusters

출력 예

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

  1. 또는 TALM 관리자 로그를 확인합니다.

    1. 다음 명령을 실행하여 TALM 관리자의 이름을 가져옵니다.

      $ oc get pod -n openshift-operators

      출력 예

      NAME                                                         READY   STATUS    RESTARTS   AGE
      cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp   2/2     Running   0          45m

    2. 다음 명령을 실행하여 TALM 관리자 로그를 확인합니다.

      $ oc logs -n openshift-operators \
      cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

      출력 예

      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"} 1
      sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

      1
      오류 메시지는 클러스터가 관리 클러스터가 아님을 나타냅니다.
관리 클러스터를 사용할 수 있는지 확인
문제
ClusterGroupUpgrade CR에 지정된 관리 클러스터를 사용할 수 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get managedclusters

출력 예

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 1
spoke3          true           https://api.spoke3.testlab.com:6443     True     True        27h 2

1 2
AVAILABLE 필드의 값은 관리되는 클러스터의 경우 True 입니다.
clusterLabelSelector 확인
문제
ClusterGroupUpgrade CR에 지정된 clusterLabelSelector 필드가 관리 클러스터 중 하나와 일치하는지 확인해야 합니다.
해결

다음 명령을 실행합니다.

$ oc get managedcluster --selector=upgrade=true 1
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

카나리아 클러스터가 있는지 확인
문제

카나리아 클러스터가 클러스터 목록에 있는지 확인하려고 합니다.

ClusterGroupUpgrade CR의 예

spec:
    remediationStrategy:
        canaries:
        - spoke3
        maxConcurrency: 2
        timeout: 240
    clusterLabelSelectors:
      - matchLabels:
          upgrade: true

해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'

출력 예

["spoke1", "spoke3"]

  1. 다음 명령을 실행하여 카나리아 클러스터가 clusterLabelSelector 라벨과 일치하는 클러스터 목록에 있는지 확인합니다.

    $ oc get managedcluster --selector=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

참고

클러스터는 spec.clusters 에 존재할 수 있으며 spec.clusterLabelSelector 라벨과 일치할 수도 있습니다.

spoke 클러스터에서 사전 캐싱 상태 확인
  1. spoke 클러스터에서 다음 명령을 실행하여 사전 캐싱 상태를 확인합니다.

    $ oc get jobs,pods -n openshift-talo-pre-cache
18.11.9.5. 수정 전략
ClusterGroupUpgrade CR에 remediationStrategy가 있는지 확인
문제
remediationStrategyClusterGroupUpgrade CR에 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'

출력 예

{"maxConcurrency":2, "timeout":240}

ClusterGroupUpgrade CR에 maxConcurrency가 지정되었는지 확인
문제
maxConcurrencyClusterGroupUpgrade CR에 지정되어 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'

출력 예

2

18.11.9.6. 토폴로지 인식 라이프사이클 관리자
ClusterGroupUpgrade CR에서 조건 메시지 및 상태 확인
문제
ClusterGroupUpgrade CR에서 status.conditions 필드의 값을 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'

출력 예

{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"Missing managed policies:[policyList]", "reason":"NotAllManagedPoliciesExist", "status":"False", "type":"Validated"}

복사된 해당 정책 확인
문제
status.managedPoliciesForUpgrade 의 모든 정책에 status.copiedPolicies.copiedPolicies의 해당 정책이 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -oyaml

출력 예

status:
  …
  copiedPolicies:
  - lab-upgrade-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy3-common-ptp-sub-policy
    namespace: default

status.remediationPlan이 계산되었는지 확인
문제
status.remediationPlan 이 계산되었는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'

출력 예

[["spoke2", "spoke3"]]

TALM 관리자 컨테이너의 오류
문제
TALM의 manager 컨테이너의 로그를 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc logs -n openshift-operators \
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

출력 예

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"} 1
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

1
오류를 표시합니다.
ClusterGroupUpgrade CR이 완료된 후 일부 정책을 준수하지 않는 클러스터
문제

TALM이 사용하는 정책 준수 상태는 모든 클러스터에 대해 수정이 아직 완전히 업데이트되지 않았는지 여부를 결정하는 데 사용합니다. 그 이유는 다음과 같습니다.

  • 정책을 만들거나 업데이트한 후 CGU가 너무 빨리 실행되었습니다.
  • 정책을 수정하면 ClusterGroupUpgrade CR의 후속 정책 준수에 영향을 미칩니다.
해결
동일한 사양으로 새 ClusterGroupUpdate CR을 생성하고 적용합니다.
GitOps ZTP 워크플로의 자동 생성된 ClusterGroupUpgrade CR에는 관리 정책이 없습니다.
문제
클러스터가 Ready 가 될 때 관리 클러스터에 대한 정책이 없는 경우 정책이 자동으로 생성되지 않은 ClusterGroupUpgrade CR이 있습니다. ClusterGroupUpgrade CR이 완료되면 관리 클러스터에 ztp-done 이라는 레이블이 지정됩니다. SiteConfig 리소스를 푸시한 후 필요한 시간 내에 PolicyGenTemplate CR이 Git 리포지토리로 푸시되지 않은 경우 클러스터가 Ready 상태가 되면 대상 클러스터에 정책을 사용할 수 없을 수 있습니다.
해결
적용할 정책을 hub 클러스터에서 사용할 수 있는지 확인한 다음 필요한 정책을 사용하여 ClusterGroupUpgrade CR을 생성합니다.

ClusterGroupUpgrade CR을 수동으로 생성하거나 자동 생성을 다시 트리거할 수 있습니다. ClusterGroupUpgrade CR의 자동 생성을 트리거하려면 클러스터에서 ztp-done 레이블을 제거하고 zip-install 네임스페이스에서 이전에 생성된 비어 있는 ClusterGroupUpgrade CR을 삭제합니다.

사전 캐싱 실패
문제

다음 이유 중 하나로 인해 사전 캐싱이 실패할 수 있습니다.

  • 노드에 사용 가능한 공간이 충분하지 않습니다.
  • 연결이 끊긴 환경의 경우 사전 캐시 이미지가 올바르게 미러링되지 않았습니다.
  • Pod를 생성할 때 문제가 발생했습니다.
해결
  1. 공간이 부족하여 사전 캐싱이 실패했는지 확인하려면 노드에서 사전 캐싱 Pod의 로그를 확인합니다.

    1. 다음 명령을 사용하여 Pod 이름을 찾습니다.

      $ oc get pods -n openshift-talo-pre-cache
    2. 다음 명령을 사용하여 로그에서 오류가 충분하지 않은 공간과 관련이 있는지 확인합니다.

      $ oc logs -n openshift-talo-pre-cache <pod name>
  2. 로그가 없는 경우 다음 명령을 사용하여 Pod 상태를 확인합니다.

    $ oc describe pod -n openshift-talo-pre-cache <pod name>
  3. Pod가 없는 경우 작업 상태를 확인하여 다음 명령을 사용하여 Pod를 생성할 수 없는 이유를 확인합니다.

    $ oc describe job -n openshift-talo-pre-cache pre-cache

추가 리소스

18.12. 토폴로지 Aware Lifecycle Manager를 사용하여 연결이 끊긴 환경에서 관리형 클러스터 업데이트

Topology Aware Lifecycle Manager (TALM)를 사용하여 OpenShift Container Platform 관리 클러스터의 소프트웨어 라이프사이클을 관리할 수 있습니다. TALM은 RHACM(Red Hat Advanced Cluster Management) 정책을 사용하여 대상 클러스터에서 변경 사항을 수행합니다.

추가 리소스

18.12.1. 연결이 끊긴 환경에서 클러스터 업데이트

ZTP(ZTP) 및 Topology Aware Lifecycle Manager(TALM)를 사용하여 배포한 관리형 클러스터 및 Operator를 업그레이드할 수 있습니다.

18.12.1.1. 환경 설정

TALM은 플랫폼과 Operator 업데이트를 모두 수행할 수 있습니다.

TALM을 사용하여 연결이 끊긴 클러스터를 업데이트하기 전에 미러 레지스트리에서 업데이트하려는 플랫폼 이미지와 Operator 이미지를 모두 미러링해야 합니다. 이미지를 미러링하려면 다음 단계를 완료합니다.

  • 플랫폼 업데이트의 경우 다음 단계를 수행해야 합니다.

    1. 원하는 OpenShift Container Platform 이미지 저장소를 미러링합니다. 추가 리소스에 연결된 "OpenShift Container Platform 이미지 저장소 미러링" 절차에 따라 원하는 플랫폼 이미지가 미러링되었는지 확인합니다. imageContentSources 섹션의 내용을 imageContentSources.yaml 파일에 저장합니다.

      출력 예

      imageContentSources:
       - mirrors:
         - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
         source: quay.io/openshift-release-dev/ocp-release
       - mirrors:
         - mirror-ocp-registry.ibmcloud.io.cpak:5000/openshift-release-dev/openshift4
         source: quay.io/openshift-release-dev/ocp-v4.0-art-dev

    2. 미러링된 플랫폼 이미지의 이미지 서명을 저장합니다. 플랫폼 업데이트를 위해 PolicyGenTemplate CR에 이미지 서명을 추가해야 합니다. 이미지 서명을 가져오려면 다음 단계를 수행합니다.

      1. 다음 명령을 실행하여 원하는 OpenShift Container Platform 태그를 지정합니다.

        $ OCP_RELEASE_NUMBER=<release_version>
      2. 다음 명령을 실행하여 클러스터의 아키텍처를 지정합니다.

        $ ARCHITECTURE=<cluster_architecture> 1
        1
        x86_64,aarch64,s390x 또는 ppc64le 과 같은 클러스터의 아키텍처를 지정합니다.
      3. 다음 명령을 실행하여 Quay에서 릴리스 이미지 다이제스트를 가져옵니다.

        $ DIGEST="$(oc adm release info quay.io/openshift-release-dev/ocp-release:${OCP_RELEASE_NUMBER}-${ARCHITECTURE} | sed -n 's/Pull From: .*@//p')"
      4. 다음 명령을 실행하여 다이제스트 알고리즘을 설정합니다.

        $ DIGEST_ALGO="${DIGEST%%:*}"
      5. 다음 명령을 실행하여 다이제스트 서명을 설정합니다.

        $ DIGEST_ENCODED="${DIGEST#*:}"
      6. 다음 명령을 실행하여 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)
      7. 다음 명령을 실행하여 checksum-<OCP_RELEASE_NUMBER>.yaml 파일에 이미지 서명을 저장합니다.

        $ cat >checksum-${OCP_RELEASE_NUMBER}.yaml <<EOF
        ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64}
        EOF
    3. 업데이트 그래프를 준비합니다. 업데이트 그래프를 준비할 수 있는 두 가지 옵션이 있습니다.

      1. OpenShift 업데이트 서비스를 사용합니다.

        hub 클러스터에 그래프를 설정하는 방법에 대한 자세한 내용은 OpenShift Update Service용 Operator 배포그래프 데이터 init 컨테이너 빌드를 참조하십시오.

      2. 업스트림 그래프의 로컬 사본을 만듭니다. 관리 클러스터에 액세스할 수 있는 연결이 끊긴 환경의 http 또는 https 서버에서 업데이트 그래프를 호스팅합니다. 업데이트 그래프를 다운로드하려면 다음 명령을 사용하십시오.

        $ curl -s https://api.openshift.com/api/upgrades_info/v1/graph?channel=stable-4.14 -o ~/upgrade-graph_stable-4.14
  • Operator를 업데이트하려면 다음 작업을 수행해야 합니다.

    • Operator 카탈로그를 미러링합니다. "연결이 끊긴 클러스터에 사용하기 위해 Operator 카탈로그 미러링" 섹션의 절차에 따라 원하는 Operator 이미지가 미러링되었는지 확인합니다.

추가 리소스

18.12.1.2. 플랫폼 업데이트 수행

TALM으로 플랫폼 업데이트를 수행할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • GitOps Zero Touch Provisioning (ZTP)을 최신 버전으로 업데이트합니다.
  • GitOps ZTP를 사용하여 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • 원하는 이미지 저장소를 미러링합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

프로세스

  1. 플랫폼 업데이트에 대한 PolicyGenTemplate CR을 생성합니다.

    1. PolicyGenTemplate CR의 다음 내용을 du-upgrade.yaml 파일에 저장합니다.

      플랫폼 업데이트를 위한 PolicyGenTemplate

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
          - fileName: ImageSignature.yaml 1
            policyName: "platform-upgrade-prep"
            binaryData:
              ${DIGEST_ALGO}-${DIGEST_ENCODED}: ${SIGNATURE_BASE64} 2
          - fileName: DisconnectedICSP.yaml
            policyName: "platform-upgrade-prep"
            metadata:
              name: disconnected-internal-icsp-for-ocp
            spec:
              repositoryDigestMirrors: 3
                - mirrors:
                  - quay-intern.example.com/ocp4/openshift-release-dev
                  source: quay.io/openshift-release-dev/ocp-release
                - mirrors:
                  - quay-intern.example.com/ocp4/openshift-release-dev
                  source: quay.io/openshift-release-dev/ocp-v4.0-art-dev
          - fileName: ClusterVersion.yaml 4
            policyName: "platform-upgrade"
            metadata:
              name: version
            spec:
              channel: "stable-4.14"
              upstream: http://upgrade.example.com/images/upgrade-graph_stable-4.14
              desiredUpdate:
                version: 4.14.4
            status:
              history:
                - version: 4.14.4
                  state: "Completed"

      1
      ConfigMap CR에는 업데이트할 원하는 릴리스 이미지의 서명이 포함되어 있습니다.
      2
      원하는 OpenShift Container Platform 릴리스의 이미지 서명을 표시합니다. "환경 설정" 섹션의 절차에 따라 저장한 checksum-${OCP_RELEASE_NUMBER}.yaml 파일에서 서명을 가져옵니다.
      3
      원하는 OpenShift Container Platform 이미지가 포함된 미러 저장소를 표시합니다. "환경 설정" 섹션의 절차를 따를 때 저장한 imageContentSources.yaml 파일에서 미러를 가져옵니다.
      4
      업데이트를 트리거할 ClusterVersion CR을 표시합니다. 채널,업스트림desiredVersion 필드는 모두 이미지 사전 캐싱에 필요합니다.

      PolicyGenTemplate CR은 다음 두 가지 정책을 생성합니다.

      • du-upgrade-platform-prep 정책은 플랫폼 업데이트에 대한 준비 작업을 수행합니다. 원하는 릴리스 이미지 서명에 대한 ConfigMap CR을 생성하고 미러링된 릴리스 이미지 저장소의 이미지 콘텐츠 소스를 생성하고, 원하는 업데이트 채널 및 연결이 끊긴 환경에서 관리 클러스터에서 연결할 수 있는 업데이트 그래프로 클러스터 버전을 업데이트합니다.
      • du-upgrade-platform-upgrade 정책은 플랫폼 업그레이드를 수행하는 데 사용됩니다.
    2. PolicyGenTemplate CR의 GitOps ZTP Git 리포지토리에 있는 kustomization.yaml 파일에 du-upgrade.yaml 파일 내용을 추가하고 Git 리포지토리로 변경 사항을 내보냅니다.

      rgocd는 Git 리포지토리에서 변경 사항을 가져와서 hub 클러스터에 정책을 생성합니다.

    3. 다음 명령을 실행하여 생성된 정책을 확인합니다.

      $ oc get policies -A | grep platform-upgrade
  2. spec.enable 필드가 false 로 설정된 상태에서 플랫폼 업데이트에 대한 ClusterGroupUpdate CR을 생성합니다.

    1. du-upgrade-platform-upgrade - prep 및 du-upgrade-platform-upgrade 정책 및 대상 클러스터를 다음 예와 같이 cgu-platform-upgrade.yml 파일에 사용하여 플랫폼 업데이트 ClusterGroupUpdate CR의 콘텐츠를 저장합니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade-prep
        - du-upgrade-platform-upgrade
        preCaching: false
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: false
    2. 다음 명령을 실행하여 Hub 클러스터에 ClusterGroupUpdate CR을 적용합니다.

      $ oc apply -f cgu-platform-upgrade.yml
  3. 선택 사항: 플랫폼 업데이트의 이미지를 사전 캐시합니다.

    1. 다음 명령을 실행하여 ClusterGroupUpdate CR에서 사전 캐싱을 활성화합니다.

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    2. 업데이트 프로세스를 모니터링하고 사전 캐싱이 완료될 때까지 기다립니다. hub 클러스터에서 다음 명령을 실행하여 사전 캐싱 상태를 확인합니다.

      $ oc get cgu cgu-platform-upgrade -o jsonpath='{.status.precaching.status}'
  4. 플랫폼 업데이트를 시작합니다.

    1. 다음 명령을 실행하여 cgu-platform-upgrade 정책을 활성화하고 사전 캐싱을 비활성화합니다.

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-platform-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.

      $ oc get policies --all-namespaces

추가 리소스

  • 연결이 끊긴 환경에서 이미지 미러링에 대한 자세한 내용은 연결이 끊긴 환경 준비를 참조하십시오.
18.12.1.3. Operator 업데이트 수행

TALM을 사용하여 Operator 업데이트를 수행할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • GitOps Zero Touch Provisioning (ZTP)을 최신 버전으로 업데이트합니다.
  • GitOps ZTP를 사용하여 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • 번들 이미지에서 참조하는 원하는 인덱스 이미지, 번들 이미지 및 모든 Operator 이미지를 미러링합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

프로세스

  1. Operator 업데이트의 PolicyGenTemplate CR을 업데이트합니다.

    1. du-upgrade.yaml 파일의 다음과 같은 추가 콘텐츠를 사용하여 du-upgrade PolicyGenTemplate CR을 업데이트합니다.

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
          - fileName: DefaultCatsrc.yaml
            remediationAction: inform
            policyName: "operator-catsrc-policy"
            metadata:
              name: redhat-operators-disconnected
            spec:
              displayName: Red Hat Operators Catalog
              image: registry.example.com:5000/olm/redhat-operators-disconnected:v4.14 1
              updateStrategy: 2
                registryPoll:
                  interval: 1h
            status:
              connectionState:
                  lastObservedState: READY 3
      1
      인덱스 이미지 URL에는 원하는 Operator 이미지가 포함되어 있습니다. 인덱스 이미지가 항상 동일한 이미지 이름 및 태그로 푸시되는 경우 이 변경이 필요하지 않습니다.
      2
      OLM(Operator Lifecycle Manager)에서 registryPoll.interval 필드를 사용하여 새 Operator 버전의 인덱스 이미지를 폴링하는 빈도를 설정합니다. 이 변경 사항은 y-stream 및 z-stream Operator 업데이트를 위해 새 인덱스 이미지 태그가 항상 푸시되는 경우 필요하지 않습니다. registryPoll.interval 필드는 업데이트를 신속하게 처리하기 위해 더 짧은 간격으로 설정할 수 있지만 더 짧은 간격은 계산 부하를 늘리십시오. 이 문제를 대응하려면 업데이트가 완료되면 registryPoll.interval 을 기본값으로 복원할 수 있습니다.
      3
      카탈로그 연결의 마지막으로 관찰된 상태입니다. READY 값을 사용하면 CatalogSource 정책이 준비되어 인덱스 Pod를 가져와 실행 중임을 나타냅니다. 이렇게 하면 TALM이 최신 정책 준수 상태를 기반으로 Operator를 업그레이드합니다.
    2. 이번 업데이트에서는 원하는 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-policydu-upgrade-subscriptions-fec-policy: 두 가지 정책을 생성합니다.

      apiVersion: ran.openshift.io/v1
      kind: PolicyGenTemplate
      metadata:
        name: "du-upgrade"
        namespace: "ztp-group-du-sno"
      spec:
        bindingRules:
          group-du-sno: ""
        mcp: "master"
        remediationAction: inform
        sourceFiles:
             …
          - fileName: DefaultCatsrc.yaml
            remediationAction: inform
            policyName: "fec-catsrc-policy"
            metadata:
              name: certified-operators
            spec:
              displayName: Intel SRIOV-FEC Operator
              image: registry.example.com:5000/olm/far-edge-sriov-fec:v4.10
              updateStrategy:
                registryPoll:
                  interval: 10m
          - fileName: AcceleratorsSubscription.yaml
            policyName: "subscriptions-fec-policy"
            spec:
              channel: "stable"
              source: certified-operators
    3. Common PolicyGenTemplate CR이 있는 경우 지정된 서브스크립션 채널을 제거합니다. GitOps ZTP 이미지의 기본 서브스크립션 채널은 업데이트에 사용됩니다.

      참고

      GitOps ZTP 4.14를 통해 적용되는 Operator의 기본 채널은 performance-addon-operator 를 제외하고 안정적입니다. OpenShift Container Platform 4.11부터 performance-addon-operator 기능이 node-tuning-operator 로 이동되었습니다. 4.10 릴리스의 경우 PAO의 기본 채널은 v4.10 입니다. 공통 PolicyGenTemplate CR에서 기본 채널을 지정할 수도 있습니다.

    4. PolicyGenTemplate CR 업데이트를 GitOps ZTP Git 리포지토리로 내보냅니다.

      rgocd는 Git 리포지토리에서 변경 사항을 가져와서 hub 클러스터에 정책을 생성합니다.

    5. 다음 명령을 실행하여 생성된 정책을 확인합니다.

      $ oc get policies -A | grep -E "catsrc-policy|subscription"
  2. Operator 업데이트를 시작하기 전에 필요한 카탈로그 소스 업데이트를 적용합니다.

    1. 카탈로그 소스 정책 및 대상 관리 클러스터를 cgu- operator-upgrade-prep 파일에 사용하여 operator-upgrade-prep라는 ClusterGroupUpgrade CR의 콘텐츠를 저장합니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-operator-upgrade-prep
        namespace: default
      spec:
        clusters:
        - spoke1
        enable: true
        managedPolicies:
        - du-upgrade-operator-catsrc-policy
        remediationStrategy:
          maxConcurrency: 1
    2. 다음 명령을 실행하여 허브 클러스터에 정책을 적용합니다.

      $ oc apply -f cgu-operator-upgrade-prep.yml
    3. 업데이트 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.

      $ oc get policies -A | grep -E "catsrc-policy"
  3. spec.enable 필드를 false 로 설정하여 Operator 업데이트에 대한 ClusterGroupUpgrade CR을 생성합니다.

    1. 다음 예와 같이 Operator 업데이트 ClusterGroupUpgrade CR의 콘텐츠를 du-upgrade-operator-catsrc-policy 정책 및 공통 PolicyGenTemplate 에서 생성한 서브스크립션 정책과 대상 클러스터에서 cgu-operator-upgrade.yml 파일에 저장합니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-operator-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-operator-catsrc-policy 1
        - common-subscriptions-policy 2
        preCaching: false
        clusters:
        - spoke1
        remediationStrategy:
          maxConcurrency: 1
        enable: false
      1
      이 정책은 카탈로그 소스에서 Operator 이미지를 검색하려면 이미지 사전 캐싱 기능에 필요합니다.
      2
      정책에는 Operator 서브스크립션이 포함되어 있습니다. 참조 PolicyGenTemplates 의 구조와 내용을 따르는 경우 모든 Operator 서브스크립션이 common-subscriptions-policy 정책으로 그룹화됩니다.
      참고

      하나의 ClusterGroupUpgrade CR은 ClusterGroupUpgrade CR에 포함된 하나의 카탈로그 소스에서 서브스크립션 정책에 정의된 Operator의 이미지만 사전 캐시할 수 있습니다. SRIOV-FEC Operator의 예와 같이 원하는 Operator가 다양한 카탈로그 소스의 경우 SRIOV-FEC Operator 이미지에 대한 du-upgrade-fec-catsrc-policydu-upgrade-subscriptions-fec-policy 정책을 사용하여 다른 ClusterGroupUpgrade CR을 생성해야 합니다.

    2. 다음 명령을 실행하여 hub 클러스터에 ClusterGroupUpgrade CR을 적용합니다.

      $ oc apply -f cgu-operator-upgrade.yml
  4. 선택 사항: Operator 업데이트의 이미지를 사전 캐시합니다.

    1. 이미지 사전 캐싱을 시작하기 전에 다음 명령을 실행하여 서브스크립션 정책이 이 시점에서 NonCompliant 인지 확인합니다.

      $ oc get policy common-subscriptions-policy -n <policy_namespace>

      출력 예

      NAME                          REMEDIATION ACTION   COMPLIANCE STATE     AGE
      common-subscriptions-policy   inform               NonCompliant         27d

    2. 다음 명령을 실행하여 ClusterGroupUpgrade CR에서 pre-caching을 활성화합니다.

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    3. 프로세스를 모니터링하고 사전 캐싱이 완료될 때까지 기다립니다. 관리 클러스터에서 다음 명령을 실행하여 사전 캐싱 상태를 확인합니다.

      $ oc get cgu cgu-operator-upgrade -o jsonpath='{.status.precaching.status}'
    4. 다음 명령을 실행하여 업데이트를 시작하기 전에 사전 캐싱이 완료되었는지 확인합니다.

      $ oc get cgu -n default cgu-operator-upgrade -ojsonpath='{.status.conditions}' | jq

      출력 예

      [
          {
            "lastTransitionTime": "2022-03-08T20:49:08.000Z",
            "message": "The ClusterGroupUpgrade CR is not enabled",
            "reason": "UpgradeNotStarted",
            "status": "False",
            "type": "Ready"
          },
          {
            "lastTransitionTime": "2022-03-08T20:55:30.000Z",
            "message": "Precaching is completed",
            "reason": "PrecachingCompleted",
            "status": "True",
            "type": "PrecachingDone"
          }
      ]

  5. Operator 업데이트를 시작합니다.

    1. cgu-operator-upgrade ClusterGroupUpgrade CR을 활성화하고 다음 명령을 실행하여 Operator 업데이트를 시작하도록 사전 캐싱을 비활성화합니다.

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-operator-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.

      $ oc get policies --all-namespaces

추가 리소스

18.12.1.3.1. 최신 정책 준수 상태로 인해 누락된 Operator 업데이트 문제 해결

일부 시나리오에서는 TALM( Topology Aware Lifecycle Manager)에서 최신 정책 준수 상태로 인해 Operator 업데이트가 누락될 수 있습니다.

카탈로그 소스 업데이트 후 OLM(Operator Lifecycle Manager)에서 서브스크립션 상태를 업데이트하는 데 시간이 걸립니다. TALM에서 수정이 필요한지 여부를 결정하는 동안 서브스크립션 정책의 상태가 계속 준수로 표시될 수 있습니다. 결과적으로 서브스크립션 정책에 지정된 Operator가 업그레이드되지 않습니다.

이 시나리오를 방지하려면 PolicyGenTemplate 에 다른 카탈로그 소스 구성을 추가하고 업데이트가 필요한 Operator의 서브스크립션에 이 구성을 지정합니다.

프로세스

  1. PolicyGenTemplate 리소스에 카탈로그 소스 구성을 추가합니다.

    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          metadata:
            name: redhat-operators-disconnected
          spec:
            displayName: Red Hat Operators Catalog
            image: registry.example.com:5000/olm/redhat-operators-disconnected:v{product-version}
            updateStrategy:
              registryPoll:
                interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    - fileName: DefaultCatsrc.yaml
          remediationAction: inform
          policyName: "operator-catsrc-policy"
          metadata:
            name: redhat-operators-disconnected-v2 1
          spec:
            displayName: Red Hat Operators Catalog v2 2
            image: registry.example.com:5000/olm/redhat-operators-disconnected:<version> 3
            updateStrategy:
              registryPoll:
                interval: 1h
          status:
            connectionState:
                lastObservedState: READY
    1
    새 구성의 이름을 업데이트합니다.
    2
    새 구성의 표시 이름을 업데이트합니다.
    3
    인덱스 이미지 URL을 업데이트합니다. 이 fileName.spec.image 필드는 DefaultCatsrc.yaml 파일의 구성을 재정의합니다.
  2. 업데이트가 필요한 Operator의 새 구성을 가리키도록 Subscription 리소스를 업데이트합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: operator-subscription
      namespace: operator-namspace
    # ...
    spec:
      source: redhat-operators-disconnected-v2 1
    # ...
    1
    PolicyGenTemplate 리소스에 정의된 추가 카탈로그 소스 구성의 이름을 입력합니다.
18.12.1.4. 플랫폼 및 Operator 업데이트를 함께 수행

플랫폼 및 Operator 업데이트를 동시에 수행할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 Aware Lifecycle Manager)을 설치합니다.
  • GitOps Zero Touch Provisioning (ZTP)을 최신 버전으로 업데이트합니다.
  • GitOps ZTP를 사용하여 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

프로세스

  1. "플랫폼 업데이트 수행" 및 "Operator 업데이트 수행" 섹션에 설명된 단계에 따라 업데이트에 대한 PolicyGenTemplate CR을 생성합니다.
  2. 플랫폼 및 Operator 업데이트에 대한 prep 작업을 적용합니다.

    1. 플랫폼 업데이트 준비 작업, 카탈로그 소스 업데이트 및 대상 클러스터에 대한 정책을 사용하여 ClusterGroupUpgrade CR의 콘텐츠를 cgu-platform-operator-upgrade-prep.yml 파일에 저장합니다. 예를 들면 다음과 같습니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-platform-operator-upgrade-prep
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade-prep
        - du-upgrade-operator-catsrc-policy
        clusterSelector:
        - group-du-sno
        remediationStrategy:
          maxConcurrency: 10
        enable: true
    2. 다음 명령을 실행하여 cgu-platform-operator-upgrade-prep.yml 파일을 hub 클러스터에 적용합니다.

      $ oc apply -f cgu-platform-operator-upgrade-prep.yml
    3. 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.

      $ oc get policies --all-namespaces
  3. 플랫폼에 대한 ClusterGroupUpdate CR을 생성하고 spec.enable 필드를 false 로 설정하여 Operator를 업데이트합니다.

    1. 다음 예와 같이 플랫폼 및 Operator의 콘텐츠를 정책 및 대상 클러스터를 사용하여 cgu-platform-operator-upgrade.yml 파일에 저장합니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: cgu-du-upgrade
        namespace: default
      spec:
        managedPolicies:
        - du-upgrade-platform-upgrade 1
        - du-upgrade-operator-catsrc-policy 2
        - common-subscriptions-policy 3
        preCaching: true
        clusterSelector:
        - group-du-sno
        remediationStrategy:
          maxConcurrency: 1
        enable: false
      1
      이는 플랫폼 업데이트 정책입니다.
      2
      이는 Operator를 업데이트할 카탈로그 소스 정보가 포함된 정책입니다. 관리 클러스터로 다운로드할 Operator 이미지를 결정하는 데 사전 캐싱 기능이 필요합니다.
      3
      Operator를 업데이트하는 정책입니다.
    2. 다음 명령을 실행하여 cgu-platform-operator-upgrade.yml 파일을 hub 클러스터에 적용합니다.

      $ oc apply -f cgu-platform-operator-upgrade.yml
  4. 선택 사항: 플랫폼 및 Operator 업데이트의 이미지를 사전 캐시합니다.

    1. 다음 명령을 실행하여 ClusterGroupUpgrade CR에서 pre-caching을 활성화합니다.

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
      --patch '{"spec":{"preCaching": true}}' --type=merge
    2. 업데이트 프로세스를 모니터링하고 사전 캐싱이 완료될 때까지 기다립니다. 관리 클러스터에서 다음 명령을 실행하여 사전 캐싱 상태를 확인합니다.

      $ oc get jobs,pods -n openshift-talm-pre-cache
    3. 다음 명령을 실행하여 업데이트를 시작하기 전에 사전 캐싱이 완료되었는지 확인합니다.

      $ oc get cgu cgu-du-upgrade -ojsonpath='{.status.conditions}'
  5. 플랫폼 및 Operator 업데이트를 시작합니다.

    1. 다음 명령을 실행하여 cgu-du-upgrade ClusterGroupUpgrade CR을 활성화하여 플랫폼 및 Operator 업데이트를 시작합니다.

      $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-du-upgrade \
      --patch '{"spec":{"enable":true, "preCaching": false}}' --type=merge
    2. 프로세스를 모니터링합니다. 완료되면 다음 명령을 실행하여 정책을 준수하는지 확인합니다.

      $ oc get policies --all-namespaces
      참고

      플랫폼 및 Operator 업데이트의 CR은 설정을 spec.enable: true 로 구성하여 처음부터 생성할 수 있습니다. 이 경우 업데이트는 사전 캐싱이 완료된 직후 시작되어 CR을 수동으로 활성화할 필요가 없습니다.

      사전 캐싱과 업데이트 모두 정책, 배치 바인딩, 배치 규칙, 관리 클러스터 작업 및 관리 클러스터 뷰와 같은 추가 리소스를 생성하여 절차를 완료하는 데 도움이 됩니다. afterCompletion.deleteObjects 필드를 true 로 설정하면 업데이트가 완료된 후 이러한 리소스가 모두 삭제됩니다.

18.12.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 권한이 있는 사용자로 로그인합니다.

프로세스

  1. common-ranGen.yaml 파일에서 Performance Addon Operator 네임스페이스, Operator group 및 서브스크립션에 대해 complianceTypemustnothave 로 변경합니다.

     -  fileName: PaoSubscriptionNS.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
     -  fileName: PaoSubscriptionOperGroup.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
     -  fileName: PaoSubscription.yaml
        policyName: "subscriptions-policy"
        complianceType: mustnothave
  2. 사용자 정의 사이트 리포지토리와 변경 사항을 병합하고 ArgoCD 애플리케이션이 변경 사항을 허브 클러스터에 동기화할 때까지 기다립니다. common-subscriptions-policy 정책의 상태는 비준 .
  3. 토폴로지 Aware Lifecycle Manager를 사용하여 대상 클러스터에 변경 사항을 적용합니다. 구성 변경 사항 롤아웃에 대한 자세한 내용은 "추가 리소스" 섹션을 참조하십시오.
  4. 프로세스를 모니터링합니다. 대상 클러스터의 common-subscriptions-policy 정책이 Compliant 인 경우 Performance Addon Operator가 클러스터에서 제거되었습니다. 다음 명령을 실행하여 common-subscriptions-policy 의 상태를 가져옵니다.

    $ oc get policy -n ztp-common common-subscriptions-policy
  5. common-ranGen.yaml 파일의 .spec.sourceFiles 에서 Performance Addon Operator 네임스페이스, Operator group 및 서브스크립션 CR을 삭제합니다.
  6. 사용자 정의 사이트 리포지토리와 변경 사항을 병합하고 ArgoCD 애플리케이션이 변경 사항을 허브 클러스터에 동기화할 때까지 기다립니다. 정책은 그대로 유지됩니다.
18.12.1.6. 단일 노드 OpenShift 클러스터에서 TALM을 사용하여 사용자 지정 이미지 미리 캐싱

애플리케이션을 업그레이드하기 전에 단일 노드 OpenShift 클러스터에서 애플리케이션별 워크로드 이미지를 사전 캐시할 수 있습니다.

다음 CR(사용자 정의 리소스)을 사용하여 사전 캐싱 작업에 대한 구성 옵션을 지정할 수 있습니다.

  • PreCachingConfig CR
  • ClusterGroupUpgrade CR
참고

PreCachingConfig CR의 모든 필드는 선택 사항입니다.

PreCachingConfig CR의 예

apiVersion: ran.openshift.io/v1alpha1
kind: PreCachingConfig
metadata:
  name: exampleconfig
  namespace: exampleconfig-ns
spec:
  overrides: 1
    platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
    operatorsIndexes:
      - registry.example.com:5000/custom-redhat-operators:1.0.0
    operatorsPackagesAndChannels:
      - local-storage-operator: stable
      - ptp-operator: stable
      - sriov-network-operator: stable
  spaceRequired: 30 Gi 2
  excludePrecachePatterns: 3
    - aws
    - vsphere
  additionalImages: 4
    - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
    - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
    - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09

1
기본적으로 TALM은 관리 클러스터 정책에서 platformImage,operatorsIndexesoperatorsPackagesAndChannels 필드를 자동으로 채웁니다. 이러한 필드의 기본 TALM 파생 값을 재정의하는 값을 지정할 수 있습니다.
2
클러스터에서 필요한 최소 디스크 공간을 지정합니다. 지정되지 않은 경우 TALM은 OpenShift Container Platform 이미지의 기본값을 정의합니다. 디스크 공간 필드에는 정수 값과 스토리지 유닛이 포함되어야 합니다. 예: 40GiB,200MB,1TiB.
3
일치하는 이미지 이름에 따라 사전 캐싱에서 제외할 이미지를 지정합니다.
4
사전 캐시할 추가 이미지 목록을 지정합니다.

PreCachingConfig CR 참조가 있는 ClusterGroupUpgrade CR의 예

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu
spec:
  preCaching: true 1
  preCachingConfigRef:
    name: exampleconfig 2
    namespace: exampleconfig-ns 3

1
true 로 설정된 preCaching 필드는 사전 캐싱 작업을 활성화합니다.
2
preCachingConfigRef.name 필드는 사용하려는 PreCachingConfig CR을 지정합니다.
3
preCachingConfigRef.namespace 는 사용하려는 PreCachingConfig CR의 네임스페이스를 지정합니다.
18.12.1.6.1. 사전 캐싱을 위한 사용자 정의 리소스 생성

ClusterGroupUpgrade CR 전에 PreCachingConfig CR을 생성해야 합니다.

  1. 사전 캐시하려는 추가 이미지 목록을 사용하여 PreCachingConfig CR을 생성합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: PreCachingConfig
    metadata:
      name: exampleconfig
      namespace: default 1
    spec:
    [...]
      spaceRequired: 30Gi 2
      additionalImages:
        - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
        - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
        - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
    1
    hub 클러스터에서 네임스페이스에 액세스할 수 있어야 합니다.
    2
    사전 캐시된 이미지에 충분한 스토리지 공간이 있는지 확인하기 위해 필요한 최소 디스크 공간 필드를 설정하는 것이 좋습니다.
  2. preCaching 필드를 true 로 설정하여 ClusterGroupUpgrade CR을 생성하고 이전 단계에서 생성한 PreCachingConfig CR을 지정합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu
      namespace: default
    spec:
      clusters:
      - sno1
      - sno2
      preCaching: true
      preCachingConfigRef:
      - name: exampleconfig
        namespace: default
      managedPolicies:
        - du-upgrade-platform-upgrade
        - du-upgrade-operator-catsrc-policy
        - common-subscriptions-policy
      remediationStrategy:
        timeout: 240
    주의

    클러스터에 이미지를 설치한 후에는 변경하거나 삭제할 수 없습니다.

  3. 이미지를 사전 캐싱하려면 다음 명령을 실행하여 ClusterGroupUpgrade CR을 적용합니다.

    $ oc apply -f cgu.yaml

TALM은 ClusterGroupUpgrade CR을 확인합니다.

이 시점에서 TALM 사전 캐싱 워크플로우를 계속 사용할 수 있습니다.

참고

모든 사이트는 동시에 사전 캐시됩니다.

검증

  1. 다음 명령을 실행하여 ClusterUpgradeGroup CR이 적용되는 hub 클러스터에서 사전 캐싱 상태를 확인합니다.

    $ oc get cgu <cgu_name> -n <cgu_namespace> -oyaml

    출력 예

      precaching:
        spec:
          platformImage: quay.io/openshift-release-dev/ocp-release@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
          operatorsIndexes:
            - registry.example.com:5000/custom-redhat-operators:1.0.0
          operatorsPackagesAndChannels:
            - local-storage-operator: stable
            - ptp-operator: stable
            - sriov-network-operator: stable
          excludePrecachePatterns:
            - aws
            - vsphere
          additionalImages:
            - quay.io/exampleconfig/application1@sha256:3d5800990dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47e2e1ef
            - quay.io/exampleconfig/application2@sha256:3d5800123dee7cd4727d3fe238a97e2d2976d3808fc925ada29c559a47adfaef
            - quay.io/exampleconfig/applicationN@sha256:4fe1334adfafadsf987123adfffdaf1243340adfafdedga0991234afdadfsa09
          spaceRequired: "30"
        status:
          sno1: Starting
          sno2: Starting

    관리 정책이 있는지 확인하여 사전 캐싱 구성의 유효성을 검사합니다. ClusterGroupUpgradePreCachingConfig CR의 유효한 구성으로 인해 다음과 같은 상태가 발생합니다.

    유효한 CR의 출력 예

    - lastTransitionTime: "2023-01-01T00:00:01Z"
      message: All selected clusters are valid
      reason: ClusterSelectionCompleted
      status: "True"
      type: ClusterSelected
    - lastTransitionTime: "2023-01-01T00:00:02Z"
      message: Completed validation
      reason: ValidationCompleted
      status: "True"
      type: Validated
    - lastTransitionTime: "2023-01-01T00:00:03Z"
      message: Precaching spec is valid and consistent
      reason: PrecacheSpecIsWellFormed
      status: "True"
      type: PrecacheSpecValid
    - lastTransitionTime: "2023-01-01T00:00:04Z"
      message: Precaching in progress for 1 clusters
      reason: InProgress
      status: "False"
      type: PrecachingSucceeded

    잘못된 PreCachingConfig CR의 예

    Type:    "PrecacheSpecValid"
    Status:  False,
    Reason:  "PrecacheSpecIncomplete"
    Message: "Precaching spec is incomplete: failed to get PreCachingConfig resource due to PreCachingConfig.ran.openshift.io "<pre-caching_cr_name>" not found"

  2. 관리 클러스터에서 다음 명령을 실행하여 사전 캐싱 작업을 찾을 수 있습니다.

    $ oc get jobs -n openshift-talo-pre-cache

    진행 중인 사전 캐싱 작업 예

    NAME        COMPLETIONS       DURATION      AGE
    pre-cache   0/1               1s            1s

  3. 다음 명령을 실행하여 사전 캐싱 작업에 대해 생성된 Pod의 상태를 확인할 수 있습니다.

    $ oc describe pod pre-cache -n openshift-talo-pre-cache

    진행 중인 사전 캐싱 작업 예

    Type        Reason              Age    From              Message
    Normal      SuccesfulCreate     19s    job-controller    Created pod: pre-cache-abcd1

  4. 다음 명령을 실행하여 작업 상태에 대한 실시간 업데이트를 가져올 수 있습니다.

    $ oc logs -f pre-cache-abcd1 -n openshift-talo-pre-cache
  5. 사전 캐시 작업이 성공적으로 완료되었는지 확인하려면 다음 명령을 실행합니다.

    $ oc describe pod pre-cache -n openshift-talo-pre-cache

    완료된 사전 캐시 작업의 예

    Type        Reason              Age    From              Message
    Normal      SuccesfulCreate     5m19s  job-controller    Created pod: pre-cache-abcd1
    Normal      Completed           19s    job-controller    Job completed

  6. 단일 노드 OpenShift에서 이미지가 성공적으로 사전 캐시되었는지 확인하려면 다음을 수행하십시오.

    1. 디버그 모드에서 노드로 들어갑니다.

      $ oc debug node/cnfdf00.example.lab
    2. root를 호스트로 변경 :

      $ chroot /host/
    3. 원하는 이미지를 검색합니다.

      $ sudo podman images | grep <operator_name>

추가 리소스

18.12.2. GitOps ZTP의 자동 생성 ClusterGroupUpgrade CR 정보

TALM에는 hub 클러스터에서 ManagedCluster CR의 Ready 상태를 모니터링하고 GitOps Zero Touch Provisioning (ZTP)에 대한 ClusterGroupUpgrade CR을 생성하는 ManagedClusterForCGU 라는 컨트롤러가 있습니다.

ztp-done 레이블이 적용되지 않은 Ready 상태의 관리형 클러스터의 경우 ManagedClusterForCGU 컨트롤러는 GitOps ZTP 프로세스 중에 생성되는 관련 RHACM 정책을 사용하여 ztp-install 네임스페이스에 ClusterGroupUpgrade CR을 자동으로 생성합니다. 그런 다음 TALM은 자동 생성된 ClusterGroupUpgrade CR에 나열된 구성 정책 세트를 수정하여 구성 CR을 관리 클러스터로 푸시합니다.

클러스터가 Ready 상태가 되는 시점에 관리 클러스터에 대한 정책이 없는 경우 정책이 생성되지 않은 ClusterGroupUpgrade CR이 생성됩니다. ClusterGroupUpgrade 가 완료되면 관리형 클러스터는 ztp-done 로 레이블이 지정됩니다. 해당 관리 클러스터에 적용하려는 정책이 있는 경우 2일 차 작업으로 ClusterGroupUpgrade 를 수동으로 생성합니다.

GitOps ZTP의 자동 생성 ClusterGroupUpgrade CR의 예

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  generation: 1
  name: spoke1
  namespace: ztp-install
  ownerReferences:
  - apiVersion: cluster.open-cluster-management.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: ManagedCluster
    name: spoke1
    uid: 98fdb9b2-51ee-4ee7-8f57-a84f7f35b9d5
  resourceVersion: "46666836"
  uid: b8be9cd2-764f-4a62-87d6-6b767852c7da
spec:
  actions:
    afterCompletion:
      addClusterLabels:
        ztp-done: "" 1
      deleteClusterLabels:
        ztp-running: ""
      deleteObjects: true
    beforeEnable:
      addClusterLabels:
        ztp-running: "" 2
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - common-spoke1-config-policy
  - common-spoke1-subscriptions-policy
  - group-spoke1-config-policy
  - spoke1-config-policy
  - group-spoke1-validator-du-policy
  preCaching: false
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240

1
TALM이 클러스터 구성을 완료할 때 관리 클러스터에 적용됩니다.
2
TALM이 구성 정책 배포를 시작할 때 관리 클러스터에 적용됩니다.

18.13. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터 확장

ZTP(ZTP)를 사용하여 단일 노드 OpenShift 클러스터를 확장할 수 있습니다. 단일 노드 OpenShift 클러스터에 작업자 노드를 추가하면 원래 단일 노드 OpenShift 클러스터는 컨트롤 플레인 노드 역할을 유지합니다. 작업자 노드를 추가하는 경우 기존 단일 노드 OpenShift 클러스터에 대한 다운타임이 필요하지 않습니다.

참고

단일 노드 OpenShift 클러스터에 추가할 수 있는 작업자 노드 수에 지정된 제한이 없지만 추가 작업자 노드의 컨트롤 플레인 노드에서 예약된 CPU 할당을 다시 평가해야 합니다.

작업자 노드에 워크로드 파티셔닝이 필요한 경우 노드를 설치하기 전에 허브 클러스터에서 관리형 클러스터 정책을 배포하고 수정해야 합니다. 이렇게 하면 GitOps ZTP 워크플로우가 MachineConfig ignition 파일을 작업자 노드에 적용하기 전에 워크로드 파티셔닝 MachineConfig 오브젝트가 렌더링되고 작업자 머신 구성 풀과 연결됩니다.

먼저 정책을 수정한 다음 작업자 노드를 설치하는 것이 좋습니다. 작업자 노드를 설치한 후 워크로드 파티셔닝 매니페스트를 생성하는 경우 노드를 수동으로 드레이닝하고 데몬 세트에서 관리하는 모든 Pod를 삭제해야 합니다. 관리 데몬 세트에서 새 Pod를 생성하면 새 Pod에 워크로드 파티션 프로세스가 수행됩니다.

중요

GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드를 추가하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

추가 리소스

18.13.1. 작업자 노드에 프로필 적용

DU 프로필을 사용하여 추가 작업자 노드를 구성할 수 있습니다.

ZTP(ZTP) 공통, 그룹 및 사이트별 PolicyGenTemplate 리소스를 사용하여 작업자 노드 클러스터에 DU(RAN 분산 단위) 프로필을 적용할 수 있습니다. 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을 생성해야 합니다.

18.13.2. (선택 사항) PTP 및 SR-IOV 데몬 선택기 호환성 활성화

ZTP(ZTP) 플러그인 버전 4.11 이상을 사용하여 DU 프로필을 배포한 경우 master 로 표시된 노드에만 데몬을 배치하도록 PTP 및 SR-IOV Operator를 구성할 수 있습니다. 이 구성으로 인해 PTP 및 SR-IOV 데몬이 작업자 노드에서 작동하지 않습니다. 시스템에 PTP 및 SR-IOV 데몬 노드 선택기가 잘못 구성된 경우 작업자 DU 프로필 구성을 진행하기 전에 데몬을 변경해야 합니다.

프로세스

  1. spoke 클러스터 중 하나에서 PTP Operator의 데몬 노드 선택기 설정을 확인합니다.

    $ oc get ptpoperatorconfig/default -n openshift-ptp -ojsonpath='{.spec}' | jq

    PTP Operator의 출력 예

    {"daemonNodeSelector":{"node-role.kubernetes.io/master":""}} 1

    1
    노드 선택기를 master 로 설정하면 변경 사항이 필요한 GitOps ZTP 플러그인 버전과 함께 spoke가 배포되었습니다.
  2. spoke 클러스터 중 하나에서 SR-IOV Operator의 데몬 노드 선택기 설정을 확인합니다.

    $  oc get sriovoperatorconfig/default -n \
    openshift-sriov-network-operator -ojsonpath='{.spec}' | jq

    SR-IOV Operator의 출력 예

    {"configDaemonNodeSelector":{"node-role.kubernetes.io/worker":""},"disableDrain":false,"enableInjector":true,"enableOperatorWebhook":true} 1

    1
    노드 선택기를 master 로 설정하면 변경 사항이 필요한 GitOps ZTP 플러그인 버전과 함께 spoke가 배포되었습니다.
  3. 그룹 정책에서 다음 complianceTypespec 항목을 추가합니다.

    spec:
        - fileName: PtpOperatorConfig.yaml
          policyName: "config-policy"
          complianceType: mustonlyhave
          spec:
            daemonNodeSelector:
              node-role.kubernetes.io/worker: ""
        - fileName: SriovOperatorConfig.yaml
          policyName: "config-policy"
          complianceType: mustonlyhave
          spec:
            configDaemonNodeSelector:
              node-role.kubernetes.io/worker: ""
    중요

    daemonNodeSelector 필드를 변경하면 임시 PTP 동기화 손실 및 SR-IOV 연결이 손실됩니다.

  4. Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

18.13.3. PTP 및 SR-IOV 노드 선택기 호환성

PTP 구성 리소스 및 SR-IOV 네트워크 노드 정책은 node-role.kubernetes.io/master: "" 를 노드 선택기로 사용합니다. 추가 작업자 노드에 컨트롤 플레인 노드와 동일한 NIC 구성이 있는 경우 컨트롤 플레인 노드를 구성하는 데 사용되는 정책을 작업자 노드에 재사용할 수 있습니다. 그러나 "node-role.kubernetes.io/worker" 레이블과 같이 두 노드 유형을 모두 선택하도록 노드 선택기를 변경해야 합니다.

18.13.4. PolicyGenTemplate CR을 사용하여 작업자 노드 정책을 작업자 노드에 적용

작업자 노드에 대한 정책을 생성할 수 있습니다.

프로세스

  1. 다음 정책 템플릿을 생성합니다.

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "example-sno-workers"
      namespace: "example-sno"
    spec:
      bindingRules:
        sites: "example-sno" 1
      mcp: "worker" 2
      sourceFiles:
        - fileName: MachineConfigGeneric.yaml 3
          policyName: "config-policy"
          metadata:
            labels:
              machineconfiguration.openshift.io/role: worker
            name: enable-workload-partitioning
          spec:
            config:
              storage:
                files:
                - contents:
                    source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMyIgfQo=
                  mode: 420
                  overwrite: true
                  path: /etc/crio/crio.conf.d/01-workload-partitioning
                  user:
                    name: root
                - contents:
                    source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTMiCiAgfQp9Cg==
                  mode: 420
                  overwrite: true
                  path: /etc/kubernetes/openshift-workload-pinning
                  user:
                    name: root
        - fileName: PerformanceProfile.yaml
          policyName: "config-policy"
          metadata:
            name: openshift-worker-node-performance-profile
          spec:
            cpu: 4
              isolated: "4-47"
              reserved: "0-3"
            hugepages:
              defaultHugepagesSize: 1G
              pages:
                - size: 1G
                  count: 32
            realTimeKernel:
              enabled: true
        - fileName: TunedPerformancePatch.yaml
          policyName: "config-policy"
          metadata:
            name: performance-patch-worker
          spec:
            profile:
              - name: performance-patch-worker
                data: |
                  [main]
                  summary=Configuration changes profile inherited from performance created tuned
                  include=openshift-node-performance-openshift-worker-node-performance-profile
                  [bootloader]
                  cmdline_crash=nohz_full=4-47 5
                  [sysctl]
                  kernel.timer_migration=1
                  [scheduler]
                  group.ice-ptp=0:f:10:*:ice-ptp.*
                  [service]
                  service.stalld=start,enable
                  service.chronyd=stop,disable
            recommend:
            - profile: performance-patch-worker
    1
    정책은 이 레이블이 있는 모든 클러스터에 적용됩니다.
    2
    MCP 필드는 worker 로 설정해야 합니다.
    3
    이 일반 MachineConfig CR은 작업자 노드에서 워크로드 파티셔닝을 구성하는 데 사용됩니다.
    4
    각 특정 하드웨어 플랫폼에 대해 cpu.isolatedcpu.reserved 필드를 구성해야 합니다.
    5
    cmdline_crash CPU 세트는 PerformanceProfile 섹션의 cpu.isolated 세트와 일치해야 합니다.

    일반 MachineConfig CR은 작업자 노드에서 워크로드 파티셔닝을 구성하는 데 사용됩니다. criokubelet 구성 파일의 콘텐츠를 생성할 수 있습니다.

  2. ArgoCD 정책 애플리케이션에서 모니터링하는 Git 리포지토리에 생성된 정책 템플릿을 추가합니다.
  3. kustomization.yaml 파일에 정책을 추가합니다.
  4. Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  5. spoke 클러스터에 대한 새 정책을 수정하려면 TALM 사용자 정의 리소스를 생성합니다.

    $ cat <<EOF | oc apply -f -
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: example-sno-worker-policies
      namespace: default
    spec:
      backup: false
      clusters:
      - example-sno
      enable: true
      managedPolicies:
      - group-du-sno-config-policy
      - example-sno-workers-config-policy
      - example-sno-config-policy
      preCaching: false
      remediationStrategy:
        maxConcurrency: 1
    EOF

18.13.5. GitOps ZTP를 사용하여 단일 노드 OpenShift 클러스터에 작업자 노드 추가

기존 단일 노드 OpenShift 클러스터에 하나 이상의 작업자 노드를 추가하여 클러스터에서 사용 가능한 CPU 리소스를 늘릴 수 있습니다.

사전 요구 사항

  • OpenShift Container Platform 4.11 이상 베어 메탈 허브 클러스터에서 RHACM 2.6 이상을 설치하고 구성
  • 허브 클러스터에 토폴로지 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를 구성합니다.

프로세스

  1. example-sno.yaml SiteConfig 매니페스트를 사용하여 클러스터를 배포한 경우 새 작업자 노드를 spec.clusters['example-sno'].nodes 목록에 추가합니다.

    nodes:
    - hostName: "example-node2.example.com"
      role: "worker"
      bmcAddress: "idrac-virtualmedia+https://[1111:2222:3333:4444::bbbb:1]/redfish/v1/Systems/System.Embedded.1"
      bmcCredentialsName:
        name: "example-node2-bmh-secret"
      bootMACAddress: "AA:BB:CC:DD:EE:11"
      bootMode: "UEFI"
      nodeNetwork:
        interfaces:
          - name: eno1
            macAddress: "AA:BB:CC:DD:EE:11"
        config:
          interfaces:
            - name: eno1
              type: ethernet
              state: up
              macAddress: "AA:BB:CC:DD:EE:11"
              ipv4:
                enabled: false
              ipv6:
                enabled: true
                address:
                - ip: 1111:2222:3333:4444::1
                  prefix-length: 64
          dns-resolver:
            config:
              search:
              - example.com
              server:
              - 1111:2222:3333:4444::2
          routes:
            config:
            - destination: ::/0
              next-hop-interface: eno1
              next-hop-address: 1111:2222:3333:4444::1
              table-id: 254
  2. SiteConfig 파일의 spec.nodes 섹션에 있는 bmcCredentialsName 필드에서 참조하는 새 호스트의 BMC 인증 시크릿을 생성합니다.

    apiVersion: v1
    data:
      password: "password"
      username: "username"
    kind: Secret
    metadata:
      name: "example-node2-bmh-secret"
      namespace: example-sno
    type: Opaque
  3. Git의 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

    ArgoCD 클러스터 애플리케이션이 동기화되면 GitOps ZTP 플러그인에서 생성한 허브 클러스터에 두 개의 새 매니페스트가 표시됩니다.

    • BareMetalHost
    • NMStateConfig

      중요

      작업자 노드에 대해 cpuset 필드를 구성해서는 안 됩니다. 노드 설치가 완료된 후 작업자 노드의 워크로드 파티셔닝이 관리 정책을 통해 추가됩니다.

검증

설치 프로세스를 여러 가지 방법으로 모니터링할 수 있습니다.

  • 다음 명령을 실행하여 사전 프로비저닝 이미지가 생성되었는지 확인합니다.

    $ oc get ppimg -n example-sno

    출력 예

    NAMESPACE       NAME            READY   REASON
    example-sno     example-sno     True    ImageCreated
    example-sno     example-node2   True    ImageCreated

  • 베어 메탈 호스트의 상태를 확인합니다.

    $ oc get bmh -n example-sno

    출력 예

    NAME            STATE          CONSUMER   ONLINE   ERROR   AGE
    example-sno     provisioned               true             69m
    example-node2   provisioning              true             4m50s 1

    1
    프로비저닝 상태는 설치 미디어에서 부팅하는 노드가 진행 중임을 나타냅니다.
  • 설치 프로세스를 지속적으로 모니터링합니다.

    1. 다음 명령을 실행하여 에이전트 설치 프로세스를 확인합니다.

      $ oc get agent -n example-sno --watch

      출력 예

      NAME                                   CLUSTER   APPROVED   ROLE     STAGE
      671bc05d-5358-8940-ec12-d9ad22804faa   example-sno   true       master   Done
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Starting installation
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Installing
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Writing image to disk
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Waiting for control plane
      [...]
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Rebooting
      14fd821b-a35d-9cba-7978-00ddf535ff37   example-sno   true       worker   Done

    2. 작업자 노드 설치가 완료되면 작업자 노드 인증서가 자동으로 승인됩니다. 이 시점에서 작업자는 ManagedClusterInfo 상태에 나타납니다. 다음 명령을 실행하여 상태를 확인합니다.

      $ oc get managedclusterinfo/example-sno -n example-sno -o \
      jsonpath='{range .status.nodeList[*]}{.name}{"\t"}{.conditions}{"\t"}{.labels}{"\n"}{end}'

      출력 예

      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":""}

18.14. 단일 노드 OpenShift 배포를 위한 이미지 사전 캐싱

ZTP( GitOps Zero Touch Provisioning) 솔루션을 사용하여 다수의 클러스터를 배포하는 제한된 대역폭이 있는 환경에서는 OpenShift Container Platform을 부트스트랩 및 설치하는 데 필요한 모든 이미지를 다운로드하지 않도록 해야 합니다. 원격 단일 노드 OpenShift 사이트의 제한된 대역폭으로 인해 배포 시간이 길어질 수 있습니다. factory-precaching-cli 툴을 사용하면 ZTP 프로비저닝을 위해 원격 사이트에 제공하기 전에 서버를 사전 단계적으로 제공할 수 있습니다.

factory-precaching-cli 툴은 다음을 수행합니다.

  • 부팅에 최소 ISO에 필요한 RHCOS rootfs 이미지를 다운로드합니다.
  • 데이터로 레이블이 지정된 설치 디스크에서 파티션을 생성합니다.
  • xfs로 디스크를 포맷합니다.
  • 디스크 끝에 GUID 파티션 테이블(GPT) 데이터 파티션을 만듭니다. 여기서 도구에서 파티션 크기를 구성할 수 있습니다.
  • OpenShift Container Platform을 설치하는 데 필요한 컨테이너 이미지를 복사합니다.
  • OpenShift Container Platform을 설치하기 위해 ZTP에 필요한 컨테이너 이미지를 복사합니다.
  • 선택 사항: Day-2 Operator를 파티션에 복사합니다.
중요

factory-precaching-cli 툴은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

18.14.1. factory-precaching-cli 툴 가져오기

factory-precaching-cli 툴 Go 바이너리는 Telco RAN 분산 장치(DU) 컨테이너 이미지에서 공개적으로 사용할 수 있습니다. 컨테이너 이미지의 factory-precaching-cli 툴 Go 바이너리는 podman 을 사용하여 RHCOS 라이브 이미지를 실행하는 서버에서 실행됩니다. 연결이 끊긴 환경에서 작업 중이거나 프라이빗 레지스트리가 있는 경우 이미지를 서버에 다운로드할 수 있도록 이미지를 복사해야 합니다.

프로세스

  • 다음 명령을 실행하여 factory-precaching-cli 툴 이미지를 가져옵니다.

    # podman pull quay.io/openshift-kni/telco-ran-tools:latest

검증

  • 도구를 사용할 수 있는지 확인하려면 factory-precaching-cli 도구 Go 바이너리의 현재 버전을 쿼리합니다.

    # podman run quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli -v

    출력 예

    factory-precaching-cli version 20221018.120852+main.feecf17

18.14.2. 라이브 운영 체제 이미지에서 부팅

factory-precaching-cli 툴을 사용하여 하나의 디스크만 사용 가능하고 외부 디스크 드라이브를 서버에 연결할 수 없는 서버를 부팅할 수 있습니다.

주의

RHCOS는 RHCOS 이미지로 디스크를 쓸 때 디스크를 사용하지 않아야 합니다.

서버 하드웨어에 따라 다음 방법 중 하나를 사용하여 RHCOS 라이브 ISO를 빈 서버에 마운트할 수 있습니다.

  • Dell 서버에서 Dell RACADM 툴 사용.
  • HP 서버에서 HPONCFG 툴 사용.
  • Redfish BMC API 사용.
참고

마운트 절차를 자동화하는 것이 좋습니다. 절차를 자동화하려면 필요한 이미지를 가져와서 로컬 HTTP 서버에서 호스팅해야 합니다.

사전 요구 사항

  • 호스트의 전원을 켭니다.
  • 호스트에 대한 네트워크 연결이 있습니다.
프로세스

이 예제 절차에서는 Redfish BMC API를 사용하여 RHCOS 라이브 ISO를 마운트합니다.

  1. RHCOS 라이브 ISO를 마운트합니다.

    1. 가상 미디어 상태를 확인합니다.

      $ 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
    2. 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
    3. 가상 미디어에서 한 번 부팅되도록 부팅 순서를 설정합니다.

      $ 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
  2. 재부팅하고 서버가 가상 미디어에서 부팅 중인지 확인합니다.

추가 리소스

18.14.3. 디스크 파티셔닝

전체 사전 캐싱 프로세스를 실행하려면 라이브 ISO에서 부팅하고 컨테이너 이미지에서 factory-precaching-cli 툴을 사용하여 필요한 모든 아티팩트를 파티션 및 사전 캐시해야 합니다.

프로비저닝 중에 운영 체제(RHCOS)가 장치에 기록될 때 디스크를 사용하지 않아야 하므로 라이브 ISO 또는 RHCOS 라이브 ISO가 필요합니다. 이 절차를 통해 단일 디스크 서버도 활성화할 수 있습니다.

사전 요구 사항

  • 분할되지 않은 디스크가 있습니다.
  • quay.io/openshift-kni/telco-ran-tools:latest 이미지에 액세스할 수 있습니다.
  • OpenShift Container Platform을 설치하고 필요한 이미지를 사전 캐시할 수 있는 충분한 스토리지가 있습니다.

프로세스

  1. 디스크가 지워졌는지 확인합니다.

    # lsblk

    출력 예

    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

  2. 장치에서 파일 시스템, RAID 또는 파티션 테이블 서명을 지웁니다.

    # wipefs -a /dev/nvme0n1

    출력 예

    /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

중요

아티팩트를 미리 캐싱하기 위해 장치의 파티션 번호 1을 사용하므로 디스크가 비어 있지 않으면 도구가 실패합니다.

18.14.3.1. 파티션 생성

장치가 준비되면 단일 파티션과 GPT 파티션 테이블을 만듭니다. 파티션은 자동으로 데이터로 레이블이 지정되어 장치 끝에 생성됩니다. 그렇지 않으면 coreos-installer 로 파티션을 덮어씁니다.

중요

coreos-installer 를 사용하려면 장치 끝에 파티션을 생성하고 데이터로 레이블이 지정되어야 합니다. RHCOS 이미지를 디스크에 쓸 때 파티션을 저장하려면 두 요구 사항이 모두 필요합니다.

사전 요구 사항

  • 호스트 장치의 포맷으로 인해 컨테이너가 privileged 로 실행되어야 합니다.
  • 컨테이너 내에서 프로세스를 실행할 수 있도록 /dev 폴더를 마운트해야 합니다.

프로세스

다음 예에서 파티션 크기는 Day 2 Operator의 DU 프로파일을 사전 캐싱할 수 있기 때문에 250GiB입니다.

  1. 컨테이너를 권한으로 실행하고 디스크를 분할합니다.

    # 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 250 3
    1
    factory-precaching-cli 도구의 파티션 함수를 지정합니다.
    2
    디스크의 루트 디렉터리를 정의합니다.
    3
    디스크 크기(GB)를 정의합니다.
  2. 스토리지 정보를 확인합니다.

    # lsblk

    출력 예

    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
    └─nvme0n1p1 259:3    0   250G  0 part

검증

다음 요구 사항이 충족되었는지 확인해야 합니다.

  • 장치에 GPT 파티션 테이블이 있습니다.
  • 파티션은 장치의 최신 섹터를 사용합니다.
  • 파티션은 데이터로 올바르게 레이블이 지정됩니다.

디스크 상태를 쿼리하여 디스크가 예상대로 분할되었는지 확인합니다.

# gdisk -l /dev/nvme0n1

출력 예

GPT fdisk (gdisk) version 1.0.3

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/nvme0n1: 3125627568 sectors, 1.5 TiB
Model: Dell Express Flash PM1725b 1.6TB SFF
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): CB5A9D44-9B3C-4174-A5C1-C64957910B61
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 3125627534
Partitions will be aligned on 2048-sector boundaries
Total free space is 2601338846 sectors (1.2 TiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1      2601338880      3125627534   250.0 GiB   8300  data

18.14.3.2. 파티션 마운트

디스크가 올바르게 분할되었는지 확인한 후 장치를 /mnt 에 마운트할 수 있습니다.

중요

GitOps ZTP 준비 중에 해당 마운트 지점이 사용되므로 장치를 /mnt 에 마운트하는 것이 좋습니다.

  1. 파티션이 xfs 로 포맷되었는지 확인합니다.

    # lsblk -f /dev/nvme0n1

    출력 예

    NAME        FSTYPE LABEL UUID                                 MOUNTPOINT
    nvme0n1
    └─nvme0n1p1 xfs          1bee8ea4-d6cf-4339-b690-a76594794071

  2. 파티션을 마운트합니다.

    # mount /dev/nvme0n1p1 /mnt/

검증

  • 파티션이 마운트되었는지 확인합니다.

    # lsblk

    출력 예

    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
    └─nvme0n1p1 259:2    0   250G  0 part /var/mnt 1

    1
    RHCOS의 /mnt 폴더가 /var/mnt 에 대한 링크이므로 마운트 지점은 /var/mnt 입니다.

18.14.4. 이미지 다운로드

factory-precaching-cli 툴을 사용하면 다음 이미지를 분할된 서버에 다운로드할 수 있습니다.

  • OpenShift Container Platform 이미지
  • 5G RAN 사이트의 DU(Distributed Unit) 프로필에 포함된 Operator 이미지
  • 연결이 끊긴 레지스트리의 Operator 이미지
참고

사용 가능한 Operator 이미지 목록은 OpenShift Container Platform 릴리스마다 다를 수 있습니다.

18.14.4.1. 병렬 작업자로 다운로드

factory-precaching-cli 툴은 병렬 작업자를 사용하여 여러 이미지를 동시에 다운로드합니다. --parallel 또는 -p 옵션을 사용하여 작업자 수를 구성할 수 있습니다. 기본 수는 서버에 사용 가능한 CPU의 80%로 설정됩니다.

참고

로그인 쉘은 CPU의 서브 세트로 제한될 수 있으므로 컨테이너에서 사용할 수 있는 CPU가 줄어듭니다. 이 제한을 제거하려면 명령 앞에 taskset 0xffffff 를 붙일 수 있습니다. 예를 들면 다음과 같습니다.

# taskset 0xffffffff podman run --rm quay.io/openshift-kni/telco-ran-tools:latest factory-precaching-cli download --help
18.14.4.2. OpenShift Container Platform 이미지 다운로드 준비

OpenShift Container Platform 컨테이너 이미지를 다운로드하려면 다중 클러스터 엔진 버전을 알아야 합니다. --du-profile 플래그를 사용하는 경우 단일 노드 OpenShift를 프로비저닝할 허브 클러스터에서 실행 중인 RHACM(Red Hat Advanced Cluster Management) 버전도 지정해야 합니다.

사전 요구 사항

  • RHACM 및 다중 클러스터 엔진 Operator가 설치되어 있어야 합니다.
  • 스토리지 장치를 분할했습니다.
  • 분할된 장치에 이미지를 위한 충분한 공간이 있습니다.
  • 베어 메탈 서버를 인터넷에 연결했습니다.
  • 유효한 풀 시크릿이 있습니다.

프로세스

  1. hub 클러스터에서 다음 명령을 실행하여 RHACM 버전과 다중 클러스터 엔진 버전을 확인합니다.

    $ oc get csv -A | grep -i advanced-cluster-management

    출력 예

    open-cluster-management                            advanced-cluster-management.v2.6.3           Advanced Cluster Management for Kubernetes   2.6.3                 advanced-cluster-management.v2.6.3                Succeeded

    $ oc get csv -A | grep -i multicluster-engine

    출력 예

    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

  2. 컨테이너 레지스트리에 액세스하려면 설치할 서버에 유효한 풀 시크릿을 복사합니다.

    1. .docker 폴더를 생성합니다.

      $ mkdir /root/.docker
    2. config.json 파일의 유효한 가져오기를 이전에 생성된 .docker/ 폴더에 복사합니다.

      $ cp config.json /root/.docker/config.json 1
      1
      /root/.docker/config.jsonpodman 이 레지스트리의 로그인 인증 정보를 확인하는 기본 경로입니다.
참고

다른 레지스트리를 사용하여 필요한 아티팩트를 가져오는 경우 적절한 풀 시크릿을 복사해야 합니다. 로컬 레지스트리에서 TLS를 사용하는 경우 레지스트리의 인증서도 포함해야 합니다.

18.14.4.3. OpenShift Container Platform 이미지 다운로드

factory-precaching-cli 툴을 사용하면 특정 OpenShift Container Platform 릴리스를 프로비저닝하는 데 필요한 모든 컨테이너 이미지를 사전 캐시할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 릴리스를 사전 캐시합니다.

    # podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools -- \
       factory-precaching-cli download \ 1
       -r 4.14.0 \ 2
       --acm-version 2.6.3 \ 3
       --mce-version 2.1.4 \ 4
       -f /mnt \ 5
       --img quay.io/custom/repository 6
    1
    factory-precaching-cli 툴의 다운로드 기능을 지정합니다.
    2
    OpenShift Container Platform 릴리스 버전을 정의합니다.
    3
    RHACM 버전을 정의합니다.
    4
    다중 클러스터 엔진 버전을 정의합니다.
    5
    디스크에서 이미지를 다운로드할 폴더를 정의합니다.
    6
    선택 사항: 추가 이미지를 저장하는 리포지토리를 정의합니다. 이러한 이미지는 디스크에서 다운로드되고 미리 캐시됩니다.

    출력 예

    Generated /mnt/imageset.yaml
    Generating list of pre-cached artifacts...
    Processing artifact [1/176]: ocp-v4.0-art-dev@sha256_6ac2b96bf4899c01a87366fd0feae9f57b1b61878e3b5823da0c3f34f707fbf5
    Processing artifact [2/176]: ocp-v4.0-art-dev@sha256_f48b68d5960ba903a0d018a10544ae08db5802e21c2fa5615a14fc58b1c1657c
    Processing artifact [3/176]: ocp-v4.0-art-dev@sha256_a480390e91b1c07e10091c3da2257180654f6b2a735a4ad4c3b69dbdb77bbc06
    Processing artifact [4/176]: ocp-v4.0-art-dev@sha256_ecc5d8dbd77e326dba6594ff8c2d091eefbc4d90c963a9a85b0b2f0e6155f995
    Processing artifact [5/176]: ocp-v4.0-art-dev@sha256_274b6d561558a2f54db08ea96df9892315bb773fc203b1dbcea418d20f4c7ad1
    Processing artifact [6/176]: ocp-v4.0-art-dev@sha256_e142bf5020f5ca0d1bdda0026bf97f89b72d21a97c9cc2dc71bf85050e822bbf
    ...
    Processing artifact [175/176]: ocp-v4.0-art-dev@sha256_16cd7eda26f0fb0fc965a589e1e96ff8577e560fcd14f06b5fda1643036ed6c8
    Processing artifact [176/176]: ocp-v4.0-art-dev@sha256_cf4d862b4a4170d4f611b39d06c31c97658e309724f9788e155999ae51e7188f
    ...
    Summary:
    
    Release:                            4.14.0
    Hub Version:                        2.6.3
    ACM Version:                        2.6.3
    MCE Version:                        2.1.4
    Include DU Profile:                 No
    Workers:                            83

검증

  • 모든 이미지가 서버의 대상 폴더에 압축되었는지 확인합니다.

    $ ls -l /mnt 1
    1
    /mnt 폴더의 이미지를 사전 캐시하는 것이 좋습니다.

    출력 예

    -rw-r--r--. 1 root root  136352323 Oct 31 15:19 ocp-v4.0-art-dev@sha256_edec37e7cd8b1611d0031d45e7958361c65e2005f145b471a8108f1b54316c07.tgz
    -rw-r--r--. 1 root root  156092894 Oct 31 15:33 ocp-v4.0-art-dev@sha256_ee51b062b9c3c9f4fe77bd5b3cc9a3b12355d040119a1434425a824f137c61a9.tgz
    -rw-r--r--. 1 root root  172297800 Oct 31 15:29 ocp-v4.0-art-dev@sha256_ef23d9057c367a36e4a5c4877d23ee097a731e1186ed28a26c8d21501cd82718.tgz
    -rw-r--r--. 1 root root  171539614 Oct 31 15:23 ocp-v4.0-art-dev@sha256_f0497bb63ef6834a619d4208be9da459510df697596b891c0c633da144dbb025.tgz
    -rw-r--r--. 1 root root  160399150 Oct 31 15:20 ocp-v4.0-art-dev@sha256_f0c339da117cde44c9aae8d0bd054bceb6f19fdb191928f6912a703182330ac2.tgz
    -rw-r--r--. 1 root root  175962005 Oct 31 15:17 ocp-v4.0-art-dev@sha256_f19dd2e80fb41ef31d62bb8c08b339c50d193fdb10fc39cc15b353cbbfeb9b24.tgz
    -rw-r--r--. 1 root root  174942008 Oct 31 15:33 ocp-v4.0-art-dev@sha256_f1dbb81fa1aa724e96dd2b296b855ff52a565fbef003d08030d63590ae6454df.tgz
    -rw-r--r--. 1 root root  246693315 Oct 31 15:31 ocp-v4.0-art-dev@sha256_f44dcf2c94e4fd843cbbf9b11128df2ba856cd813786e42e3da1fdfb0f6ddd01.tgz
    -rw-r--r--. 1 root root  170148293 Oct 31 15:00 ocp-v4.0-art-dev@sha256_f48b68d5960ba903a0d018a10544ae08db5802e21c2fa5615a14fc58b1c1657c.tgz
    -rw-r--r--. 1 root root  168899617 Oct 31 15:16 ocp-v4.0-art-dev@sha256_f5099b0989120a8d08a963601214b5c5cb23417a707a8624b7eb52ab788a7f75.tgz
    -rw-r--r--. 1 root root  176592362 Oct 31 15:05 ocp-v4.0-art-dev@sha256_f68c0e6f5e17b0b0f7ab2d4c39559ea89f900751e64b97cb42311a478338d9c3.tgz
    -rw-r--r--. 1 root root  157937478 Oct 31 15:37 ocp-v4.0-art-dev@sha256_f7ba33a6a9db9cfc4b0ab0f368569e19b9fa08f4c01a0d5f6a243d61ab781bd8.tgz
    -rw-r--r--. 1 root root  145535253 Oct 31 15:26 ocp-v4.0-art-dev@sha256_f8f098911d670287826e9499806553f7a1dd3e2b5332abbec740008c36e84de5.tgz
    -rw-r--r--. 1 root root  158048761 Oct 31 15:40 ocp-v4.0-art-dev@sha256_f914228ddbb99120986262168a705903a9f49724ffa958bb4bf12b2ec1d7fb47.tgz
    -rw-r--r--. 1 root root  167914526 Oct 31 15:37 ocp-v4.0-art-dev@sha256_fa3ca9401c7a9efda0502240aeb8d3ae2d239d38890454f17fe5158b62305010.tgz
    -rw-r--r--. 1 root root  164432422 Oct 31 15:24 ocp-v4.0-art-dev@sha256_fc4783b446c70df30b3120685254b40ce13ba6a2b0bf8fb1645f116cf6a392f1.tgz
    -rw-r--r--. 1 root root  306643814 Oct 31 15:11 troubleshoot@sha256_b86b8aea29a818a9c22944fd18243fa0347c7a2bf1ad8864113ff2bb2d8e0726.tgz

18.14.4.4. Operator 이미지 다운로드

5G radio Access Network (RAN) Distributed Unit (DU) 클러스터 구성에서 사용되는 pre-cache Day-2 Operator도 사용할 수 있습니다. Day-2 Operator는 설치된 OpenShift Container Platform 버전을 사용합니다.

중요

--acm-version--mce-version 플래그를 사용하여 RHACM 허브 및 다중 클러스터 엔진 Operator 버전을 포함해야 합니다. 따라서 factory-precaching-cli 툴이 RHACM 및 다중 클러스터 엔진 Operator에 적합한 컨테이너 이미지를 사전 캐시할 수 있습니다.

프로세스

  • Operator 이미지를 사전 캐시합니다.

    # podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli download \ 1
       -r 4.14.0 \ 2
       --acm-version 2.6.3 \ 3
       --mce-version 2.1.4 \ 4
       -f /mnt \ 5
       --img quay.io/custom/repository 6
       --du-profile -s 7
    1
    factory-precaching-cli 툴의 다운로드 기능을 지정합니다.
    2
    OpenShift Container Platform 릴리스 버전을 정의합니다.
    3
    RHACM 버전을 정의합니다.
    4
    다중 클러스터 엔진 버전을 정의합니다.
    5
    디스크에서 이미지를 다운로드할 폴더를 정의합니다.
    6
    선택 사항: 추가 이미지를 저장하는 리포지토리를 정의합니다. 이러한 이미지는 디스크에서 다운로드되고 미리 캐시됩니다.
    7
    DU 구성에 포함된 Operator를 사전 캐싱합니다.

    출력 예

    Generated /mnt/imageset.yaml
    Generating list of pre-cached artifacts...
    Processing artifact [1/379]: ocp-v4.0-art-dev@sha256_7753a8d9dd5974be8c90649aadd7c914a3d8a1f1e016774c7ac7c9422e9f9958
    Processing artifact [2/379]: ose-kube-rbac-proxy@sha256_c27a7c01e5968aff16b6bb6670423f992d1a1de1a16e7e260d12908d3322431c
    Processing artifact [3/379]: ocp-v4.0-art-dev@sha256_370e47a14c798ca3f8707a38b28cfc28114f492bb35fe1112e55d1eb51022c99
    ...
    Processing artifact [378/379]: ose-local-storage-operator@sha256_0c81c2b79f79307305e51ce9d3837657cf9ba5866194e464b4d1b299f85034d0
    Processing artifact [379/379]: multicluster-operators-channel-rhel8@sha256_c10f6bbb84fe36e05816e873a72188018856ad6aac6cc16271a1b3966f73ceb3
    ...
    Summary:
    
    Release:                            4.14.0
    Hub Version:                        2.6.3
    ACM Version:                        2.6.3
    MCE Version:                        2.1.4
    Include DU Profile:                 Yes
    Workers:                            83

18.14.4.5. 연결이 끊긴 환경에서 사용자 정의 이미지 사전 캐싱

--generate-imageset 인수는 ImageSetConfiguration CR(사용자 정의 리소스)이 생성된 후 factory-precaching-cli 툴을 중지합니다. 이를 통해 이미지를 다운로드하기 전에 ImageSetConfiguration CR을 사용자 지정할 수 있습니다. CR을 사용자 지정한 후 --skip-imageset 인수를 사용하여 ImageSetConfiguration CR에 지정한 이미지를 다운로드할 수 있습니다.

다음과 같은 방법으로 ImageSetConfiguration CR을 사용자 지정할 수 있습니다.

  • Operator 및 추가 이미지 추가
  • Operator 및 추가 이미지 제거
  • Operator 및 카탈로그 소스를 로컬 또는 연결이 끊긴 레지스트리로 변경

프로세스

  1. 이미지를 사전 캐시합니다.

    # podman run -v /mnt:/mnt -v /root/.docker:/root/.docker --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- factory-precaching-cli download \ 1
       -r 4.14.0 \ 2
       --acm-version 2.6.3 \ 3
       --mce-version 2.1.4 \ 4
       -f /mnt \ 5
       --img quay.io/custom/repository 6
       --du-profile -s \ 7
       --generate-imageset 8
    1
    factory-precaching-cli 툴의 다운로드 기능을 지정합니다.
    2
    OpenShift Container Platform 릴리스 버전을 정의합니다.
    3
    RHACM 버전을 정의합니다.
    4
    다중 클러스터 엔진 버전을 정의합니다.
    5
    디스크에서 이미지를 다운로드할 폴더를 정의합니다.
    6
    선택 사항: 추가 이미지를 저장하는 리포지토리를 정의합니다. 이러한 이미지는 디스크에서 다운로드되고 미리 캐시됩니다.
    7
    DU 구성에 포함된 Operator를 사전 캐싱합니다.
    8
    --generate-imageset 인수는 CR을 사용자 지정할 수 있는 ImageSetConfiguration CR만 생성합니다.

    출력 예

    Generated /mnt/imageset.yaml

    ImageSetConfiguration CR의 예

    apiVersion: mirror.openshift.io/v1alpha2
    kind: ImageSetConfiguration
    mirror:
      platform:
        channels:
        - name: stable-4.14
          minVersion: 4.14.0 1
          maxVersion: 4.14.0
      additionalImages:
        - name: quay.io/custom/repository
      operators:
        - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.14
          packages:
            - name: advanced-cluster-management 2
              channels:
                 - name: 'release-2.6'
                   minVersion: 2.6.3
                   maxVersion: 2.6.3
            - name: multicluster-engine 3
              channels:
                 - name: 'stable-2.1'
                   minVersion: 2.1.4
                   maxVersion: 2.1.4
            - name: local-storage-operator 4
              channels:
                - name: 'stable'
            - name: ptp-operator 5
              channels:
                - name: 'stable'
            - name: sriov-network-operator 6
              channels:
                - name: 'stable'
            - name: cluster-logging 7
              channels:
                - name: 'stable'
            - name: lvms-operator 8
              channels:
                - name: 'stable-4.14'
            - name: amq7-interconnect-operator 9
              channels:
                - name: '1.10.x'
            - name: bare-metal-event-relay 10
              channels:
                - name: 'stable'
        - catalog: registry.redhat.io/redhat/certified-operator-index:v4.14
          packages:
            - name: sriov-fec 11
              channels:
                - name: 'stable'

    1
    플랫폼 버전은 툴로 전달된 버전과 일치합니다.
    2 3
    RHACM 버전 및 다중 클러스터 엔진 Operator는 툴에 전달된 버전과 일치합니다.
    4 5 6 7 8 9 10 11
    CR에는 지정된 모든 DU Operator가 포함되어 있습니다.
  2. CR에서 카탈로그 리소스를 사용자 지정합니다.

    apiVersion: mirror.openshift.io/v1alpha2
    kind: ImageSetConfiguration
    mirror:
      platform:
    [...]
      operators:
        - catalog: eko4.cloud.lab.eng.bos.redhat.com:8443/redhat/certified-operator-index:v4.14
          packages:
            - name: sriov-fec
              channels:
                - name: 'stable'

    로컬 또는 연결이 끊긴 레지스트리를 사용하여 이미지를 다운로드하는 경우 먼저 콘텐츠를 가져오려는 레지스트리에 대한 인증서를 추가해야 합니다.

  3. 오류를 방지하려면 레지스트리 인증서를 서버에 복사합니다.

    # cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
  4. 그런 다음 인증서 신뢰 저장소를 업데이트합니다.

    # update-ca-trust
  5. host /etc/pki 폴더를 factory-cli 이미지에 마운트합니다.

    # podman run -v /mnt:/mnt -v /root/.docker:/root/.docker -v /etc/pki:/etc/pki --privileged --rm quay.io/openshift-kni/telco-ran-tools:latest -- \
    factory-precaching-cli download \ 1
       -r 4.14.0 \ 2
       --acm-version 2.6.3 \ 3
       --mce-version 2.1.4 \ 4
       -f /mnt \ 5
       --img quay.io/custom/repository 6
       --du-profile -s \ 7
       --skip-imageset 8
    1
    factory-precaching-cli 툴의 다운로드 기능을 지정합니다.
    2
    OpenShift Container Platform 릴리스 버전을 정의합니다.
    3
    RHACM 버전을 정의합니다.
    4
    다중 클러스터 엔진 버전을 정의합니다.
    5
    디스크에서 이미지를 다운로드할 폴더를 정의합니다.
    6
    선택 사항: 추가 이미지를 저장하는 리포지토리를 정의합니다. 이러한 이미지는 디스크에서 다운로드되고 미리 캐시됩니다.
    7
    DU 구성에 포함된 Operator를 사전 캐싱합니다.
    8
    --skip-imageset 인수를 사용하면 사용자 지정된 ImageSetConfiguration CR에 지정한 이미지를 다운로드할 수 있습니다.
  6. imageSetConfiguration CR을 생성하지 않고 이미지를 다운로드합니다.

    # 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.14.0 \
    --acm-version 2.6.3 --mce-version 2.1.4 -f /mnt \
    --img quay.io/custom/repository \
    --du-profile -s \
    --skip-imageset

추가 리소스

18.14.5. GitOps ZTP의 이미지 사전 캐싱

SiteConfig 매니페스트는 OpenShift 클러스터를 설치 및 구성하는 방법을 정의합니다. ZTP( GitOps Zero Touch Provisioning) 프로비저닝 워크플로우에서 factory-precaching-cli 툴에는 site Config 매니페스트에 다음과 같은 추가 필드가 필요합니다.

  • clusters.ignitionConfigOverride
  • nodes.installerArgs
  • nodes.ignitionConfigOverride

추가 필드가 있는 siteConfig의 예

apiVersion: ran.openshift.io/v1
kind: SiteConfig
metadata:
  name: "example-5g-lab"
  namespace: "example-5g-lab"
spec:
  baseDomain: "example.domain.redhat.com"
  pullSecretRef:
    name: "assisted-deployment-pull-secret"
  clusterImageSetNameRef: "img4.9.10-x86-64-appsub" 1
  sshPublicKey: "ssh-rsa ..."
  clusters:
  - clusterName: "sno-worker-0"
    clusterImageSetNameRef: "eko4-img4.11.5-x86-64-appsub" 2
    clusterLabels:
      group-du-sno: ""
      common-411: true
      sites : "example-5g-lab"
      vendor: "OpenShift"
    clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
    machineNetwork:
      - cidr: 10.19.32.192/26
    serviceNetwork:
      - 172.30.0.0/16
    networkType: "OVNKubernetes"
    additionalNTPSources:
      - clock.corp.redhat.com
    ignitionConfigOverride:
      '{
        "ignition": {
          "version": "3.1.0"
        },
        "systemd": {
          "units": [
            {
              "name": "var-mnt.mount",
              "enabled": true,
              "contents": "[Unit]\nDescription=Mount partition with artifacts\nBefore=precache-images.service\nBindsTo=precache-images.service\nStopWhenUnneeded=true\n\n[Mount]\nWhat=/dev/disk/by-partlabel/data\nWhere=/var/mnt\nType=xfs\nTimeoutSec=30\n\n[Install]\nRequiredBy=precache-images.service"
            },
            {
              "name": "precache-images.service",
              "enabled": true,
              "contents": "[Unit]\nDescription=Extracts the precached images in discovery stage\nAfter=var-mnt.mount\nBefore=agent.service\n\n[Service]\nType=oneshot\nUser=root\nWorkingDirectory=/var/mnt\nExecStart=bash /usr/local/bin/extract-ai.sh\n#TimeoutStopSec=30\n\n[Install]\nWantedBy=multi-user.target default.target\nWantedBy=agent.service"
            }
          ]
        },
        "storage": {
          "files": [
            {
              "overwrite": true,
              "path": "/usr/local/bin/extract-ai.sh",
              "mode": 755,
              "user": {
                "name": "root"
              },
              "contents": {
                "source": "data:,%23%21%2Fbin%2Fbash%0A%0AFOLDER%3D%22%24%7BFOLDER%3A-%24%28pwd%29%7D%22%0AOCP_RELEASE_LIST%3D%22%24%7BOCP_RELEASE_LIST%3A-ai-images.txt%7D%22%0ABINARY_FOLDER%3D%2Fvar%2Fmnt%0A%0Apushd%20%24FOLDER%0A%0Atotal_copies%3D%24%28sort%20-u%20%24BINARY_FOLDER%2F%24OCP_RELEASE_LIST%20%7C%20wc%20-l%29%20%20%23%20Required%20to%20keep%20track%20of%20the%20pull%20task%20vs%20total%0Acurrent_copy%3D1%0A%0Awhile%20read%20-r%20line%3B%0Ado%0A%20%20uri%3D%24%28echo%20%22%24line%22%20%7C%20awk%20%27%7Bprint%241%7D%27%29%0A%20%20%23tar%3D%24%28echo%20%22%24line%22%20%7C%20awk%20%27%7Bprint%242%7D%27%29%0A%20%20podman%20image%20exists%20%24uri%0A%20%20if%20%5B%5B%20%24%3F%20-eq%200%20%5D%5D%3B%20then%0A%20%20%20%20%20%20echo%20%22Skipping%20existing%20image%20%24tar%22%0A%20%20%20%20%20%20echo%20%22Copying%20%24%7Buri%7D%20%5B%24%7Bcurrent_copy%7D%2F%24%7Btotal_copies%7D%5D%22%0A%20%20%20%20%20%20current_copy%3D%24%28%28current_copy%20%2B%201%29%29%0A%20%20%20%20%20%20continue%0A%20%20fi%0A%20%20tar%3D%24%28echo%20%22%24uri%22%20%7C%20%20rev%20%7C%20cut%20-d%20%22%2F%22%20-f1%20%7C%20rev%20%7C%20tr%20%22%3A%22%20%22_%22%29%0A%20%20tar%20zxvf%20%24%7Btar%7D.tgz%0A%20%20if%20%5B%20%24%3F%20-eq%200%20%5D%3B%20then%20rm%20-f%20%24%7Btar%7D.gz%3B%20fi%0A%20%20echo%20%22Copying%20%24%7Buri%7D%20%5B%24%7Bcurrent_copy%7D%2F%24%7Btotal_copies%7D%5D%22%0A%20%20skopeo%20copy%20dir%3A%2F%2F%24%28pwd%29%2F%24%7Btar%7D%20containers-storage%3A%24%7Buri%7D%0A%20%20if%20%5B%20%24%3F%20-eq%200%20%5D%3B%20then%20rm%20-rf%20%24%7Btar%7D%3B%20current_copy%3D%24%28%28current_copy%20%2B%201%29%29%3B%20fi%0Adone%20%3C%20%24%7BBINARY_FOLDER%7D%2F%24%7BOCP_RELEASE_LIST%7D%0A%0A%23%20workaround%20while%20https%3A%2F%2Fgithub.com%2Fopenshift%2Fassisted-service%2Fpull%2F3546%0A%23cp%20%2Fvar%2Fmnt%2Fmodified-rhcos-4.10.3-x86_64-metal.x86_64.raw.gz%20%2Fvar%2Ftmp%2F.%0A%0Aexit%200"
              }
            },
            {
              "overwrite": true,
              "path": "/usr/local/bin/agent-fix-bz1964591",
              "mode": 755,
              "user": {
                "name": "root"
              },
              "contents": {
                "source": "data:,%23%21%2Fusr%2Fbin%2Fsh%0A%0A%23%20This%20script%20is%20a%20workaround%20for%20bugzilla%201964591%20where%20symlinks%20inside%20%2Fvar%2Flib%2Fcontainers%2F%20get%0A%23%20corrupted%20under%20some%20circumstances.%0A%23%0A%23%20In%20order%20to%20let%20agent.service%20start%20correctly%20we%20are%20checking%20here%20whether%20the%20requested%0A%23%20container%20image%20exists%20and%20in%20case%20%22podman%20images%22%20returns%20an%20error%20we%20try%20removing%20the%20faulty%0A%23%20image.%0A%23%0A%23%20In%20such%20a%20scenario%20agent.service%20will%20detect%20the%20image%20is%20not%20present%20and%20pull%20it%20again.%20In%20case%0A%23%20the%20image%20is%20present%20and%20can%20be%20detected%20correctly%2C%20no%20any%20action%20is%20required.%0A%0AIMAGE%3D%24%28echo%20%241%20%7C%20sed%20%27s%2F%3A.%2A%2F%2F%27%29%0Apodman%20image%20exists%20%24IMAGE%20%7C%7C%20echo%20%22already%20loaded%22%20%7C%7C%20echo%20%22need%20to%20be%20pulled%22%0A%23podman%20images%20%7C%20grep%20%24IMAGE%20%7C%7C%20podman%20rmi%20--force%20%241%20%7C%7C%20true"
              }
            }
          ]
        }
      }'
    nodes:
      - hostName: "snonode.sno-worker-0.example.domain.redhat.com"
        role: "master"
        bmcAddress: "idrac-virtualmedia+https://10.19.28.53/redfish/v1/Systems/System.Embedded.1"
        bmcCredentialsName:
          name: "worker0-bmh-secret"
        bootMACAddress: "e4:43:4b:bd:90:46"
        bootMode: "UEFI"
        rootDeviceHints:
          deviceName: /dev/disk/by-path/pci-0000:01:00.0-scsi-0:2:0:0
        installerArgs: '["--save-partlabel", "data"]'
        ignitionConfigOverride: |
           {
            "ignition": {
              "version": "3.1.0"
            },
            "systemd": {
              "units": [
                {
                  "name": "var-mnt.mount",
                  "enabled": true,
                  "contents": "[Unit]\nDescription=Mount partition with artifacts\nBefore=precache-ocp-images.service\nBindsTo=precache-ocp-images.service\nStopWhenUnneeded=true\n\n[Mount]\nWhat=/dev/disk/by-partlabel/data\nWhere=/var/mnt\nType=xfs\nTimeoutSec=30\n\n[Install]\nRequiredBy=precache-ocp-images.service"
                },
                {
                  "name": "precache-ocp-images.service",
                  "enabled": true,
                  "contents": "[Unit]\nDescription=Extracts the precached OCP images into containers storage\nAfter=var-mnt.mount\nBefore=machine-config-daemon-pull.service nodeip-configuration.service\n\n[Service]\nType=oneshot\nUser=root\nWorkingDirectory=/var/mnt\nExecStart=bash /usr/local/bin/extract-ocp.sh\nTimeoutStopSec=60\n\n[Install]\nWantedBy=multi-user.target"
                }
              ]
            },
            "storage": {
              "files": [
                {
                  "overwrite": true,
                  "path": "/usr/local/bin/extract-ocp.sh",
                  "mode": 755,
                  "user": {
                    "name": "root"
                  },
                  "contents": {
                    "source": "data:,%23%21%2Fbin%2Fbash%0A%0AFOLDER%3D%22%24%7BFOLDER%3A-%24%28pwd%29%7D%22%0AOCP_RELEASE_LIST%3D%22%24%7BOCP_RELEASE_LIST%3A-ocp-images.txt%7D%22%0ABINARY_FOLDER%3D%2Fvar%2Fmnt%0A%0Apushd%20%24FOLDER%0A%0Atotal_copies%3D%24%28sort%20-u%20%24BINARY_FOLDER%2F%24OCP_RELEASE_LIST%20%7C%20wc%20-l%29%20%20%23%20Required%20to%20keep%20track%20of%20the%20pull%20task%20vs%20total%0Acurrent_copy%3D1%0A%0Awhile%20read%20-r%20line%3B%0Ado%0A%20%20uri%3D%24%28echo%20%22%24line%22%20%7C%20awk%20%27%7Bprint%241%7D%27%29%0A%20%20%23tar%3D%24%28echo%20%22%24line%22%20%7C%20awk%20%27%7Bprint%242%7D%27%29%0A%20%20podman%20image%20exists%20%24uri%0A%20%20if%20%5B%5B%20%24%3F%20-eq%200%20%5D%5D%3B%20then%0A%20%20%20%20%20%20echo%20%22Skipping%20existing%20image%20%24tar%22%0A%20%20%20%20%20%20echo%20%22Copying%20%24%7Buri%7D%20%5B%24%7Bcurrent_copy%7D%2F%24%7Btotal_copies%7D%5D%22%0A%20%20%20%20%20%20current_copy%3D%24%28%28current_copy%20%2B%201%29%29%0A%20%20%20%20%20%20continue%0A%20%20fi%0A%20%20tar%3D%24%28echo%20%22%24uri%22%20%7C%20%20rev%20%7C%20cut%20-d%20%22%2F%22%20-f1%20%7C%20rev%20%7C%20tr%20%22%3A%22%20%22_%22%29%0A%20%20tar%20zxvf%20%24%7Btar%7D.tgz%0A%20%20if%20%5B%20%24%3F%20-eq%200%20%5D%3B%20then%20rm%20-f%20%24%7Btar%7D.gz%3B%20fi%0A%20%20echo%20%22Copying%20%24%7Buri%7D%20%5B%24%7Bcurrent_copy%7D%2F%24%7Btotal_copies%7D%5D%22%0A%20%20skopeo%20copy%20dir%3A%2F%2F%24%28pwd%29%2F%24%7Btar%7D%20containers-storage%3A%24%7Buri%7D%0A%20%20if%20%5B%20%24%3F%20-eq%200%20%5D%3B%20then%20rm%20-rf%20%24%7Btar%7D%3B%20current_copy%3D%24%28%28current_copy%20%2B%201%29%29%3B%20fi%0Adone%20%3C%20%24%7BBINARY_FOLDER%7D%2F%24%7BOCP_RELEASE_LIST%7D%0A%0Aexit%200"
                  }
                }
              ]
            }
           }
        nodeNetwork:
          config:
            interfaces:
              - name: ens1f0
                type: ethernet
                state: up
                macAddress: "AA:BB:CC:11:22:33"
                ipv4:
                  enabled: true
                  dhcp: true
                ipv6:
                  enabled: false
          interfaces:
            - name: "ens1f0"
              macAddress: "AA:BB:CC:11:22:33"

1
spec.clusters.clusterImageSetNameRef 필드에 다른 이미지 세트를 지정하지 않는 한 배포에 사용되는 클러스터 이미지 세트를 지정합니다.
2
개별 클러스터를 배포하는 데 사용되는 클러스터 이미지 세트를 지정합니다. 정의된 경우 사이트 수준에서 spec.clusterImageSetNameRef 를 덮어씁니다.
18.14.5.1. cluster.ignitionConfigOverride 필드 이해

clusters.ignitionConfigOverride 필드는 GitOps ZTP 검색 단계에서 Ignition 형식으로 구성을 추가합니다. 구성에는 가상 미디어에 마운트된 ISO의 systemd 서비스가 포함됩니다. 이렇게 하면 스크립트는 검색 RHCOS 라이브 ISO의 일부이며 지원 설치 관리자(AI) 이미지를 로드하는 데 사용할 수 있습니다.

systemd 서비스
systemd 서비스는 var-mnt.mountprecache-images.services 입니다. precache-images.servicevar-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 스크립트에서 요청된 컨테이너 이미지가 존재하는지 확인합니다.
18.14.5.2. nodes.installerArgs 필드 이해

nodes.installerArgs 필드를 사용하면 coreos-installer 유틸리티에서 RHCOS 라이브 ISO를 디스크에 쓰는 방법을 구성할 수 있습니다. 데이터 파티션에 저장된 아티팩트가 OpenShift Container Platform 설치 단계에서 필요하므로 레이블이 지정된 디스크 파티션을 데이터로 저장하려면 지정해야 합니다.

추가 매개변수는 라이브 RHCOS를 디스크에 쓰는 coreos-installer 유틸리티로 직접 전달됩니다. 다음 재부팅 시 운영 체제가 디스크에서 시작됩니다.

coreos-installer 유틸리티에 여러 옵션을 전달할 수 있습니다.

OPTIONS:
...
    -u, --image-url <URL>
            Manually specify the image URL

    -f, --image-file <path>
            Manually specify a local image file

    -i, --ignition-file <path>
            Embed an Ignition config from a file

    -I, --ignition-url <URL>
            Embed an Ignition config from a URL
...
        --save-partlabel <lx>...
            Save partitions with this label glob

        --save-partindex <id>...
            Save partitions with this number or range
...
        --insecure-ignition
            Allow Ignition URL without HTTPS or hash
18.14.5.3. nodes.ignitionConfigOverride 필드 이해

cluster .ignitionConfigOverride 와 마찬가지로 nodes.ignitionConfigOverride 필드를 사용하면 Ignition 형식의 구성을 coreos-installer 유틸리티에 추가할 수 있지만 OpenShift Container Platform 설치 단계에서 구성을 추가할 수 있습니다. RHCOS가 디스크에 기록되면 GitOps ZTP 검색 ISO에 포함된 추가 구성을 더 이상 사용할 수 없습니다. 검색 단계에서 추가 구성이 라이브 OS의 메모리에 저장됩니다.

참고

이 단계에서는 추출 및 로드된 컨테이너 이미지의 수가 검색 단계보다 큽니다. OpenShift Container Platform 릴리스 및 Day-2 Operator 설치 여부에 따라 설치 시간이 다를 수 있습니다.

설치 단계에서 var-mnt.mountprecache-ocp.services systemd 서비스가 사용됩니다.

precache-ocp.service

precache-ocp.servicevar-mnt.mount 단위의 /var/mnt 에 마운트할 디스크 파티션에 따라 다릅니다. precache-ocp.service 서비스는 extract-ocp.sh 라는 스크립트를 호출합니다.

중요

OpenShift Container Platform 설치 전에 모든 이미지를 추출하려면 machine-config-daemon-pull.servicenodeip-configuration.service 서비스를 실행하기 전에 precache-ocp.service 를 실행해야 합니다.

extract-ocp.sh
extract-ocp.sh 스크립트는 디스크 파티션의 필수 이미지를 추출하고 로컬 컨테이너 스토리지로 로드합니다. 스크립트가 성공적으로 완료되면 이미지를 로컬에서 사용할 수 있습니다.

Argo CD가 모니터링되는 Git 리포지터리에 site ConfigPolicyGenTemplates CR(사용자 정의 리소스)을 업로드할 때 허브 클러스터와 CR을 동기화하여 GitOps ZTP 워크플로를 시작할 수 있습니다.

18.14.6. 문제 해결

18.14.6.1. 렌더링된 카탈로그가 유효하지 않음

로컬 또는 연결이 끊긴 레지스트리를 사용하여 이미지를 다운로드하는 경우 렌더링된 카탈로그가 유효하지 않은 오류가 표시될 수 있습니다. 즉, 콘텐츠를 가져오려는 새 레지스트리의 인증서가 누락되어 있습니다.

참고

factory-precaching-cli 툴 이미지는 UBI RHEL 이미지를 기반으로 합니다. 인증서 경로와 위치는 RHCOS에서 동일합니다.

오류 예

Generating list of pre-cached artifacts...
error: unable to run command oc-mirror -c /mnt/imageset.yaml file:///tmp/fp-cli-3218002584/mirror --ignore-history --dry-run: Creating directory: /tmp/fp-cli-3218002584/mirror/oc-mirror-workspace/src/publish
Creating directory: /tmp/fp-cli-3218002584/mirror/oc-mirror-workspace/src/v2
Creating directory: /tmp/fp-cli-3218002584/mirror/oc-mirror-workspace/src/charts
Creating directory: /tmp/fp-cli-3218002584/mirror/oc-mirror-workspace/src/release-signatures
backend is not configured in /mnt/imageset.yaml, using stateless mode
backend is not configured in /mnt/imageset.yaml, using stateless mode
No metadata detected, creating new workspace
level=info msg=trying next host error=failed to do request: Head "https://eko4.cloud.lab.eng.bos.redhat.com:8443/v2/redhat/redhat-operator-index/manifests/v4.11": x509: certificate signed by unknown authority host=eko4.cloud.lab.eng.bos.redhat.com:8443

The rendered catalog is invalid.

Run "oc-mirror list operators --catalog CATALOG-NAME --package PACKAGE-NAME" for more information.

error: error rendering new refs: render reference "eko4.cloud.lab.eng.bos.redhat.com:8443/redhat/redhat-operator-index:v4.11": error resolving name : failed to do request: Head "https://eko4.cloud.lab.eng.bos.redhat.com:8443/v2/redhat/redhat-operator-index/manifests/v4.11": x509: certificate signed by unknown authority

프로세스

  1. 레지스트리 인증서를 서버에 복사합니다.

    # cp /tmp/eko4-ca.crt /etc/pki/ca-trust/source/anchors/.
  2. 인증서 신뢰 저장소를 업데이트합니다.

    # update-ca-trust
  3. host /etc/pki 폴더를 factory-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.14.0 --acm-version 2.5.4 \
       --mce-version 2.0.4 -f /mnt \--img quay.io/custom/repository
       --du-profile -s --skip-imageset

Legal Notice

Copyright © 2024 Red Hat, Inc.

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.

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다. 최신 업데이트를 확인하세요.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.