확장 및 성능


OpenShift Container Platform 4.17

프로덕션 환경에서 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 사양

Telco 코어 참조 설계 사양

계획, 최적화 및 측정

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

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.17 클러스터를 설명합니다.

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

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

Red Hat 및 인증된 파트너는 OpenShift Container Platform 4.17 클러스터에서 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.17 참조 설계 개요

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

3.2.1.1. 배포 아키텍처 개요

중앙 집중식 관리형 RHACM 허브 클러스터에서 관리되는 클러스터에 telco RAN DU 4.17 참조 구성을 배포합니다. 참조 설계 사양(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 사용자 애플리케이션 및 워크로드는 다음과 같은 모범 사례 및 애플리케이션 제한을 준수해야 합니다.

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

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

    참고

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

이 사양에 설명된 참조 DU 애플리케이션 워크로드의 차원을 준수하는 테스트 워크로드는 openshift-kni/du-test-workloads 에서 확인할 수 있습니다.

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])
    Copy to Clipboard Toggle word wrap
  • 애플리케이션 로그는 플랫폼 로그 수집기에 의해 수집되지 않습니다.
  • 기본 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 를 기본 구성으로 설정합니다.

    중요

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

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

Expand
표 3.1. 참조 애플리케이션 로드 아래의 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.17 참조 설계 구성 요소

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

3.2.3.1. 호스트 펌웨어 튜닝
이번 릴리스의 새로운 기능
  • GitOps ZTP로 배포하는 관리 클러스터의 호스트 펌웨어 설정을 구성할 수 있습니다.
설명
초기 클러스터 배포 중에 최적의 성능을 위해 호스트 펌웨어 설정을 조정합니다. 관리 클러스터 호스트 펌웨어 설정은 hub 클러스터에서 site Config CR 및 GitOps ZTP를 사용하여 관리 클러스터를 배포할 때 생성되는 BareMetalHost CR(사용자 정의 리소스)으로 사용할 수 있습니다.
제한 및 요구사항
  • 하이퍼 스레딩을 활성화해야 합니다.
엔지니어링 고려 사항
  • 최대 성능을 위해 모든 설정을 조정합니다.
  • 전원 비용 절감을 위해 튜닝하지 않는 한 모든 설정은 최대 성능을 위해 예상됩니다.
  • 필요에 따라 성능 저하를 위해 호스트 펌웨어를 조정할 수 있습니다.
  • 보안 부팅을 활성화합니다. 보안 부팅이 활성화되면 서명된 커널 모듈만 커널에 의해 로드됩니다. 트리 외부 드라이버는 지원되지 않습니다.
3.2.3.2. Node Tuning Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

성능 프로필을 생성하여 클러스터 성능을 조정합니다.

중요

RAN DU 사용 사례를 사용하려면 대기 시간이 짧은 성능을 위해 클러스터를 조정해야 합니다.

제한 및 요구사항

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 선호도 설정 찾기"를 참조하십시오.

cpu CryostatingMode: AllNodes 설정을 사용하여 클러스터 배포 중에 워크로드 파티셔닝을 활성화하면 PerformanceProfile CR에 예약된 CPU가 운영 체제, 인터럽트 및 OpenShift 플랫폼 Pod에 충분한 CPU를 포함해야 합니다.

중요

cgroup v1은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

3.2.3.3. PTP Operator
이번 릴리스의 새로운 기능
  • 새로운 버전 두 가지 PTP(Precision Time Protocol) 빠른 이벤트 REST API를 사용할 수 있습니다. 소비자 애플리케이션은 PTP 이벤트 생산자 사이드카의 이벤트 REST API에 직접 등록할 수 있습니다. PTP 빠른 이벤트 REST API v2는 이벤트 소비자 3.0의 O-RAN O-Cloud 알림 API 사양을 준수합니다. PtpOperatorConfig 리소스에서 ptpEventConfig.apiVersion 필드를 설정하여 API 버전을 변경할 수 있습니다.
설명

클러스터 노드에서 PTP 지원 및 구성에 대한 자세한 내용은 "Recommended single-node OpenShift cluster configuration for vDU 애플리케이션 워크로드"에서 참조하십시오. DU 노드는 다음 모드에서 실행할 수 있습니다.

  • 일반 클럭(OC)은 마스터 클록 또는 경계 클록(T-BC)에 동기화되었습니다.
  • 마스터 클록 (T-GM)은 단일 또는 듀얼 카드 E810 NIC를 지원하는 GPS에서 동기화되었습니다.
  • E810 NIC를 지원하는 이중 경계 클럭( NIC당 하나씩)입니다.
  • 다른 NIC에 시간 소스가 여러 개인 경우 HA(고가용성) 시스템 시계가 있는 T-BC입니다.
  • 선택 사항: 라디오 장치(RU)의 경계 클럭입니다.
제한 및 요구사항
  • 듀얼 NIC 및 HA에 대한 두 개의 경계 클럭으로 제한됩니다.
  • T-GM의 두 카드 E810 구성으로 제한됩니다.
엔지니어링 고려 사항
  • 일반 클럭, 경계 클럭, 고가용성 시스템 시계가 있는 경계 클록 및 마스터 클록에 대한 구성이 제공됩니다.
  • PTP 빠른 이벤트 알림은 ConfigMap CR을 사용하여 PTP 이벤트 서브스크립션을 저장합니다.
  • PTP 이벤트 REST API v2에는 리소스 경로에 포함된 모든 하위 계층 리소스에 대한 글로벌 서브스크립션이 없습니다. 사용 가능한 다양한 이벤트 유형에 소비자 애플리케이션을 별도로 서브스크립션합니다.
3.2.3.4. SR-IOV Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
SR-IOV Operator는 SR-IOV CNI 및 장치 플러그인을 프로비저닝하고 구성합니다. netdevice (커널 VF) 및 DPDK ( Vfio) 장치가 모두 지원되며 RAN 사용 모델에 적용됩니다.
제한 및 요구사항
  • OpenShift Container Platform 지원 장치 사용
  • BIOS에서 SR-IOV 및 IOMMU 활성화: SR-IOV Network Operator는 커널 명령줄에서 IOMMU를 자동으로 활성화합니다.
  • SR-IOV VF는 PF에서 링크 상태 업데이트를 수신하지 않습니다. 링크 다운 탐지가 필요한 경우 프로토콜 수준에서 이를 구성해야 합니다.
  • Secure Boot 또는 커널 잠금을 사용하는 펌웨어 업데이트를 지원하지 않는 NIC는 애플리케이션 워크로드에 필요한 VF 수를 지원하기 위해 충분한 VF(가상 기능)로 사전 구성해야 합니다.

    참고

    문서화되지 않은 disablePlugins 옵션을 사용하여 지원되지 않는 NIC에 대해 SR-IOV Operator 플러그인을 비활성화해야 할 수 있습니다.

엔지니어링 고려 사항
  • vfio 드라이버 유형의 SR-IOV 인터페이스는 일반적으로 높은 처리량 또는 짧은 대기 시간이 필요한 애플리케이션의 보조 네트워크를 활성화하는 데 사용됩니다.
  • SriovNetworkSriovNetworkNodePolicy 고객 리소스 (CR)의 구성과 수에 대한 고객의 변화가 예상됩니다.
  • IOMMU 커널 명령줄 설정은 설치 시 MachineConfig CR에 적용됩니다. 이렇게 하면 SriovOperator CR에서 노드를 추가할 때 노드가 재부팅되지 않습니다.
  • 노드를 병렬로 드레이닝하는 SR-IOV 지원은 단일 노드 OpenShift 클러스터에는 적용되지 않습니다.
  • 배포에서 SriovOperatorConfig CR을 제외하면 CR이 자동으로 생성되지 않습니다.
  • 워크로드를 특정 노드로 고정하거나 제한하는 시나리오에서는 SR-IOV 병렬 노드 드레이닝 기능으로 인해 Pod 일정이 변경되지 않습니다. 이러한 시나리오에서 SR-IOV Operator는 병렬 노드 드레이닝 기능을 비활성화합니다.
3.2.3.5. 로깅
이번 릴리스의 새로운 기능
  • 이번 릴리스에서는 Cluster Logging Operator 6.0이 새로 추가되었습니다. 새 API 버전에 맞게 기존 구현을 업데이트합니다.
설명
로깅을 사용하여 원격 분석을 위해 far edge 노드에서 로그를 수집합니다. 권장되는 로그 수집기는 Vector입니다.
엔지니어링 고려 사항
  • 예를 들어, 인프라 및 감사 로그 이외의 로그를 처리하려면 추가 로깅 속도를 기반으로 하는 추가 CPU 및 네트워크 대역폭이 필요합니다.
  • OpenShift Container Platform 4.14부터 Vector는 참조 로그 수집기입니다.

    참고

    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 을 사용해야 합니다. Pod의 애플리케이션은 EAL 매개변수 --vfio-vf-token 을 사용하여 VF 토큰을 DPDK에 전달할 수 있습니다.
엔지니어링 고려 사항
  • SRIOV-FEC Operator는 분리된 CPU 세트의 CPU 코어를 사용합니다.
  • 예를 들어 검증 정책을 확장하여 FEC 준비 상태를 사전 점검의 일부로 검증할 수 있습니다.
3.2.3.7. 라이프사이클 에이전트
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
Lifecycle Agent는 단일 노드 OpenShift 클러스터에 대한 로컬 라이프사이클 관리 서비스를 제공합니다.
제한 및 요구사항
  • Lifecycle Agent는 추가 작업자가 있는 다중 노드 클러스터 또는 단일 노드 OpenShift 클러스터에는 적용되지 않습니다.
  • 클러스터를 설치할 때 생성하는 영구 볼륨이 필요합니다. 파티션 요구 사항은 GitOps ZTP를 사용할 때 "ostree stateroots 간 공유 컨테이너 디렉터리 구성"을 참조하십시오.
3.2.3.8. Local Storage Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
Local Storage Operator를 사용하여 애플리케이션에서 PVC 리소스로 사용할 수 있는 영구 볼륨을 생성할 수 있습니다. 생성하는 PV 리소스의 수 및 유형은 요구 사항에 따라 다릅니다.
엔지니어링 고려 사항
  • PV 를 생성하기 전에 PV CR에 대한 백업 스토리지를 생성합니다. 파티션, 로컬 볼륨, LVM 볼륨 또는 전체 디스크일 수 있습니다.
  • 디스크 및 파티션을 올바르게 할당하도록 각 장치에 액세스하는 데 사용되는 하드웨어 경로에서 LocalVolume CR의 장치 목록을 참조하십시오. 논리 이름(예: /dev/sda)은 노드를 재부팅해도 일관성이 보장되지 않습니다.

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

3.2.3.9. LVM 스토리지
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
참고

LVM(Logical Volume Manager) 스토리지는 선택적 구성 요소입니다.

LVM 스토리지를 스토리지 솔루션으로 사용하면 Local Storage Operator를 대체합니다. CPU 리소스는 플랫폼 오버헤드로 관리 파티션에 할당됩니다. 참조 구성에는 이러한 스토리지 솔루션 중 하나가 포함되어야 하지만 둘 다 포함되지는 않습니다.

설명
LVM 스토리지는 블록 및 파일 스토리지에 대한 동적 프로비저닝을 제공합니다. LVM 스토리지는 애플리케이션에서 PVC 리소스로 사용할 수 있는 로컬 장치에서 논리 볼륨을 생성합니다. 볼륨 확장 및 스냅샷도 가능합니다.
제한 및 요구사항
  • 단일 노드 OpenShift 클러스터에서 영구 스토리지는 둘 다 아닌 LVM 스토리지 또는 로컬 스토리지에서 제공해야 합니다.
  • 볼륨 스냅샷은 참조 구성에서 제외됩니다.
엔지니어링 고려 사항
  • LVM 스토리지는 RAN DU 사용 사례의 로컬 스토리지 구현으로 사용할 수 있습니다. LVM 스토리지를 스토리지 솔루션으로 사용하면 Local Storage Operator가 교체되고 필요한 CPU가 플랫폼 오버헤드로 관리 파티션에 할당됩니다. 참조 구성에는 이러한 스토리지 솔루션 중 하나가 포함되어야 하지만 둘 다 포함되지는 않습니다.
  • 스토리지 요구 사항에 충분한 디스크 또는 파티션을 사용할 수 있는지 확인합니다.
3.2.3.10. 워크로드 파티셔닝
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
워크로드 파티셔닝은 DU 프로파일의 일부인 OpenShift 플랫폼과 Day 2 Operator Pod를 예약된 CPU 세트에 고정하고 노드 회계에서 예약된 CPU를 제거합니다. 이렇게 하면 사용자 워크로드에서 예약되지 않은 모든 CPU 코어를 사용할 수 있습니다.
제한 및 요구사항
  • Pod 를 관리 파티션에 적용할 수 있도록 네임스페이스 및 Pod CR에 주석을 달 수 있어야 합니다.
  • CPU 제한이 있는 Pod는 파티션에 할당할 수 없습니다. 변경으로 Pod QoS를 변경할 수 있기 때문입니다.
  • 관리 파티션에 할당할 수 있는 최소 CPU 수에 대한 자세한 내용은 Node Tuning Operator 를 참조하십시오.
엔지니어링 고려 사항
  • 워크로드 파티셔닝은 모든 관리 Pod를 예약된 코어에 고정합니다. 워크로드 시작, 노드 재부팅 또는 기타 시스템 이벤트가 발생할 때 발생하는 CPU 사용 급증을 고려하여 예약된 세트에 코어 수를 할당해야 합니다.
3.2.3.11. 클러스터 튜닝
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
설치 전에 활성화하거나 비활성화할 수 있는 선택적 구성 요소의 전체 목록은 "클러스터 기능"을 참조하십시오.
제한 및 요구사항
  • 설치 관리자가 프로비저닝한 설치 방법에서는 클러스터 기능을 사용할 수 없습니다.
  • 모든 플랫폼 튜닝 구성을 적용해야 합니다. 다음 표에는 필요한 플랫폼 튜닝 구성이 나열되어 있습니다.

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

    선택적 클러스터 기능 제거

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

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

    클러스터 모니터링 구성

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

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

      참고

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

    네트워킹 진단 비활성화

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

    단일 OperatorHub 카탈로그 소스 구성

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

    Console Operator 비활성화

    콘솔이 비활성화된 콘솔과 함께 클러스터가 배포된 경우 Console CR(ConsoleOperatorDisable.yaml)이 필요하지 않습니다. 콘솔이 활성화된 상태에서 클러스터가 배포된 경우 Console CR을 적용해야 합니다.

엔지니어링 고려 사항
  • OpenShift Container Platform 4.16 이상에서는 PerformanceProfile CR을 적용할 때 클러스터에서 cgroups v1로 자동 되돌리지 않습니다. 클러스터에서 실행되는 워크로드에 cgroup v1이 필요한 경우 cgroups v1을 사용하도록 클러스터를 구성해야 합니다.

    참고

    cgroups v1을 구성해야 하는 경우 구성을 초기 클러스터 배포의 일부로 설정합니다.

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

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

    컨테이너 런타임

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

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

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

    SCTP

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

    kdump

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

    참고

    kdump를 활성화하는 참조 CR에는 참조 구성에 포함된 드라이버 및 커널 모듈 세트에 따라 메모리 예약이 증가합니다.

    CRI-O 제거 비활성화

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

    SR-IOV 관련 커널 인수

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

    RCU 일반 systemd 서비스

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

    일회성 시간 동기화

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

3.2.3.13. Telco RAN DU 배포 구성 요소

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

3.2.3.13.1. Red Hat Advanced Cluster Management
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

RHACM(Red Hat Advanced Cluster Management)은 배포된 클러스터에 대한 MCE(Multi Cluster Engine) 설치 및 지속적인 라이프사이클 관리 기능을 제공합니다. 유지 관리 기간 중 클러스터에 정책 CR(사용자 정의 리소스)을 적용하여 클러스터 구성과 업그레이드를 선언적으로 관리합니다.

토폴로지 Aware Lifecycle Manager(TALM)에서 관리하는 대로 RHACM 정책 컨트롤러를 사용하여 정책을 적용합니다. 정책 컨트롤러는 구성, 업그레이드 및 클러스터 상태를 처리합니다.

관리형 클러스터를 설치할 때 RHACM은 사용자 지정 디스크 파티셔닝, 역할 할당 및 머신 구성 풀에 할당을 지원하기 위해 라벨을 개별 노드에 적용합니다. SiteConfig 또는 ClusterInstance CR을 사용하여 이러한 구성을 정의합니다.

제한 및 요구사항
  • ArgoCD 애플리케이션당 300개의 SiteConfig CR. 여러 애플리케이션을 사용하여 단일 허브 클러스터에서 지원하는 최대 클러스터 수를 달성할 수 있습니다.
  • 단일 허브 클러스터는 5 Policy CR이 각 클러스터에 바인딩된 최대 3500개의 배포된 단일 노드 OpenShift 클러스터를 지원합니다.
엔지니어링 고려 사항
  • RHACM 정책 허브 측 템플릿을 사용하여 클러스터 구성을 보다 효과적으로 확장할 수 있습니다. 단일 그룹 정책 또는 그룹과 클러스터별 값이 템플릿으로 대체되는 일반 그룹 정책 수를 사용하여 정책 수를 크게 줄일 수 있습니다.
  • 클러스터별 구성: 관리 클러스터에는 일반적으로 개별 클러스터에 고유한 몇 가지 구성 값이 있습니다. 이러한 구성은 클러스터 이름을 기반으로 ConfigMap CR에서 가져온 값을 사용하여 RHACM 정책 허브 쪽 템플릿을 사용하여 관리해야 합니다.
  • 관리 클러스터에 CPU 리소스를 저장하려면 클러스터의 GitOps ZTP 설치 후 정적 구성을 적용하는 정책을 관리 클러스터에서 바인딩해야 합니다.
3.2.3.13.2. 토폴로지 인식 라이프사이클 관리자
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
TALM( topology Aware Lifecycle Manager)은 클러스터 및 Operator 업그레이드, 구성 등을 포함한 변경 사항이 네트워크로 롤아웃되는 방식을 관리하기 위해 허브 클러스터에서만 실행되는 Operator입니다.
제한 및 요구사항
  • TALM은 400 배치로 동시 클러스터 배포를 지원합니다.
  • 사전 캐싱 및 백업 기능은 단일 노드 OpenShift 클러스터에만 사용할 수 있습니다.
엔지니어링 고려 사항
  • ran.openshift.io/ztp-deploy- ECDSA 주석이 있는 정책만 초기 클러스터 설치 중에 TALM에 의해 자동으로 적용됩니다.
  • 추가 ClusterGroupUpgrade CR을 생성하여 TALM이 수정하는 정책을 제어할 수 있습니다.
3.2.3.13.3. GitOps 및 GitOps ZTP 플러그인
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

GitOps 및 GitOps ZTP 플러그인은 클러스터 배포 및 구성을 관리하기 위한 GitOps 기반 인프라를 제공합니다. 클러스터 정의 및 구성은 Git에서 선언적 상태로 유지됩니다. site Config Operator가 설치 CR로 렌더링하는 허브 클러스터에 ClusterInstance CR을 적용할 수 있습니다. 또는 GitOps ZTP 플러그인을 사용하여 SiteConfig CR에서 직접 설치 CR을 생성할 수 있습니다. GitOps ZTP 플러그인은 PolicyGenTemplate CR을 기반으로 하는 정책의 구성 CR 자동 래핑을 지원합니다.

참고

기준 참조 구성 CR을 사용하여 관리형 클러스터에서 여러 버전의 OpenShift Container Platform을 배포하고 관리할 수 있습니다. 기준 CR과 함께 사용자 정의 CR을 사용할 수 있습니다.

여러 버전별 정책을 동시에 유지하려면 Git을 사용하여 소스 CR 및 정책 CR 버전(PolicyGenTemplate 또는 PolicyGenerator)을 관리합니다.

참조 CR 및 사용자 정의 CR을 다른 디렉터리에 보관합니다. 이렇게 하면 사용자 정의 CR을 건드리지 않고 모든 디렉터리 콘텐츠를 간단하게 교체하여 참조 CR을 패치하고 업데이트할 수 있습니다.

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

    참고

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

  • SiteConfig CR의 extraManifestPath 필드는 OpenShift Container Platform 4.15 이상에서 더 이상 사용되지 않습니다. 대신 새로운 extraManifests.searchPaths 필드를 사용합니다.
엔지니어링 고려 사항
  • 멀티 노드 클러스터 업그레이드의 경우 paused 필드를 true 로 설정하여 유지 관리 기간 동안 MachineConfigPool (MCP) CR을 일시 중지할 수 있습니다. MCP CR에서 maxUnavailable 설정을 구성하여 MCP 당 노드 수를 동시에 늘릴 수 있습니다. MaxUnavailable 필드는 MachineConfig 업데이트 중에 동시에 사용할 수 없는 풀의 노드 백분율을 정의합니다. maxUnavailable 을 최대 허용 가능한 값으로 설정합니다. 이렇게 하면 업그레이드 중에 클러스터의 재부팅 횟수가 줄어들어 업그레이드 시간이 단축됩니다. MCP CR 일시 중지를 마지막으로 해제하면 변경된 모든 구성이 단일 재부팅으로 적용됩니다.
  • 클러스터 설치 중에 paused 필드를 true 로 설정하고 maxUnavailable 을 100%로 설정하여 설치 시간을 단축하여 사용자 정의 MCP CR을 일시 중지할 수 있습니다.
  • 콘텐츠를 업데이트할 때 파일의 혼동 또는 의도하지 않은 덮어쓰기를 방지하려면 /source-crs 폴더 및 Git의 추가 매니페스트에서 사용자 제공 CR에 대해 고유하고 구분 가능한 이름을 사용합니다.
  • SiteConfig CR을 사용하면 여러 추가 경로가 허용됩니다. 동일한 이름의 파일이 여러 디렉토리 경로에 있는 경우 마지막으로 발견된 파일이 우선합니다. 이를 통해 Git에 버전별 Day 0 매니페스트(extra-manifests)의 전체 세트를 배치하고 site Config CR에서 참조할 수 있습니다. 이 기능을 사용하면 여러 OpenShift Container Platform 버전을 관리 클러스터에 동시에 배포할 수 있습니다.
3.2.3.13.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.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
Expand
표 3.4. 2일차 Operator CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

클러스터 로깅

ClusterLogForwarder.yaml

없음

없음

클러스터 로깅

ClusterLogNS.yaml

없음

없음

클러스터 로깅

ClusterLogOperGroup.yaml

없음

없음

클러스터 로깅

ClusterLogServiceAccount.yaml

없음

제공됨

클러스터 로깅

ClusterLogServiceAccountAuditBinding.yaml

없음

제공됨

클러스터 로깅

ClusterLogServiceAccountInfrastructureBinding.yaml

없음

제공됨

클러스터 로깅

ClusterLogSubscription.yaml

없음

없음

Lifecycle Agent Operator

ImageBasedUpgrade.yaml

제공됨

없음

Lifecycle Agent Operator

LcaSubscription.yaml

제공됨

없음

Lifecycle Agent Operator

LcaSubscriptionNS.yaml

제공됨

없음

Lifecycle Agent Operator

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

제공됨

없음

LVM Operator

LVMOperatorStatus.yaml

제공됨

없음

LVM Operator

StorageLVMCluster.yaml

제공됨

없음

LVM Operator

StorageLVMSubscription.yaml

제공됨

없음

LVM Operator

StorageLVMSubscriptionNS.yaml

제공됨

없음

LVM Operator

StorageLVMSubscriptionOperGroup.yaml

제공됨

없음

Node Tuning Operator

PerformanceProfile.yaml

없음

없음

Node Tuning Operator

TunedPerformancePatch.yaml

없음

없음

PTP 빠른 이벤트 알림

PtpConfigBoundaryForEvent.yaml

제공됨

없음

PTP 빠른 이벤트 알림

PtpConfigForHAForEvent.yaml

제공됨

없음

PTP 빠른 이벤트 알림

PtpConfigMasterForEvent.yaml

제공됨

없음

PTP 빠른 이벤트 알림

PtpConfigSlaveForEvent.yaml

제공됨

없음

PTP Operator - 고가용성

PtpConfigBoundary.yaml

없음

없음

PTP Operator - 고가용성

PtpConfigForHA.yaml

없음

없음

PTP Operator

PtpConfigDualCardGmWpc.yaml

없음

없음

PTP Operator

PtpConfigGmWpc.yaml

없음

없음

PTP Operator

PtpConfigSlave.yaml

없음

없음

PTP Operator

PtpOperatorConfig.yaml

없음

없음

PTP Operator

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

SriovOperatorConfigForSNO.yaml

없음

없음

SR-IOV Operator

SriovSubscription.yaml

없음

없음

SR-IOV Operator

SriovSubscriptionNS.yaml

없음

없음

SR-IOV Operator

SriovSubscriptionOperGroup.yaml

없음

없음

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

구성 가능 OpenShift

example-sno.yaml

없음

없음

콘솔 비활성화

ConsoleOperatorDisable.yaml

제공됨

없음

연결이 끊긴 레지스트리

09-openshift-marketplace-ns.yaml

없음

없음

연결이 끊긴 레지스트리

DefaultCatsrc.yaml

없음

없음

연결이 끊긴 레지스트리

DisableOLMPprof.yaml

없음

없음

연결이 끊긴 레지스트리

DisconnectedICSP.yaml

없음

없음

연결이 끊긴 레지스트리

OperatorHub.yaml

단일 노드 OpenShift 및 다중 노드 클러스터에는 OperatorHub가 필요합니다.

없음

모니터링 구성

ReduceMonitoringFootprint.yaml

없음

없음

네트워크 진단 비활성화

DisableSnoNetworkDiag.yaml

없음

없음

3.2.4.3. 머신 구성 참조 CR
Expand
표 3.6. 머신 구성 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 활성화

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

제공됨

없음

RCU 일반 설정

08-set-rcu-normal-master.yaml

없음

없음

RCU 일반 설정

08-set-rcu-normal-worker.yaml

없음

없음

SR-IOV 관련 커널 인수

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

없음

없음

SR-IOV 관련 커널 인수

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

없음

없음

3.2.4.4. YAML 참조

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

3.2.4.4.1. 2일차 Operator 참조 YAML

ClusterLogForwarder.yaml

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
  annotations: {}
spec:
  # outputs: $outputs
  # pipelines: $pipelines
  serviceAccount:
    name: logcollector
#apiVersion: "observability.openshift.io/v1"
#kind: ClusterLogForwarder
#metadata:
#  name: instance
#  namespace: openshift-logging
# spec:
#   outputs:
#   - type: "kafka"
#     name: kafka-open
#     # below url is an example
#     kafka:
#       url: tcp://10.46.55.190:9092/test
#   filters:
#   - name: test-labels
#     type: openshiftLabels
#     openshiftLabels:
#       label1: test1
#       label2: test2
#       label3: test3
#       label4: test4
#   pipelines:
#   - name: all-to-default
#     inputRefs:
#     - audit
#     - infrastructure
#     filterRefs:
#     - test-labels
#     outputRefs:
#     - kafka-open
#   serviceAccount:
#     name: logcollector
Copy to Clipboard Toggle word wrap

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
  annotations: {}
spec:
  targetNamespaces:
    - openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccount.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: logcollector
  namespace: openshift-logging
  annotations: {}
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountAuditBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-audit-logs-binding
  annotations: {}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-audit-logs
subjects:
  - kind: ServiceAccount
    name: logcollector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountInfrastructureBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-infrastructure-logs-binding
  annotations: {}
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-infrastructure-logs
subjects:
  - kind: ServiceAccount
    name: logcollector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogSubscription.yaml

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

ImageBasedUpgrade.yaml

apiVersion: lca.openshift.io/v1
kind: ImageBasedUpgrade
metadata:
  name: upgrade
spec:
  stage: Idle
  # When setting `stage: Prep`, remember to add the seed image reference object below.
  # seedImageRef:
  #   image: $image
  #   version: $version
Copy to Clipboard Toggle word wrap

LcaSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: lifecycle-agent
  namespace: openshift-lifecycle-agent
  annotations: {}
spec:
  channel: "stable"
  name: lifecycle-agent
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

LcaSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-lifecycle-agent
  annotations:
    workload.openshift.io/allowed: management
  labels:
    kubernetes.io/metadata.name: openshift-lifecycle-agent
Copy to Clipboard Toggle word wrap

LcaSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: lifecycle-agent
  namespace: openshift-lifecycle-agent
  annotations: {}
spec:
  targetNamespaces:
    - openshift-lifecycle-agent
Copy to Clipboard Toggle word wrap

StorageClass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  annotations: {}
  name: example-storage-class
provisioner: kubernetes.io/no-provisioner
reclaimPolicy: Delete
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

StorageNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-local-storage
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

StorageOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-local-storage
  namespace: openshift-local-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-local-storage
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

LVMOperatorStatus.yaml

# This CR verifies the installation/upgrade of the Sriov Network Operator
apiVersion: operators.coreos.com/v1
kind: Operator
metadata:
  name: lvms-operator.openshift-storage
  annotations: {}
status:
  components:
    refs:
      - kind: Subscription
        namespace: openshift-storage
        conditions:
          - type: CatalogSourcesUnhealthy
            status: "False"
      - kind: InstallPlan
        namespace: openshift-storage
        conditions:
          - type: Installed
            status: "True"
      - kind: ClusterServiceVersion
        namespace: openshift-storage
        conditions:
          - type: Succeeded
            status: "True"
            reason: InstallSucceeded
Copy to Clipboard Toggle word wrap

StorageLVMCluster.yaml

apiVersion: lvm.topolvm.io/v1alpha1
kind: LVMCluster
metadata:
  name: lvmcluster
  namespace: openshift-storage
  annotations: {}
spec: {}
#example: creating a vg1 volume group leveraging all available disks on the node
#         except the installation disk.
#  storage:
#    deviceClasses:
#    - name: vg1
#      thinPoolConfig:
#        name: thin-pool-1
#        sizePercent: 90
#        overprovisionRatio: 10
Copy to Clipboard Toggle word wrap

StorageLVMSubscription.yaml

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

StorageLVMSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-storage
  labels:
    workload.openshift.io/allowed: "management"
    openshift.io/cluster-monitoring: "true"
  annotations: {}
Copy to Clipboard Toggle word wrap

StorageLVMSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: lvms-operator-operatorgroup
  namespace: openshift-storage
  annotations: {}
spec:
  targetNamespaces:
    - openshift-storage
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
        [scheduler]
        group.ice-ptp=0:f:10:*:ice-ptp.*
        group.ice-gnss=0:f:10:*:ice-gnss.*
        group.ice-dplls=0:f:10:*:ice-dplls.*
        [service]
        service.stalld=start,enable
        service.chronyd=stop,disable
  recommend:
    - machineConfigLabels:
        machineconfiguration.openshift.io/role: "$mcp"
      priority: 19
      profile: performance-patch
Copy to Clipboard Toggle word wrap

PtpConfigBoundaryForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary"
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      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"
Copy to Clipboard Toggle word wrap

PtpConfigForHAForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-ha
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary-ha"
      ptp4lOpts: ""
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
        haProfiles: "$profile1,$profile2"
  recommend:
    - profile: "boundary-ha"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Toggle word wrap

PtpConfigMasterForEvent.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"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 --summary_interval -4"
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
      ptp4lConf: |
        [global]
        #
        # Default Data Set
        #
        twoStepFlag 1
        slaveOnly 0
        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: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Toggle word wrap

PtpConfigSlaveForEvent.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: du-ptp-slave
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "slave"
      # The interface name is hardware-specific
      interface: $interface
      ptp4lOpts: "-2 -s --summary_interval -4"
      phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16"
      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"
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

PtpConfigForHA.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: boundary-ha
  namespace: openshift-ptp
  annotations: {}
spec:
  profile:
    - name: "boundary-ha"
      ptp4lOpts: ""
      phc2sysOpts: "-a -r -n 24"
      ptpSchedulingPolicy: SCHED_FIFO
      ptpSchedulingPriority: 10
      ptpSettings:
        logReduce: "true"
        haProfiles: "$profile1,$profile2"
  recommend:
    - profile: "boundary-ha"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Toggle word wrap

PtpConfigDualCardGmWpc.yaml

# The grandmaster profile is provided for testing only
# It is not installed on production clusters
# In this example two cards $iface_nic1 and $iface_nic2 are connected via
# SMA1 ports by a cable and $iface_nic2 receives 1PPS signals from $iface_nic1
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 -w -N 8 -R 16 -s $iface_nic1 -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_nic1":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "2 1"
          #  "$iface_nic2":
          #    "U.FL2": "0 2"
          #    "U.FL1": "0 1"
          #    "SMA2": "0 2"
          #    "SMA1": "1 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,248
                - "-P"
                - "29.20"
                - "-p"
                - "CFG-MSG,1,38,248"
              reportOutput: true
      ts2phcOpts: " "
      ts2phcConf: |
        [nmea]
        ts2phc.master 1
        [global]
        use_syslog  0
        verbose 1
        logging_level 7
        ts2phc.pulsewidth 100000000
        #cat /dev/GNSS 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_nic1]
        ts2phc.extts_polarity rising
        ts2phc.extts_correction 0
        [$iface_nic2]
        ts2phc.master 0
        ts2phc.extts_polarity rising
        #this is a measured value in nanoseconds to compensate for SMA cable delay
        ts2phc.extts_correction -10
      ptp4lConf: |
        [$iface_nic1]
        masterOnly 1
        [$iface_nic1_1]
        masterOnly 1
        [$iface_nic1_2]
        masterOnly 1
        [$iface_nic1_3]
        masterOnly 1
        [$iface_nic2]
        masterOnly 1
        [$iface_nic2_1]
        masterOnly 1
        [$iface_nic2_2]
        masterOnly 1
        [$iface_nic2_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 1
        #
        # Clock description
        #
        productDescription ;;
        revisionData ;;
        manufacturerIdentity 00:00:00
        userDescription ;
        timeSource 0x20
  recommend:
    - profile: "grandmaster"
      priority: 4
      match:
        - nodeLabel: "node-role.kubernetes.io/$mcp"
Copy to Clipboard Toggle word wrap

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 -w -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,248
                - "-P"
                - "29.20"
                - "-p"
                - "CFG-MSG,1,38,248"
              reportOutput: true
      ts2phcOpts: " "
      ts2phcConf: |
        [nmea]
        ts2phc.master 1
        [global]
        use_syslog  0
        verbose 1
        logging_level 7
        ts2phc.pulsewidth 100000000
        #cat /dev/GNSS 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"
Copy to Clipboard Toggle word wrap

PtpConfigSlave.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpConfig
metadata:
  name: du-ptp-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"
Copy to Clipboard Toggle word wrap

PtpOperatorConfig.yaml

apiVersion: ptp.openshift.io/v1
kind: PtpOperatorConfig
metadata:
  name: default
  namespace: openshift-ptp
  annotations: {}
spec:
  daemonNodeSelector:
    node-role.kubernetes.io/$mcp: ""
Copy to Clipboard Toggle word wrap

PtpOperatorConfigForEvent.yaml

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

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
Copy to Clipboard Toggle word wrap

PtpSubscriptionNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-ptp
  annotations:
    workload.openshift.io/allowed: management
  labels:
    openshift.io/cluster-monitoring: "true"
Copy to Clipboard Toggle word wrap

PtpSubscriptionOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: ptp-operators
  namespace: openshift-ptp
  annotations: {}
spec:
  targetNamespaces:
    - openshift-ptp
Copy to Clipboard Toggle word wrap

AcceleratorsNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: vran-acceleration-operators
  annotations: {}
Copy to Clipboard Toggle word wrap

AcceleratorsOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: vran-operators
  namespace: vran-acceleration-operators
  annotations: {}
spec:
  targetNamespaces:
    - vran-acceleration-operators
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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: ""
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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: false
  enableOperatorWebhook: false
  logLevel: 0
Copy to Clipboard Toggle word wrap

SriovOperatorConfigForSNO.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: false
  enableOperatorWebhook: false
  # Disable drain is needed for Single Node Openshift
  disableDrain: true
  logLevel: 0
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

SriovSubscriptionNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-sriov-network-operator
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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.16"
  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 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
      # - Ingress is needed for 4.16 and later
      installConfigOverrides: |
        {
          "capabilities": {
            "baselineCapabilitySet": "None",
            "additionalEnabledCapabilities": [
              "NodeTuning",
              "OperatorLifecycleManager",
              "Ingress"
            ]
          }
        }
      # 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: "UEFISecureBoot"
          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-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"
                  }
                ]
              }
            }
          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
Copy to Clipboard Toggle word wrap

ConsoleOperatorDisable.yaml

apiVersion: operator.openshift.io/v1
kind: Console
metadata:
  annotations:
    include.release.openshift.io/ibm-cloud-managed: "false"
    include.release.openshift.io/self-managed-high-availability: "false"
    include.release.openshift.io/single-node-developer: "false"
    release.openshift.io/create-only: "true"
  name: cluster
spec:
  logLevel: Normal
  managementState: Removed
  operatorLogLevel: Normal
Copy to Clipboard Toggle word wrap

09-openshift-marketplace-ns.yaml

# Taken from https://github.com/operator-framework/operator-marketplace/blob/53c124a3f0edfd151652e1f23c87dd39ed7646bb/manifests/01_namespace.yaml
# Update it as the source evolves.
apiVersion: v1
kind: Namespace
metadata:
  annotations:
    openshift.io/node-selector: ""
    workload.openshift.io/allowed: "management"
  labels:
    openshift.io/cluster-monitoring: "true"
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.25
    pod-security.kubernetes.io/audit: baseline
    pod-security.kubernetes.io/audit-version: v1.25
    pod-security.kubernetes.io/warn: baseline
    pod-security.kubernetes.io/warn-version: v1.25
  name: "openshift-marketplace"
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

DisableOLMPprof.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: collect-profiles-config
  namespace: openshift-operator-lifecycle-manager
  annotations: {}
data:
  pprof-config.yaml: |
    disabled: True
Copy to Clipboard Toggle word wrap

DisconnectedICSP.yaml

apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
  name: disconnected-internal-icsp
  annotations: {}
spec:
#    repositoryDigestMirrors:
#    - $mirrors
Copy to Clipboard Toggle word wrap

OperatorHub.yaml

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
  annotations: {}
spec:
  disableAllDefaultSources: true
Copy to Clipboard Toggle word wrap

ReduceMonitoringFootprint.yaml

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

DisableSnoNetworkDiag.yaml

apiVersion: operator.openshift.io/v1
kind: Network
metadata:
  name: cluster
  annotations: {}
spec:
  disableNetworkDiagnostics: true
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

99-crio-disable-wipe-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

99-crio-disable-wipe-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

06-kdump-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

06-kdump-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

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

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

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

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

99-sync-time-once-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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-online.target
            Wants=network-online.target
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecCondition=/bin/bash -c 'systemctl is-enabled chronyd.service --quiet && exit 1 || exit 0'
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service
Copy to Clipboard Toggle word wrap

99-sync-time-once-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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-online.target
            Wants=network-online.target
            [Service]
            Type=oneshot
            TimeoutStartSec=300
            ExecCondition=/bin/bash -c 'systemctl is-enabled chronyd.service --quiet && exit 1 || exit 0'
            ExecStart=/usr/sbin/chronyd -n -f /etc/chrony.conf -q
            RemainAfterExit=yes
            [Install]
            WantedBy=multi-user.target
          enabled: true
          name: sync-time-once.service
Copy to Clipboard Toggle word wrap

03-sctp-machine-config-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

03-sctp-machine-config-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

08-set-rcu-normal-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

08-set-rcu-normal-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 08-set-rcu-normal-worker
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
Copy to Clipboard Toggle word wrap

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

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

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

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

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

관리형 클러스터 버전

4.17

Cluster Logging Operator

6.0

Local Storage Operator

4.17

OADP(OpenShift API for Data Protection)

1.4.1

PTP Operator

4.17

SRIOV Operator

4.17

SRIOV-FEC Operator

2.9

라이프사이클 에이전트

4.17

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

hub 클러스터 버전

4.17

Red Hat Advanced Cluster Management(RHACM)

2.11

GitOps ZTP 플러그인

4.17

Red Hat OpenShift GitOps

1.13

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

4.17

3.3. Telco 코어 참조 설계 사양

3.3.1. Telco core 4.17 참조 설계 개요

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

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

그림 3.3. telco core 클러스터 서비스 기반 아키텍처 및 네트워킹 토폴로지

overlaid 네트워킹 토폴로지가 있는 서비스 기반 아키텍처를 표시하는 5G 코어 클러스터

telco 코어 클러스터 서비스 기반 아키텍처는 다음 구성 요소로 구성됩니다.

  • 네트워크 데이터 분석 기능 (NWDAF)
  • 네트워크 슬라이스 선택 기능(NSFF)
  • 인증 서버 기능 (AUSF)
  • 통합 데이터 관리(UDM)
  • NRF(네트워크 리포지토리 기능)
  • 네트워크 노출 기능(NEF)
  • 애플리케이션 기능 (AF)
  • 액세스 및 이동성 기능 (AMF)
  • 세션 관리 기능(SMF)
  • 정책 제어 기능 (PCF)
  • 보충 기능 (CHF)
  • 사용자 장비 (Device)
  • 무선 액세스 네트워크(RAN)
  • 사용자 플레인 기능 (UPF)
  • 데이터 플레인 네트워킹 (DN)

3.3.2. Telco 코어 4.17 사용 모델 개요

Telco 코어 클러스터는 RT(Non real-time) 커널로 구성된 작업자 노드가 있는 표준 3개의 컨트롤 플레인 클러스터로 구성됩니다.

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

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

Telco core 사용 모델 아키텍처

Use model architecture

3.3.2.1. 공통 기준 모델

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

Cluster

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

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

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

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

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

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

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

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

다음과 같은 엔지니어링 고려 사항은 telco 코어 사용 모델과 관련이 있습니다.

작업자 노드
  • 작업자 노드는 Intel 3세대 Xeon(IceLake) 프로세서 이상에서 실행해야 합니다.

    참고

    또는 작업자 노드에 Skylake 또는 이전 프로세서가 있는 경우 Spectre와 같은 보안 취약점에 대한 완화 조치를 비활성화해야 합니다. 실패로 인해 트랜잭션 성능이 40% 감소할 수 있습니다.

  • 작업자 노드에 대한 IRQ Balancing을 활성화합니다. PerformanceProfile CR(사용자 정의 리소스)에서 globallyDisableIrqLoadBalancing 필드를 false 로 설정합니다. QoS 클래스가 Guaranteed 로 Pod에 주석을 달아 격리되었는지 확인합니다. 자세한 내용은 "CPU 파티셔닝 및 성능 튜닝"을 참조하십시오.
클러스터의 모든 노드
  • 모든 노드에 대해 Hyper-Threading을 활성화합니다.
  • CPU 아키텍처가 x86_64 인지 확인합니다.
  • 노드가 비RT(RT) 커널을 실행하고 있는지 확인합니다.
  • 워크로드 파티셔닝을 위해 노드가 구성되지 않았는지 확인합니다.
전원 관리 및 성능
  • 전원 관리 및 최대 성능 간의 균형은 클러스터의 MachineConfigPool 리소스에 따라 다릅니다.
클러스터 스케일링
  • 클러스터 노드 수를 120개 이상의 노드로 확장합니다.
CPU 파티셔닝
  • CPU 파티션은 클러스터의 모든 MachineConfigPool CR에 대해 PerformanceProfile CR을 사용하여 구성됩니다. 자세한 내용은 "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 파티셔닝 및 성능 튜닝
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
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"
    Copy to Clipboard Toggle word wrap
  • PerformanceProfile.workloadHints.perPodPowerManagement 를 사용하여 Pod별 전원 관리를 활성화하면 보장된 QoS Pod에 CPU를 완전히 사용해야 하는 경우 다음 주석도 Pod에 연결해야 합니다.

    cpu-c-states.crio.io: "disable"
    cpu-freq-governor.crio.io: "performance"
    Copy to Clipboard Toggle word wrap
엔지니어링 고려 사항
  • 필요한 최소 예약 용량( systemReserved )은 "OpenShift 4 노드의 시스템에 예약하는 데 권장되는 CPU 및 메모리 양은 어느 정도입니까?"의 지침에 따라 확인할 수 있습니다.
  • 실제 필수 예약된 CPU 용량은 클러스터 구성 및 워크로드 특성에 따라 다릅니다.
  • 이 예약된 CPU 값은 전체 코어(2하이퍼 스레드) 정렬으로 반올림해야 합니다.
  • CPU 파티셔닝을 변경하면 MCP의 노드를 드레이닝하고 재부팅합니다.
  • 예약된 CPU는 OpenShift 노드의 할당 가능한 용량에서 제거되므로 예약된 CPU는 Pod 밀도를 줄입니다.
  • 워크로드를 실시간으로 사용할 수 있는 경우 실시간 워크로드 힌트를 활성화해야 합니다.
  • IIRQ(Interrupt Request) 선호도 지원이 없는 하드웨어는 분리된 CPU에 영향을 미칩니다. 보장된 CPU QoS가 있는 Pod에서 할당된 CPU를 완전히 사용하려면 서버의 모든 하드웨어가 IRQ 선호도를 지원해야 합니다.
  • OVS는 네트워크 트래픽 요구 사항에 맞게 cpuset 구성을 동적으로 관리합니다. 기본 CNI에서 높은 네트워크 처리량을 처리하기 위해 추가 CPU를 예약할 필요가 없습니다.
  • 클러스터에서 실행되는 워크로드에 cgroup v1이 필요한 경우 cgroups v1을 초기 클러스터 배포의 일부로 사용하도록 노드를 구성할 수 있습니다. 자세한 내용은 "설치 중 Linux cgroup v1 활성화"를 참조하십시오.
3.3.3.2. 서비스 메시
설명

통신 핵심 클라우드 네이티브 기능(CNF)에는 일반적으로 서비스 메시 구현이 필요합니다.

참고

특정 서비스 메시 기능 및 성능 요구 사항은 애플리케이션에 따라 다릅니다. 서비스 메시 구현 및 구성을 선택하는 것은 이 문서의 범위를 벗어납니다. 구현 시 Pod 네트워킹에 도입된 추가 대기 시간을 포함하여 클러스터 리소스 사용량 및 성능에 서비스 메시의 영향을 고려해야 합니다.

3.3.3.3. 네트워킹
이번 릴리스의 새로운 기능
  • 이제 본딩, MACVLAN, IPVLAN 및 SR-IOV 네트워킹 시나리오를 통해 통신 코어 검증이 확장됩니다.
설명
  • 클러스터는 듀얼 스택 IP 구성(IPv4 및 IPv6)으로 구성됩니다.
  • 검증된 물리적 네트워크 구성은 두 개의 듀얼 포트 NIC로 구성됩니다. 하나의 NIC는 기본 CNI(OVN-Kubernetes) 및 IPVLAN 및 MACVLAN 트래픽 간에 공유되며 두 번째 NIC는 SR-IOV VF 기반 Pod 트래픽 전용입니다.
  • 두 개의 NIC 포트가 연결된 활성-활성 LACP IEEE 802.3ad 구성에서 Linux 본딩 인터페이스(bond0)가 생성됩니다.

    참고

    최상위 네트워킹 장치는 MLAG(Multi-chassis link aggregation) 기술을 지원하고 구성해야 합니다.

  • VLAN 인터페이스는 기본 CNI를 포함하여 bond0 상단에 생성됩니다.
  • 본딩 및 VLAN 인터페이스는 네트워크 구성 중에 설치 시 생성됩니다. 기본 CNI에서 사용하는 VLAN(VLAN0) 외에도 Kubernetes NMState Operator를 사용하여 Day 2에서 다른 VLANS를 생성할 수 있습니다.
  • MACVLAN 및 IPVLAN 인터페이스는 해당 CNI를 사용하여 생성됩니다. 동일한 기본 인터페이스를 공유하지 않습니다.
  • SR-IOV VF는 SR-IOV Network Operator가 관리합니다. 다음 다이어그램에서는 SR-IOV NIC 공유에 대한 개요를 보여줍니다.

    그림 3.4. SR-IOV NIC 공유

    간소화된 SR-IOV NIC 공유 구성
3.3.3.4. CNO(Cluster Network Operator)
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
CNO(Cluster Network Operator)는 OpenShift Container Platform 클러스터 설치 중에 기본 OVN-Kubernetes 네트워크 플러그인을 포함하여 클러스터 네트워크 구성 요소를 배포하고 관리합니다. 기본 인터페이스 MTU 설정, OVN 게이트웨이 모드를 구성하여 Pod 송신에 노드 라우팅 테이블 및 MACVLAN과 같은 추가 보조 네트워크를 사용할 수 있습니다.
제한 및 요구사항
  • IPv6 지원에는 OVN-Kubernetes가 필요합니다.
  • 대규모 MTU 클러스터 지원을 사용하려면 연결된 네트워크 장치를 동일하거나 더 큰 값으로 설정해야 합니다.
  • MACVLAN 및 IPVLAN은 동일한 기본 커널 메커니즘, 특히 rx_handler 에 의존하여 동일한 기본 인터페이스에 공동 배치할 수 없습니다. 이 처리기를 사용하면 타사 모듈에서 호스트 처리 전에 들어오는 패킷을 처리할 수 있으며 이러한 핸들러는 네트워크 인터페이스별로 등록할 수 있습니다. MACVLAN과 IPVLAN 모두 기능을 위해 자체 rx_handler 를 등록해야 하므로 충돌하며 동일한 인터페이스에서 공존할 수 없습니다. 자세한 내용은 ipvlan/ipvlan_main.c#L82net/macvlan.c#L1260 을 참조하십시오.
  • 대체 NIC 구성에는 공유 NIC를 여러 NIC로 분할하거나 단일 듀얼 포트 NIC를 사용하는 작업이 포함됩니다.

    중요

    공유 NIC를 여러 NIC로 분할하거나 단일 듀얼 포트 NIC를 사용하여 telco 코어 참조 설계에서 검증되지 않았습니다.

  • 단일 스택 IP 클러스터가 검증되지 않았습니다.
엔지니어링 고려 사항
  • Pod 송신 트래픽은 routingViaHost 옵션을 사용하여 커널 라우팅 테이블에 의해 처리됩니다. 적절한 정적 경로를 호스트에 구성해야 합니다.
3.3.3.5. 로드 밸런서
이번 릴리스의 새로운 기능
  • OpenShift Container Platform 4.17에서 frr-k8s 는 이제 기본 및 완전히 지원되는 BGP(Border Gateway Protocol) 백엔드입니다. 더 이상 사용되지 않는 frr BGP 모드를 계속 사용할 수 있습니다. frr-k8s 백엔드를 사용하려면 클러스터를 업그레이드해야 합니다.
설명

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

참고

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

제한 및 요구사항
  • MetalLB에서 상태 저장 로드 밸런싱을 지원하지 않습니다. 워크로드 CNF에 대한 요구 사항인 경우 대체 로드 밸런서 구현을 사용해야 합니다.
  • 네트워킹 인프라는 클라이언트에서 클러스터의 호스트 네트워크로 외부 IP 주소를 라우팅할 수 있는지 확인해야 합니다.
엔지니어링 고려 사항
  • MetalLB는 코어 사용 사례 모델에만 BGP 모드에서 사용됩니다.
  • 코어 사용 모델의 경우 MetalLB는 로컬 게이트웨이 모드에서 사용되는 OVN-Kubernetes 네트워크 공급자에서만 지원됩니다. "Cluster Network Operator" 섹션의 routingViaHost 를 참조하십시오.
  • MetalLB의 BGP 구성은 네트워크 및 피어의 요구 사항에 따라 다릅니다.
  • 주소 풀은 필요에 따라 구성할 수 있으므로 주소, 집계 길이, 자동 할당 및 기타 관련 매개 변수의 변형을 허용합니다.
  • MetalLB는 BGP를 nouncing 경로에만 사용합니다. transmitIntervalminimumTtl 매개변수만 이 모드에서 관련이 있습니다. BFD 프로필의 다른 매개 변수는 기본 설정에 가까운 상태로 유지되어야 합니다. 값이 더 짧은 경우 오류가 발생하고 성능에 영향을 미칠 수 있습니다.
3.3.3.6. SR-IOV
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
SR-IOV를 사용하면 물리적 네트워크 인터페이스(PF)를 여러 VF(가상 기능)로 나눌 수 있습니다. 그러면 Pod를 분리한 상태로 유지하면서 더 높은 처리량 성능을 달성하기 위해 VFS를 여러 Pod에 할당할 수 있습니다. SR-IOV Network Operator는 SR-IOV CNI, 네트워크 장치 플러그인 및 SR-IOV 스택의 기타 구성 요소를 프로비저닝하고 관리합니다.
제한 및 요구사항
  • 지원되는 네트워크 인터페이스 컨트롤러는 "지원되는 장치"에 나열되어 있습니다.
  • SR-IOV Network Operator는 커널 명령줄에서 IOMMU를 자동으로 활성화합니다.
  • SR-IOV VF는 PF에서 링크 상태 업데이트를 수신하지 않습니다. 링크 다운 탐지가 필요한 경우 프로토콜 수준에서 수행해야 합니다.
  • MultiNetworkPolicy CR은 netdevice 네트워크에만 적용할 수 있습니다. 구현에서 vfio 인터페이스를 관리할 수 없는 iptables 툴을 사용하기 때문입니다.
엔지니어링 고려 사항
  • vfio 모드의 SR-IOV 인터페이스는 일반적으로 처리량 또는 짧은 대기 시간이 필요한 애플리케이션의 추가 보조 네트워크를 활성화하는 데 사용됩니다.
  • 배포에서 SriovOperatorConfig CR을 제외하면 CR이 자동으로 생성되지 않습니다.
  • 보안 부팅 또는 커널 잠금 아래의 펌웨어 업데이트를 지원하지 않는 NIC는 애플리케이션 워크로드에 필요한 VF 수를 지원하기에 충분한 VF를 사용하여 사전 구성해야 합니다.

    참고

    이러한 NIC에 대한 SR-IOV Network Operator 플러그인은 문서화되지 않은 disablePlugins 옵션을 사용하여 비활성화해야 할 수 있습니다.

3.3.3.7. NMState Operator
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
NMState Operator는 클러스터 노드에서 네트워크 구성을 수행하기 위한 Kubernetes API를 제공합니다.
제한 및 요구사항
해당 없음
엔지니어링 고려 사항
  • 초기 네트워킹 구성은 설치 CR의 NMStateConfig 콘텐츠를 사용하여 적용됩니다. NMState Operator는 네트워크 업데이트에 필요한 경우에만 사용됩니다.
  • SR-IOV 가상 기능이 호스트 네트워킹에 사용되는 경우 NodeNetworkConfigurationPolicy 를 사용하는 NMState Operator는 해당 VF 인터페이스(예: VLAN 및 MTU)를 구성하는 데 사용됩니다.
3.3.3.8. 로깅
이번 릴리스의 새로운 기능
  • 이번 릴리스에서는 Cluster Logging Operator 6.0이 새로 추가되었습니다. 새 API 버전에 맞게 기존 구현을 업데이트합니다.
설명
Cluster Logging Operator를 사용하면 원격 아카이브 및 분석을 위해 노드에서 로그를 수집하고 제공할 수 있습니다. 참조 구성은 Kafka를 사용하여 원격 아카이브에 감사 및 인프라 로그를 제공합니다.
제한 및 요구사항
해당 없음
엔지니어링 고려 사항
  • 클러스터 CPU 사용 영향은 생성된 로그 수 또는 크기와 구성된 로그 필터링 양을 기반으로 합니다.
  • 참조 구성에는 애플리케이션 로그 전달이 포함되어 있지 않습니다. 구성에 애플리케이션 로그를 포함하려면 애플리케이션 로깅 속도를 평가하고 예약된 세트에 할당된 추가 CPU 리소스를 평가해야 합니다.
3.3.3.9. 전원 관리
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
성능 프로필을 사용하여 높은 전원 모드, 저전력 모드 또는 혼합 모드로 클러스터를 구성합니다. 전원 모드를 선택하는 것은 클러스터에서 실행되는 워크로드의 특성, 특히 대기 시간에 얼마나 민감한지에 따라 달라집니다.
제한 및 요구사항
  • 전원 구성은 적절한 BIOS 구성을 사용합니다(예: C 상태 및 P-상태 활성화). 구성은 하드웨어 벤더마다 다릅니다.
엔지니어링 고려 사항
  • 대기 시간: 대기 시간에 민감한 워크로드가 요구 사항을 충족하도록 하려면 고급 구성 또는 Pod별 전원 관리 구성이 필요합니다. Pod별 전원 관리는 전용 고정 CPU가 있는 QoS Pod에서만 사용할 수 있습니다.
3.3.3.10. 스토리지

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

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

    참고

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

3.3.3.11. 통신 핵심 배포 구성 요소

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

3.3.3.11.1. Red Hat Advanced Cluster Management
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

RHACM(Red Hat Advanced Cluster Management)은 배포된 클러스터에 대한 MCE(Multi Cluster Engine) 설치 및 지속적인 라이프사이클 관리 기능을 제공합니다. 유지 관리 기간 중 클러스터에 정책 CR(사용자 정의 리소스)을 적용하여 클러스터 구성과 업그레이드를 선언적으로 관리합니다.

토폴로지 Aware Lifecycle Manager(TALM)에서 관리하는 대로 RHACM 정책 컨트롤러를 사용하여 정책을 적용합니다.

관리형 클러스터를 설치할 때 RHACM은 사용자 지정 디스크 파티셔닝, 역할 할당 및 머신 구성 풀에 할당을 지원하기 위해 라벨을 개별 노드에 적용합니다. SiteConfig 또는 ClusterInstance CR을 사용하여 이러한 구성을 정의합니다.

제한 및 요구사항
엔지니어링 고려 사항
  • RHACM 정책 허브 측 템플릿을 사용하여 클러스터 구성을 보다 효과적으로 확장할 수 있습니다. 단일 그룹 정책 또는 그룹과 클러스터별 값이 템플릿으로 대체되는 일반 그룹 정책 수를 사용하여 정책 수를 크게 줄일 수 있습니다.
  • 클러스터별 구성: 관리 클러스터에는 일반적으로 개별 클러스터에 고유한 몇 가지 구성 값이 있습니다. 이러한 구성은 클러스터 이름을 기반으로 ConfigMap CR에서 가져온 값을 사용하여 RHACM 정책 허브 쪽 템플릿을 사용하여 관리해야 합니다.
3.3.3.11.2. 토폴로지 인식 라이프사이클 관리자
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
TALM( topology Aware Lifecycle Manager)은 클러스터 및 Operator 업그레이드, 구성 등을 포함한 변경 사항이 네트워크로 롤아웃되는 방식을 관리하기 위해 허브 클러스터에서만 실행되는 Operator입니다.
제한 및 요구사항
  • TALM은 400 배치로 동시 클러스터 배포를 지원합니다.
  • 사전 캐싱 및 백업 기능은 단일 노드 OpenShift 클러스터에만 사용할 수 있습니다.
엔지니어링 고려 사항
  • ran.openshift.io/ztp-deploy- ECDSA 주석이 있는 정책만 초기 클러스터 설치 중에 TALM에 의해 자동으로 적용됩니다.
  • 추가 ClusterGroupUpgrade CR을 생성하여 TALM이 수정하는 정책을 제어할 수 있습니다.
3.3.3.11.3. GitOps 및 GitOps ZTP 플러그인
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

GitOps 및 GitOps ZTP 플러그인은 클러스터 배포 및 구성을 관리하기 위한 GitOps 기반 인프라를 제공합니다. 클러스터 정의 및 구성은 Git에서 선언적 상태로 유지됩니다. site Config Operator가 설치 CR로 렌더링하는 허브 클러스터에 ClusterInstance CR을 적용할 수 있습니다. 또는 GitOps ZTP 플러그인을 사용하여 SiteConfig CR에서 직접 설치 CR을 생성할 수 있습니다. GitOps ZTP 플러그인은 PolicyGenTemplate CR을 기반으로 하는 정책의 구성 CR 자동 래핑을 지원합니다.

참고

기준 참조 구성 CR을 사용하여 관리형 클러스터에서 여러 버전의 OpenShift Container Platform을 배포하고 관리할 수 있습니다. 기준 CR과 함께 사용자 정의 CR을 사용할 수 있습니다.

여러 버전별 정책을 동시에 유지하려면 Git을 사용하여 소스 CR 및 정책 CR 버전(PolicyGenTemplate 또는 PolicyGenerator)을 관리합니다.

참조 CR 및 사용자 정의 CR을 다른 디렉터리에 보관합니다. 이렇게 하면 사용자 정의 CR을 건드리지 않고 모든 디렉터리 콘텐츠를 간단하게 교체하여 참조 CR을 패치하고 업데이트할 수 있습니다.

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

    참고

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

  • SiteConfig CR의 extraManifestPath 필드는 OpenShift Container Platform 4.15 이상에서 더 이상 사용되지 않습니다. 대신 새로운 extraManifests.searchPaths 필드를 사용합니다.
엔지니어링 고려 사항
  • 멀티 노드 클러스터 업그레이드의 경우 paused 필드를 true 로 설정하여 유지 관리 기간 동안 MachineConfigPool (MCP) CR을 일시 중지할 수 있습니다. MCP CR에서 maxUnavailable 설정을 구성하여 MCP 당 노드 수를 동시에 늘릴 수 있습니다. MaxUnavailable 필드는 MachineConfig 업데이트 중에 동시에 사용할 수 없는 풀의 노드 백분율을 정의합니다. maxUnavailable 을 최대 허용 가능한 값으로 설정합니다. 이렇게 하면 업그레이드 중에 클러스터의 재부팅 횟수가 줄어들어 업그레이드 시간이 단축됩니다. MCP CR 일시 중지를 마지막으로 해제하면 변경된 모든 구성이 단일 재부팅으로 적용됩니다.
  • 클러스터 설치 중에 paused 필드를 true 로 설정하고 maxUnavailable 을 100%로 설정하여 설치 시간을 단축하여 사용자 정의 MCP CR을 일시 중지할 수 있습니다.
  • 콘텐츠를 업데이트할 때 파일의 혼동 또는 의도하지 않은 덮어쓰기를 방지하려면 /source-crs 폴더 및 Git의 추가 매니페스트에서 사용자 제공 CR에 대해 고유하고 구분 가능한 이름을 사용합니다.
  • SiteConfig CR을 사용하면 여러 추가 경로가 허용됩니다. 동일한 이름의 파일이 여러 디렉토리 경로에 있는 경우 마지막으로 발견된 파일이 우선합니다. 이를 통해 Git에 버전별 Day 0 매니페스트(extra-manifests)의 전체 세트를 배치하고 site Config CR에서 참조할 수 있습니다. 이 기능을 사용하면 여러 OpenShift Container Platform 버전을 관리 클러스터에 동시에 배포할 수 있습니다.
3.3.3.11.4. 에이전트 기반 설치 프로그램
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

설치를 관리하기 위해 추가 서버 또는 가상 머신 없이도 베어 메탈 서버에 에이전트 기반 설치 관리자(ABI)를 사용하여 통신 코어 클러스터를 설치할 수 있습니다. ABI는 연결이 끊긴 환경에서 설치를 지원합니다. ABI를 사용하면 선언적 CR(사용자 정의 리소스)을 사용하여 클러스터를 설치합니다.

참고

에이전트 기반 설치 프로그램은 선택적 구성 요소입니다. 권장되는 설치 방법은 Kubernetes Operator에 Red Hat Advanced Cluster Management 또는 다중 클러스터 엔진을 사용하는 것입니다.

제한 및 요구사항
  • 연결이 끊긴 환경에서 에이전트 기반 설치를 수행하는 데 필요한 모든 콘텐츠가 미러링된 연결이 끊긴 미러 레지스트리가 있어야 합니다.
엔지니어링 고려 사항
  • 네트워킹 구성은 클러스터 설치 중에 NMState CR(사용자 정의 리소스)으로 적용해야 합니다.
3.3.3.12. 모니터링
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명

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

참고

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

제한 및 요구사항
  • 모니터링 구성에서 Pod 메트릭을 정확하게 표시하려면 전용 서비스 모니터 기능을 활성화해야 합니다.
엔지니어링 고려 사항
  • Prometheus 보존 기간을 구성합니다. 사용된 값은 CPU 및 스토리지 리소스에 대해 클러스터의 기록 데이터를 유지 관리하기 위한 운영 요구 사항 간의 절충입니다. 보존 기간이 길어지면 스토리지의 필요성이 증가하고 데이터 인덱싱을 관리하기 위해 추가 CPU가 필요합니다.
3.3.3.13. 스케줄링
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
  • 스케줄러는 지정된 워크로드에 적합한 노드를 선택하는 클러스터 전체 구성 요소입니다. 이는 플랫폼의 핵심 부분이며 일반적인 배포 시나리오에서 특정 구성이 필요하지 않습니다. 그러나 다음 섹션에서 설명하는 몇 가지 특정 사용 사례가 있습니다. NUMA 리소스 Operator를 통해 NUMA 인식 스케줄링을 활성화할 수 있습니다. 자세한 내용은 " NUMA 인식 워크로드 스케줄링"을 참조하십시오.
제한 및 요구사항
  • 기본 스케줄러는 워크로드의 NUMA 현지성을 인식하지 못합니다. 작업자 노드에서 사용 가능한 모든 리소스의 합계만 알고 있습니다. 이로 인해 토폴로지 관리자 정책이 single-numa-node 또는 restricted 로 설정된 노드에 예약할 때 워크로드가 거부될 수 있습니다.

    • 예를 들어 Pod에서 6개의 CPU를 요청하고 NUMA 노드당 CPU가 4개인 빈 노드로 예약되는 것이 좋습니다. 노드의 총 할당 가능 용량은 8개의 CPU이며 스케줄러는 Pod를 배치합니다. 노드 로컬 승인은 실패하지만 각 NUMA 노드에서 사용할 수 있는 CPU는 4개뿐입니다.
    • NUMA 노드가 있는 모든 클러스터는 NUMA 리소스 Operator를 사용해야 합니다. KubeletConfig CR에서 machineConfigPoolSelector 필드를 사용하여 NUMA 정렬 스케줄링이 필요한 모든 노드를 선택합니다.
  • 모든 머신 구성 풀에는 일관된 하드웨어 구성이 있어야 합니다. 예를 들어 모든 노드에는 동일한 NUMA 영역 수가 있어야 합니다.
엔지니어링 고려 사항
  • Pod에 올바른 스케줄링 및 격리를 위한 주석이 필요할 수 있습니다. 주석에 대한 자세한 내용은 "CPU 파티셔닝 및 성능 튜닝"을 참조하십시오.
  • SriovNetworkNodePolicy CR에서 excludeTopology 필드를 사용하여 예약 중에 무시하도록 SR-IOV 가상 함수 NUMA 선호도를 구성할 수 있습니다.
3.3.3.14. 노드 구성
이번 릴리스의 새로운 기능
  • 이제 컨테이너 마운트 네임스페이스 캡슐화 및 kdump를 telco core RDS에서 사용할 수 있습니다.
설명
  • 컨테이너 마운트 네임스페이스 캡슐화는 시스템 마운트 검사를 줄이고 kubelet 및 CRI-O에 표시되는 컨테이너 마운트 네임스페이스를 생성합니다.
  • kdump는 커널 패닉이 발생할 때 디버그 정보를 캡처하는 기본적으로 활성화된 선택적 구성입니다. kdump를 활성화하는 참조 CR에는 참조 구성에 포함된 드라이버 및 커널 모듈 세트에 따라 증가된 메모리 예약이 포함됩니다.
제한 및 요구사항
  • kdump 및 컨테이너 마운트 네임스페이스 캡슐화는 추가 커널 모듈을 통해 사용할 수 있습니다. 이러한 모듈을 분석하여 CPU 부하, 시스템 성능 및 필요한 KPI를 충족하는 기능에 미치는 영향을 결정해야 합니다.
엔지니어링 고려 사항
  • MachineConfig CR을 사용하여 다음 커널 모듈을 설치합니다. 이러한 모듈은 확장된 커널 기능을 클라우드 네이티브 기능(CNF)에 제공합니다.

    • sctp
    • ip_gre
    • ip6_tables
    • ip6t_REJECT
    • ip6table_filter
    • ip6table_mangle
    • iptable_filter
    • iptable_mangle
    • iptable_nat
    • xt_multiport
    • xt_owner
    • xt_REDIRECT
    • xt_statistic
    • xt_TCPMSS
3.3.3.15. 호스트 펌웨어 및 부트 로더 구성
이번 릴리스의 새로운 기능
  • 이제 telco 코어 참조 설계로 구성된 클러스터 호스트에 보안 부팅이 권장됩니다.
엔지니어링 고려 사항
  • 보안 부팅을 활성화하는 것이 좋습니다.

    참고

    보안 부팅이 활성화되면 서명된 커널 모듈만 커널에 의해 로드됩니다. 트리 외부 드라이버는 지원되지 않습니다.

3.3.3.16. 연결이 끊긴 환경
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
설명
통신 핵심 클러스터는 인터넷에 직접 액세스하지 않고 네트워크에 설치해야 합니다. 클러스터를 설치, 구성, Operator에 필요한 모든 컨테이너 이미지는 연결이 끊긴 레지스트리에서 사용할 수 있어야 합니다. 여기에는 OpenShift Container Platform 이미지, Day 2 Operator Lifecycle Manager(OLM) Operator 이미지 및 애플리케이션 워크로드 이미지가 포함됩니다.
제한 및 요구사항
  • 모든 사용자 정의 CatalogSources에는 고유한 이름이 필요합니다. 기본 카탈로그 이름을 재사용하지 마십시오.
  • 유효한 시간 소스는 클러스터 설치의 일부로 구성해야 합니다.
3.3.3.17. 보안
이번 릴리스의 새로운 기능
  • telco 코어 클러스터에는 보안 부팅 호스트 펌웨어 설정이 권장됩니다. 자세한 내용은 "호스트 펌웨어 및 부트 로더 구성"을 참조하십시오.
설명

여러 공격 벡터에 대해 클러스터를 강화해야 합니다. OpenShift Container Platform에는 클러스터 보안을 담당하는 단일 구성 요소 또는 기능이 없습니다. 다음 보안 지향 기능 및 구성을 사용하여 클러스터를 보호합니다.

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

    • container_t SELinux 컨텍스트를 사용하여 Cryostat 플러그인을 구성합니다.
    • 호스트에서 container_use_devices SELinux 부울을 활성화합니다.
엔지니어링 고려 사항
  • rootless DPDK Pod를 지원하려면 Cryostat 장치를 생성하려면 호스트에서 SELinux 부울 container_use_devices 를 활성화해야 합니다. 이로 인해 단기간에 사용 가능한 보안 위험이 발생합니다. 다른 해결책도 살펴볼 것입니다.
3.3.3.18. 확장성
이번 릴리스의 새로운 기능
  • 이 릴리스에는 참조 디자인 업데이트가 없습니다
제한 및 요구사항
  • 클러스터는 최소 120개의 노드로 확장되어야 합니다.

3.3.4. Telco core 4.17 참조 구성 CR

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

3.3.4.1. telco 코어 참조 설계 구성 CR 추출

telco-core-rds-rhel9 컨테이너 이미지에서 telco core 프로필의 전체 CR(사용자 정의 리소스) 세트를 추출할 수 있습니다. 컨테이너 이미지에는 telco core 프로필에 대한 필수 CR과 선택적 CR이 모두 있습니다.

사전 요구 사항

  • podman 을 설치했습니다.

프로세스

  • 다음 명령을 실행하여 telco-core-rds-rhel9 컨테이너 이미지에서 콘텐츠를 추출합니다.

    $ mkdir -p ./out
    Copy to Clipboard Toggle word wrap
    $ podman run -it registry.redhat.io/openshift4/openshift-telco-core-rds-rhel9:v4.17 | base64 -d | tar xv -C out
    Copy to Clipboard Toggle word wrap

검증

  • out 디렉터리에는 다음과 같은 폴더 구조가 있습니다. out/telco-core-rds/ 디렉터리에서 telco 코어 CR을 볼 수 있습니다.

    출력 예

    out/
    └── telco-core-rds
        ├── configuration
        │   └── reference-crs
        │       ├── optional
        │       │   ├── logging
        │       │   ├── networking
        │       │   │   └── multus
        │       │   │       └── tap_cni
        │       │   ├── other
        │       │   └── tuning
        │       └── required
        │           ├── networking
        │           │   ├── metallb
        │           │   ├── multinetworkpolicy
        │           │   └── sriov
        │           ├── other
        │           ├── performance
        │           ├── scheduling
        │           └── storage
        │               └── odf-external
        └── install
    Copy to Clipboard Toggle word wrap

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

기준

Network.yaml

제공됨

없음

기준

networkAttachmentDefinition.yaml

제공됨

없음

로드 밸런서

addr-pool.yaml

없음

없음

로드 밸런서

bfd-profile.yaml

없음

없음

로드 밸런서

bgp-advr.yaml

없음

없음

로드 밸런서

bgp-peer.yaml

없음

없음

로드 밸런서

community.yaml

없음

없음

로드 밸런서

metallb.yaml

없음

없음

로드 밸런서

metallbNS.yaml

없음

없음

로드 밸런서

metallbOperGroup.yaml

없음

없음

로드 밸런서

metallbSubscription.yaml

없음

없음

Multus - rootless DPDK Pod의 경우 Tap CNI

mc_rootless_pods_selinux.yaml

없음

없음

NMState Operator

NMState.yaml

없음

없음

NMState Operator

NMStateNS.yaml

없음

없음

NMState Operator

NMStateOperGroup.yaml

없음

없음

NMState Operator

NMStateSubscription.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.3.4.3. 노드 구성 참조 CR
Expand
표 3.10. 노드 구성 CR
Component참조 CR선택 사항이번 릴리스의 새로운 기능

추가 커널 모듈

control-plane-load-kernel-modules.yaml

제공됨

없음

추가 커널 모듈

sctp_module_mc.yaml

제공됨

없음

추가 커널 모듈

worker-load-kernel-modules.yaml

제공됨

없음

컨테이너 마운트 네임스페이스 숨기기

mount_namespace_config_master.yaml

없음

제공됨

컨테이너 마운트 네임스페이스 숨기기

mount_namespace_config_worker.yaml

없음

제공됨

kdump 활성화

kdump-master.yaml

없음

제공됨

kdump 활성화

kdump-worker.yaml

없음

제공됨

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

클러스터 로깅

ClusterLogForwarder.yaml

제공됨

없음

클러스터 로깅

ClusterLogNS.yaml

제공됨

없음

클러스터 로깅

ClusterLogOperGroup.yaml

제공됨

없음

클러스터 로깅

ClusterLogServiceAccount.yaml

제공됨

제공됨

클러스터 로깅

ClusterLogServiceAccountAuditBinding.yaml

제공됨

제공됨

클러스터 로깅

ClusterLogServiceAccountInfrastructureBinding.yaml

제공됨

제공됨

클러스터 로깅

ClusterLogSubscription.yaml

제공됨

없음

연결이 끊긴 구성

catalog-source.yaml

없음

없음

연결이 끊긴 구성

icsp.yaml

없음

없음

연결이 끊긴 구성

operator-hub.yaml

없음

없음

모니터링 및 관찰 기능

monitoring-config-cm.yaml

제공됨

없음

전원 관리

PerformanceProfile.yaml

없음

없음

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

시스템 예약 용량

control-plane-system-reserved.yaml

제공됨

없음

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

NUMA 인식 스케줄러

nrop.yaml

없음

없음

NUMA 인식 스케줄러

NROPSubscription.yaml

없음

없음

NUMA 인식 스케줄러

NROPSubscriptionNS.yaml

없음

없음

NUMA 인식 스케줄러

NROPSubscriptionOperGroup.yaml

없음

없음

NUMA 인식 스케줄러

sched.yaml

없음

없음

NUMA 인식 스케줄러

Scheduler.yaml

없음

없음

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

외부 ODF 구성

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

없음

없음

외부 ODF 구성

02-ocs-external-storagecluster.yaml

없음

없음

외부 ODF 구성

odfNS.yaml

없음

없음

외부 ODF 구성

odfOperGroup.yaml

없음

없음

외부 ODF 구성

odfSubscription.yaml

없음

없음

3.3.4.8. YAML 참조
3.3.4.8.1. 네트워킹 참조 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

  # Enable to use MultiNetworkPolicy CRs
  useMultiNetworkPolicy: true
Copy to Clipboard Toggle word wrap

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",
  #  }
  #}'
Copy to Clipboard Toggle word wrap

addr-pool.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: $name # eg addresspool3
  namespace: metallb-system
spec:
  ##############
  # Expected variation in this configuration
  addresses: [$pools]
  #- 3.3.3.0/24
  autoAssign: true
  ##############
Copy to Clipboard Toggle word wrap

bfd-profile.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta1
kind: BFDProfile
metadata:
  name: $name # e.g. 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
  #
  ################
Copy to Clipboard Toggle word wrap

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, or Community
  # eg:

  #    - bgpcommunity
  #    - 65535:65282
  aggregationLength: 32
  aggregationLengthV6: 128
  localPref: 100
Copy to Clipboard Toggle word wrap

bgp-peer.yaml

# required
# count: 1-N
apiVersion: metallb.io/v1beta2
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 # e.g. bfdprofile
  passwordSecret: {}
Copy to Clipboard Toggle word wrap

community.yaml

---
apiVersion: metallb.io/v1beta1
kind: Community
metadata:
  name: $name # e.g. bgpcommunity
  namespace: metallb-system
spec:
  communities: [$comm]
Copy to Clipboard Toggle word wrap

metallb.yaml

# required
# count: 1
apiVersion: metallb.io/v1beta1
kind: MetalLB
metadata:
  name: metallb
  namespace: metallb-system
spec: {}
#nodeSelector:
#  node-role.kubernetes.io/worker: ""
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

metallbOperGroup.yaml

# required: yes
# count: 1
---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: metallb-operator
  namespace: metallb-system
Copy to Clipboard Toggle word wrap

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
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

NMState.yaml

apiVersion: nmstate.io/v1
kind: NMState
metadata:
  name: nmstate
spec: {}
Copy to Clipboard Toggle word wrap

NMStateNS.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-nmstate
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

NMStateOperGroup.yaml

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-nmstate
  namespace: openshift-nmstate
spec:
  targetNamespaces:
    - openshift-nmstate
Copy to Clipboard Toggle word wrap

NMStateSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: kubernetes-nmstate-operator
  namespace: openshift-nmstate
spec:
  channel: "stable"
  name: kubernetes-nmstate-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
  disableDrain: false
  logLevel: 2
Copy to Clipboard Toggle word wrap

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
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

SriovSubscriptionNS.yaml

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

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
Copy to Clipboard Toggle word wrap

3.3.4.8.2. 노드 구성 참조 YAML

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,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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,aXBfZ3JlCmlwNl90YWJsZXMKaXA2dF9SRUpFQ1QKaXA2dGFibGVfZmlsdGVyCmlwNnRhYmxlX21hbmdsZQppcHRhYmxlX2ZpbHRlcgppcHRhYmxlX21hbmdsZQppcHRhYmxlX25hdAp4dF9tdWx0aXBvcnQKeHRfb3duZXIKeHRfUkVESVJFQ1QKeHRfc3RhdGlzdGljCnh0X1RDUE1TUwo=
          mode: 420
          overwrite: true
          path: /etc/modules-load.d/kernel-load.conf
Copy to Clipboard Toggle word wrap

mount_namespace_config_master.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
Copy to Clipboard Toggle word wrap

mount_namespace_config_worker.yaml

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
Copy to Clipboard Toggle word wrap

kdump-master.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

kdump-worker.yaml

# Automatically generated by extra-manifests-builder
# Do not make changes directly.
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
Copy to Clipboard Toggle word wrap

3.3.4.8.3. 기타 참조 YAML

ClusterLogForwarder.yaml

apiVersion: "observability.openshift.io/v1"
kind: ClusterLogForwarder
metadata:
  name: instance
  namespace: openshift-logging
spec:
  # outputs: $outputs
  # pipelines: $pipelines
  serviceAccount:
    name: collector
#apiVersion: "observability.openshift.io/v1"
#kind: ClusterLogForwarder
#metadata:
#  name: instance
#  namespace: openshift-logging
# spec:
#   outputs:
#   - type: "kafka"
#     name: kafka-open
#     # below url is an example
#     kafka:
#       url: tcp://10.11.12.13:9092/test
#   filters:
#   - name: test-labels
#     type: openshiftLabels
#     openshiftLabels:
#       label1: test1
#       label2: test2
#       label3: test3
#       label4: test4
#   pipelines:
#   - name: all-to-default
#     inputRefs:
#     - audit
#     - infrastructure
#     filterRefs:
#     - test-labels
#     outputRefs:
#     - kafka-open
#   serviceAccount:
#     name: collector
Copy to Clipboard Toggle word wrap

ClusterLogNS.yaml

---
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-logging
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

ClusterLogOperGroup.yaml

---
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  targetNamespaces:
    - openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccount.yaml

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: collector
  namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountAuditBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-audit-logs-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-audit-logs
subjects:
  - kind: ServiceAccount
    name: collector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogServiceAccountInfrastructureBinding.yaml

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: logcollector-infrastructure-logs-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: collect-infrastructure-logs
subjects:
  - kind: ServiceAccount
    name: collector
    namespace: openshift-logging
Copy to Clipboard Toggle word wrap

ClusterLogSubscription.yaml

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: cluster-logging
  namespace: openshift-logging
spec:
  channel: "stable-6.0"
  name: cluster-logging
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
  installPlanApproval: Automatic
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

icsp.yaml

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

operator-hub.yaml

# required
# count: 1
apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true
Copy to Clipboard Toggle word wrap

monitoring-config-cm.yaml

# optional
# count: 1
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-monitoring-config
  namespace: openshift-monitoring
data:
  config.yaml: |
    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
Copy to Clipboard Toggle word wrap

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: {}
  #  pools.operator.machineconfiguration.openshift.io/worker: ''
  nodeSelector: {}
  #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:
    userLevelNetworking: false
Copy to Clipboard Toggle word wrap

3.3.4.8.4. 리소스 튜닝 참조 YAML

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: ""
Copy to Clipboard Toggle word wrap

3.3.4.8.5. 참조 YAML 예약

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: ""
Copy to Clipboard Toggle word wrap

NROPSubscription.yaml

# required
# count: 1
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: numaresources-operator
  namespace: openshift-numaresources
spec:
  channel: "4.17"
  name: numaresources-operator
  source: redhat-operators-disconnected
  sourceNamespace: openshift-marketplace
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

NROPSubscriptionNS.yaml

# required: yes
# count: 1
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-numaresources
  annotations:
    workload.openshift.io/allowed: management
Copy to Clipboard Toggle word wrap

NROPSubscriptionOperGroup.yaml

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

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.17.0"
  #logLevel: "Trace"
  schedulerName: topo-aware-scheduler
Copy to Clipboard Toggle word wrap

Scheduler.yaml

apiVersion: config.openshift.io/v1
kind: Scheduler
metadata:
  name: cluster
spec:
  # non-schedulable control plane is the default. This ensures
  # compliance.
  mastersSchedulable: false
  policy:
    name: ""
Copy to Clipboard Toggle word wrap

3.3.4.8.6. 스토리지 참조 YAML

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==
Copy to Clipboard Toggle word wrap

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: {}
status:
  phase: Ready
Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
status:
  state: AtLatestKnown
Copy to Clipboard Toggle word wrap

3.3.5. Telco 코어 참조 구성 소프트웨어 사양

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

3.3.5.1. Telco 코어 참조 구성 소프트웨어 사양

Red Hat telco 코어 4.17 솔루션은 다음 OpenShift Container Platform 클러스터용 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.

Expand
표 3.15. telco 코어 클러스터 검증 소프트웨어 구성 요소
Component소프트웨어 버전

Cluster Logging Operator

6.0

OpenShift Data Foundation

4.17

SR-IOV Operator

4.17

MetalLB

4.17

NMState Operator

4.17

NUMA 인식 스케줄러

4.17

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

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

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

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

주의

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

참고

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

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

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

노드 수

2,000 [1]

Pod 수 [2]

150,000

노드당 Pod 수

2,500 [3]

코어당 Pod 수

기본값 없음

네임스페이스 수 [4]

10,000

빌드 수

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

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

25,000

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

라우터당 2,000개

보안 수

80,000

구성 맵 수

90,000

서비스 수 [6]

10,000

네임스페이스당 서비스 수

5,000

서비스당 백엔드 수

5,000

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

2,000

빌드 구성 수

12,000

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

1,024 [7]

  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. 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하기 위해 조각 모음을 포함한 etcd의 유지보수를 정기적으로 수행하는 것이 좋습니다.
  5. 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트를 반복해야 하는 컨트롤 루프가 여러 개 있습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
  6. 각 서비스 포트와 각 서비스 백엔드에는 iptables 에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
  7. 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.17, 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.1. AWS 클라우드 플랫폼

Expand
노드플레이버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 플랫폼

Expand
노드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 플랫폼

Expand
노드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
Copy to Clipboard Toggle word wrap

노드당 기본 최대 Pod 수는 250입니다. 하지만 노드에 적합한 Pod 수는 애플리케이션 자체에 따라 달라집니다. "애플리케이션 요구 사항에 따라 환경을 계획하는 방법"에 설명된 대로 애플리케이션의 메모리, CPU 및 스토리지 요구 사항을 고려하십시오.

시나리오 예

클러스터당 2,200개의 Pod로 클러스터 규모를 지정하려면 노드당 최대 500개의 Pod가 있다고 가정하여 최소 5개의 노드가 있어야 합니다.

2200 / 500 = 4.4
Copy to Clipboard Toggle word wrap

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

2200 / 20 = 110
Copy to Clipboard Toggle word wrap

다음과 같습니다.

required pods per cluster / total number of nodes = expected pods per node
Copy to Clipboard Toggle word wrap

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

4.4. 애플리케이션 요구사항에 따라 환경을 계획하는 방법

예에 나온 애플리케이션 환경을 고려해 보십시오.

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

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

Expand
노드 유형수량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
Copy to Clipboard Toggle word wrap

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

참고

Expand
표 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의 임시 스토리지 제한 합계는 이 값을 초과할 수 없습니다. 이 기능은 기본적으로 비활성화되어 있습니다.

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

requests.storage

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

persistentvolumeclaims

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

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

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

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

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

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

pods

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

replicationcontrollers

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

resourcequotas

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

services

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

secrets

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

configmaps

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

persistentvolumeclaims

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

openshift.io/imagestreams

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

$ oc create quota <name> --hard=count/<resource>.<group>=<quota> 
1
Copy to Clipboard Toggle word wrap
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'
    Copy to Clipboard Toggle word wrap

    출력 예

                        openshift.com/gpu-accelerator=true
    Capacity:
     nvidia.com/gpu:  2
    Allocatable:
     nvidia.com/gpu:  2
     nvidia.com/gpu:  0           0
    Copy to Clipboard Toggle word wrap

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

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

    $ cat gpu-quota.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: gpu-quota
      namespace: nvidia
    spec:
      hard:
        requests.nvidia.com/gpu: 1
    Copy to Clipboard Toggle word wrap

  3. $ oc create -f gpu-quota.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    resourcequota/gpu-quota created
    Copy to Clipboard Toggle word wrap

  4. $ oc describe quota gpu-quota -n nvidia
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  0     1
    Copy to Clipboard Toggle word wrap

  5. $ oc create pod gpu-pod.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  6. $ oc get pods
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME              READY     STATUS      RESTARTS   AGE
    gpu-pod-s46h7     1/1       Running     0          1m
    Copy to Clipboard Toggle word wrap

  7. $ oc describe quota gpu-quota -n nvidia
    Copy to Clipboard Toggle word wrap

    출력 예

    Name:                    gpu-quota
    Namespace:               nvidia
    Resource                 Used  Hard
    --------                 ----  ----
    requests.nvidia.com/gpu  1     1
    Copy to Clipboard Toggle word wrap

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

    $ oc create -f gpu-pod.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    Error from server (Forbidden): error when creating "gpu-pod.yaml": pods "gpu-pod-f7z2w" is forbidden: exceeded quota: gpu-quota, requested: requests.nvidia.com/gpu=1, used: requests.nvidia.com/gpu=1, limited: requests.nvidia.com/gpu=1
    Copy to Clipboard Toggle word wrap

5.1.2. 할당량 범위

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

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

Expand
범위설명

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
Copy to Clipboard Toggle word wrap

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

apiVersion: v1
kind: ResourceQuota
metadata:
  name: openshift-object-counts
spec:
  hard:
    openshift.io/imagestreams: "10" 
1
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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

5.2.4. 할당량 생성

$ oc create -f <resource_quota_definition> [-n <project_name>]
Copy to Clipboard Toggle word wrap

$ oc create -f core-object-counts.yaml -n demoproject
Copy to Clipboard Toggle word wrap

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

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

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

$ oc create quota <name> --hard=count/<resource>.<group>=<quota>,count/<resource>.<group>=<quota>
Copy to Clipboard Toggle word wrap

$ 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
Copy to Clipboard Toggle word wrap

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

5.2.6. 할당량 보기

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

    $ oc get quota -n demoproject
    NAME                AGE
    besteffort          11m
    compute-resources   2m
    core-object-counts  29m
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap

5.2.7.

kubernetesMasterConfig:
  apiLevels:
  - v1beta3
  - v1
  apiServerArguments: null
  controllerArguments:
    resource-quota-sync-period:
      - "10s"
Copy to Clipboard Toggle word wrap

$ master-restart api
$ master-restart controllers
Copy to Clipboard Toggle word wrap

참고

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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

1
제한 범위 오브젝트의 이름입니다.
2
3
4
5
6
Pod의 단일 컨테이너에서 요청할 수 있는 최대 CPU 양입니다.
7
Pod의 단일 컨테이너에서 요청할 수 있는 최대 메모리 양입니다.
8
Pod의 단일 컨테이너에서 요청할 수 있는 최소 CPU 양입니다.
9
Pod의 단일 컨테이너에서 요청할 수 있는 최소 메모리 양입니다.
10
11
12
13
14
컨테이너에 대한 최대 제한 대 요청 비율입니다.

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
Copy to Clipboard Toggle word wrap

1
내부 레지스트리로 내보낼 수 있는 이미지의 최대 크기입니다.
2
3
4
5
6
7
8

5.3.1. 컨테이너 제한

  • CPU
  • 메모리

컨테이너

Expand
 동작

MaxLimitRequestRatio

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

5.3.2. Pod 제한

  • CPU
  • 메모리

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

Expand
표 5.4. Pod
  

MaxLimitRequestRatio

5.3.3. 이미지 제한

  • 스토리지

  • openshift.io/Image

Expand
표 5.5. 이미지
 동작

참고

5.3.4. 이미지 스트림 제한

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

  • openshift.io/ImageStream

Expand
표 5.6. ImageStream
 동작

Max[openshift.io/image-tags]

Max[openshift.io/images]

5.3.5.

내부 참조와 외부 참조는 구분되지 않습니다. 내부 컨테이너 이미지 레지스트리에 대한 내보내기는 어떤 방식으로든 제한하지 않지만 태그 제한에 유용합니다.

내부 및 외부 참조는 구분되지 않습니다.

5.3.6. PersistentVolumeClaim limits

  • 스토리지

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

Expand
표 5.7. Pod
  

{
  "apiVersion": "v1",
  "kind": "LimitRange",
  "metadata": {
    "name": "pvcs" 
1

  },
  "spec": {
    "limits": [{
        "type": "PersistentVolumeClaim",
        "min": {
          "storage": "2Gi" 
2

        },
        "max": {
          "storage": "50Gi" 
3

        }
      }
    ]
  }
}
Copy to Clipboard Toggle word wrap

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

추가 리소스

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

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

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

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

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

5.4. 제한 범위 작업

5.4.1. 제한 범위 생성

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

프로세스

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

    $ oc create -f <limit_range_file> -n <project>
    Copy to Clipboard Toggle word wrap

5.4.2. 제한 보기

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

프로세스

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

    $ oc get limits -n demoproject
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME              AGE
    resource-limits   6d
    Copy to Clipboard Toggle word wrap

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

    $ oc describe limits resource-limits -n demoproject
    Copy to Clipboard Toggle word wrap

    출력 예

    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      -               -               -
    Copy to Clipboard Toggle word wrap

5.4.3. 제한 범위 삭제

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

+

$ oc delete limits <limit_name>
Copy to Clipboard Toggle word wrap

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

버전 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
    Copy to Clipboard Toggle word wrap

기본 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/ocp-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
Copy to Clipboard Toggle word wrap

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 ^ {} \;
Copy to Clipboard Toggle word wrap

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

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

$ oc get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
Copy to Clipboard Toggle word wrap

출력 예

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
Copy to Clipboard Toggle word wrap

  • 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
Copy to Clipboard Toggle word wrap

출력 예

NAME          VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
node-tuning   4.17.1    True        False         True       60m     1/5 Profiles with bootcmdline conflict
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

권장 프로필

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

recommend:
<recommend-item-1>
# ...
<recommend-item-n>
Copy to Clipboard Toggle word wrap

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

- 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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

위의 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
Copy to Clipboard Toggle word wrap

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

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

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

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

이제 openshift -control-planeopenshift-node 프로필에서 설정을 상속하는 openshift 프로파일이 조건부 프로필 로드를 사용하여 이 기능을 사용하도록 업데이트되었습니다. NTO 및 TuneD에는 현재 클라우드 공급자별 프로필이 포함되어 있지 않습니다. 그러나 모든 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
Copy to Clipboard Toggle word wrap

참고

프로필 상속으로 인해 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
Copy to Clipboard Toggle word wrap

중요

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

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

예: 기본 제공 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
Copy to Clipboard Toggle word wrap

기본 제공 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
Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    참고

    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
    Copy to Clipboard Toggle word wrap
  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:
        ...
    Copy to Clipboard Toggle word wrap
    참고

    여러 노드 풀에서 동일한 구성 맵을 참조할 수 있습니다. 호스팅된 컨트롤 플레인에서 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
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME       AGE
    default    7m36s
    rendered   7m36s
    tuned-1    65s
    Copy to Clipboard Toggle word wrap

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

    $ oc --kubeconfig="$HC_KUBECONFIG" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                           TUNED            APPLIED   DEGRADED   AGE
    nodepool-1-worker-1            tuned-1-profile  True      False      7m43s
    nodepool-1-worker-2            tuned-1-profile  True      False      7m14s
    Copy to Clipboard Toggle word wrap

    참고

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

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

    $ oc --kubeconfig="$HC_KUBECONFIG" debug node/nodepool-1-worker-1 -- chroot /host sysctl vm.dirty_ratio
    Copy to Clipboard Toggle word wrap

    출력 예

    vm.dirty_ratio = 55
    Copy to Clipboard Toggle word wrap

커널 부팅 매개변수를 설정해야 하는 호스팅된 컨트롤 플레인의 고급 튜닝의 경우 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
    Copy to Clipboard Toggle word wrap
    참고

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

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

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f tuned-hugepages.yaml 
    1
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    참고

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

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

    $ oc --kubeconfig="<management_cluster_kubeconfig>" create -f hugepages-nodepool.yaml
    Copy to Clipboard Toggle word wrap

검증

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

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

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get tuned.tuned.openshift.io -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                 AGE
    default              123m
    hugepages-8dfb1fed   1m23s
    rendered             123m
    Copy to Clipboard Toggle word wrap

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

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" get profile.tuned.openshift.io -n openshift-cluster-node-tuning-operator
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                           TUNED                      APPLIED   DEGRADED   AGE
    nodepool-1-worker-1            openshift-node             True      False      132m
    nodepool-1-worker-2            openshift-node             True      False      131m
    hugepages-nodepool-worker-1    openshift-node-hugepages   True      False      4m8s
    hugepages-nodepool-worker-2    openshift-node-hugepages   True      False      3m57s
    Copy to Clipboard Toggle word wrap

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

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

    $ oc --kubeconfig="<hosted_cluster_kubeconfig>" debug node/nodepool-1-worker-1 -- chroot /host cat /proc/cmdline
    Copy to Clipboard Toggle word wrap

    출력 예

    BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-... hugepagesz=2M hugepages=50
    Copy to Clipboard Toggle word wrap

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 관리자 설정

CPU 관리자를 구성하려면 KubeletConfig CR(사용자 정의 리소스)을 생성하고 원하는 노드 세트에 적용합니다.

프로세스

  1. 다음 명령을 실행하여 노드에 레이블을 지정합니다.

    # oc label node perf-node.example.com cpumanager=true
    Copy to Clipboard Toggle word wrap
  2. 모든 컴퓨팅 노드에 대해 CPU 관리자를 활성화하려면 다음 명령을 실행하여 CR을 편집합니다.

    # oc edit machineconfigpool worker
    Copy to Clipboard Toggle word wrap
  3. metadata.labels 섹션에 custom-kubelet: cpumanager-enabled 레이블을 추가합니다.

    metadata:
      creationTimestamp: 2020-xx-xxx
      generation: 3
      labels:
        custom-kubelet: cpumanager-enabled
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    정책을 지정합니다.
    • none. 이 정책은 기존 기본 CPU 선호도 체계를 명시적으로 활성화하여 스케줄러가 자동으로 수행하는 것 이상으로 선호도를 제공하지 않도록 합니다. 이는 기본 정책입니다.
    • static. 이 정책은 정수 CPU 요청이 있는 보장된 Pod의 컨테이너를 허용합니다. 또한 노드의 전용 CPU로 액세스를 제한합니다. 적인 경우 소문자 s 를 사용해야 합니다.
    2
    선택 사항: CPU 관리자 조정 빈도를 지정합니다. 기본값은 5s입니다.
  5. 다음 명령을 실행하여 동적 kubelet 구성을 생성합니다.

    # oc create -f cpumanager-kubeletconfig.yaml
    Copy to Clipboard Toggle word wrap

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

  6. 다음 명령을 실행하여 병합된 kubelet 구성을 확인합니다.

    # oc get machineconfig 99-worker-XXXXXX-XXXXX-XXXX-XXXXX-kubelet -o json | grep ownerReference -A7
    Copy to Clipboard Toggle word wrap

    출력 예

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

  7. 다음 명령을 실행하여 컴퓨팅 노드에서 업데이트된 kubelet.conf 파일이 있는지 확인합니다.

    # oc debug node/perf-node.example.com
    sh-4.2# cat /host/etc/kubernetes/kubelet.conf | grep cpuManager
    Copy to Clipboard Toggle word wrap

    출력 예

    cpuManagerPolicy: static        
    1
    
    cpuManagerReconcilePeriod: 5s   
    2
    Copy to Clipboard Toggle word wrap

    1
    cpuManagerPolicyKubeletConfig CR을 생성할 때 정의됩니다.
    2
    KubeletConfig CR을 생성할 때 cpuManagerReconcilePeriod 가 정의됩니다.
  8. 다음 명령을 실행하여 프로젝트를 생성합니다.

    $ oc new-project <project_name>
    Copy to Clipboard Toggle word wrap
  9. 코어를 하나 이상 요청하는 Pod를 생성합니다. 제한 및 요청 둘 다 해당 CPU 값이 정수로 설정되어야 합니다. 해당 숫자는 이 Pod 전용으로 사용할 코어 수입니다.

    # cat cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: cpumanager-
    spec:
      securityContext:
        runAsNonRoot: true
        seccompProfile:
          type: RuntimeDefault
      containers:
      - name: cpumanager
        image: gcr.io/google_containers/pause:3.2
        resources:
          requests:
            cpu: 1
            memory: "1G"
          limits:
            cpu: 1
            memory: "1G"
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop: [ALL]
      nodeSelector:
        cpumanager: "true"
    Copy to Clipboard Toggle word wrap

  10. Pod를 생성합니다.

    # oc create -f cpumanager-pod.yaml
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 레이블을 지정한 노드에 Pod가 예약되어 있는지 확인합니다.

    # oc describe pod cpumanager
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 CPU가 Pod에만 할당되었는지 확인합니다.

    # oc describe node --selector='cpumanager=true' | grep -i cpumanager- -B2
    Copy to Clipboard Toggle word wrap

    출력 예

    NAMESPACE    NAME                CPU Requests  CPU Limits  Memory Requests  Memory Limits  Age
    cpuman       cpumanager-mlrrz    1 (28%)       1 (28%)     1G (13%)         1G (13%)       27m
    Copy to Clipboard Toggle word wrap

  3. cgroups가 올바르게 설정되었는지 검증합니다. 다음 명령을 실행하여 일시 중지 프로세스의 PID(프로세스 ID)를 가져옵니다.

    # oc debug node/perf-node.example.com
    Copy to Clipboard Toggle word wrap
    sh-4.2# systemctl status | grep -B5 pause
    Copy to Clipboard Toggle word wrap
    참고

    출력에서 일시 정지 프로세스 항목을 여러 개 반환하는 경우 올바른 일시 중지 프로세스를 식별해야 합니다.

    출력 예

    # ├─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
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행하여 QoS(Quality of Service) 계층 Guaranteed 의 Pod가 kubepods.slice 하위 디렉터리에 배치되었는지 확인합니다.

    # cd /sys/fs/cgroup/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    Copy to Clipboard Toggle word wrap
    # for i in `ls cpuset.cpus cgroup.procs` ; do echo -n "$i "; cat $i ; done
    Copy to Clipboard Toggle word wrap
    참고

    다른 QoS 계층의 Pod는 상위 kubepods 의 하위 cgroup 에 있습니다.

    출력 예

    cpuset.cpus 1
    tasks 32706
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 작업에 허용되는 CPU 목록을 확인합니다.

    # grep ^Cpus_allowed_list /proc/32706/status
    Copy to Clipboard Toggle word wrap

    출력 예

     Cpus_allowed_list:    1
    Copy to Clipboard Toggle word wrap

  6. 시스템의 다른 Pod가 Guaranteed Pod에 할당된 코어에서 실행할 수 없는지 확인합니다. 예를 들어 besteffort QoS 계층에서 Pod를 확인하려면 다음 명령을 실행합니다.

    # cat /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    Copy to Clipboard Toggle word wrap
    # oc describe node perf-node.example.com
    Copy to Clipboard Toggle word wrap

    출력 예

    ...
    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%)
    Copy to Clipboard Toggle word wrap

    이 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
    Copy to Clipboard Toggle word wrap

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
    Copy to Clipboard Toggle word wrap
    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
    Copy to Clipboard Toggle word wrap
    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
Copy to Clipboard Toggle word wrap

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

spec:
  containers:
  - name: nginx
    image: nginx
    resources:
      limits:
        memory: "200Mi"
      requests:
        memory: "100Mi"
Copy to Clipboard Toggle word wrap

선택한 정책이 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"
Copy to Clipboard Toggle word wrap

토폴로지 관리자는 이러한 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
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 네임스페이스 CR을 생성합니다.

      $ oc create -f nro-namespace.yaml
      Copy to Clipboard Toggle word wrap
  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
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다.

      $ oc create -f nro-operatorgroup.yaml
      Copy to Clipboard Toggle word wrap
  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.17"
        name: numaresources-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      Copy to Clipboard Toggle word wrap
    2. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다.

      $ oc create -f nro-sub.yaml
      Copy to Clipboard Toggle word wrap

검증

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

    $ oc get csv -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                             DISPLAY                  VERSION   REPLACES   PHASE
    numaresources-operator.v4.17.2   numaresources-operator   4.17.2               Succeeded
    Copy to Clipboard Toggle word wrap

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 OperatorInstallSucceeded상태openshift-numaresources 네임스페이스에 나열되어 있는지 확인합니다.

      참고

      설치 중에 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
      Copy to Clipboard Toggle word wrap
      1
      NUMA Resources Operator를 구성하려는 MachineConfigPool 과 일치해야 합니다. 예를 들어 통신 워크로드를 실행하는 데 예상되는 노드 집합을 지정하는 worker-cnf 라는 MachineConfigPool 을 생성할 수 있습니다.
    2. 다음 명령을 실행하여 NUMAResourcesOperator CR을 만듭니다.

      $ oc create -f nrop.yaml
      Copy to Clipboard Toggle word wrap
      참고

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

검증

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

    $ oc get numaresourcesoperators.nodetopology.openshift.io
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    AGE
    numaresourcesoperator   27s
    Copy to Clipboard Toggle word wrap

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

    $ oc get all -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                    READY   STATUS    RESTARTS   AGE
    pod/numaresources-controller-manager-7d9d84c58d-qk2mr   1/1     Running   0          12m
    pod/numaresourcesoperator-worker-7d96r                  2/2     Running   0          97s
    pod/numaresourcesoperator-worker-crsht                  2/2     Running   0          97s
    pod/numaresourcesoperator-worker-jp9mw                  2/2     Running   0          97s
    Copy to Clipboard Toggle word wrap

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

NUMA Resources Operator를 설치한 후 다음 절차에 따라 NUMA 인식 보조 Pod 스케줄러를 배포합니다.

프로세스

  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.17" 
      1
      Copy to Clipboard Toggle word wrap
      1
      연결이 끊긴 환경에서 다음 중 하나를 통해 이 이미지의 해상도를 구성해야 합니다.
      • ImageTagMirrorSet 사용자 정의 리소스(CR) 생성. 자세한 내용은 "추가 리소스" 섹션의 "이미지 레지스트리 저장소 미러링 구성"을 참조하십시오.
      • URL을 연결이 끊긴 레지스트리로 설정합니다.
    2. 다음 명령을 실행하여 NUMAResourcesScheduler CR을 만듭니다.

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

    $ oc get all -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap
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
      Copy to Clipboard Toggle word wrap
      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
      Copy to Clipboard Toggle word wrap
      참고

      성능 프로필 또는 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'
    Copy to Clipboard Toggle word wrap

    출력 예

    "topo-aware-scheduler"
    Copy to Clipboard Toggle word wrap

  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"
      Copy to Clipboard Toggle word wrap
      1
      schedulerName 은 클러스터에 배포된 NUMA 인식 스케줄러의 이름(예: topo-aware-scheduler )과 일치해야 합니다.
    2. 다음 명령을 실행하여 Deployment CR을 생성합니다.

      $ oc create -f nro-deployment.yaml
      Copy to Clipboard Toggle word wrap

검증

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

    $ oc get pods -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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

    $ oc describe pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources
    Copy to Clipboard Toggle word wrap

    출력 예

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

    참고

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

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

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

      $ oc get pods -n openshift-numaresources -o wide
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
      numa-deployment-1-6c4f5bdb84-wgn6g   0/2     Running   0          82m   10.128.2.50   worker-1   <none>  <none>
      Copy to Clipboard Toggle word wrap

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

      $ oc describe noderesourcetopologies.topology.node.k8s.io worker-1
      Copy to Clipboard Toggle word wrap

      출력 예

      ...
      
      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
      Copy to Clipboard Toggle word wrap

      1
      보장된 pod에 할당된 리소스 때문에 사용 가능한 용량이 줄어듭니다.

      보장된 Pod에서 사용하는 리소스는 noderesourcetopologies.topology.node.k8s.io 아래에 나열된 사용 가능한 노드 리소스에서 차감됩니다.

  4. Best-effort 또는 Burstable QoS(qosClass)가 있는 Pod의 리소스 할당은 noderesourcetopologies.topology.node.k8s.io 의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 소모된 리소스가 노드 리소스 계산에 반영되지 않는 경우 Pod에 보장된 qosClass가 있고 CPU 요청이 십진수 값이 아닌 정수 값인지 확인합니다. 다음 명령을 실행하여 Pod에 보장된 qosClass 가 있는지 확인할 수 있습니다.

    $ oc get pod numa-deployment-1-6c4f5bdb84-wgn6g -n openshift-numaresources -o jsonpath="{ .status.qosClass }"
    Copy to Clipboard Toggle word wrap

    출력 예

    Guaranteed
    Copy to Clipboard Toggle word wrap

9.4. 선택 사항: NUMA 리소스 업데이트를 위한 폴링 작업 구성

nodeGroup 의 NUMA Resources Operator에서 제어하는 데몬은 리소스를 폴링하여 사용 가능한 NUMA 리소스에 대한 업데이트를 검색합니다. NUMAResourcesOperator CR(사용자 정의 리소스)에서 spec.nodeGroups 사양을 구성하여 이러한 데몬에 대한 폴링 작업을 미세 조정할 수 있습니다. 이를 통해 폴링 작업에 대한 고급 제어가 제공됩니다. 이러한 사양을 구성하여 스케줄링 동작을 개선하고 하위 최적의 스케줄링 결정을 해결합니다.

구성 옵션은 다음과 같습니다.

  • infoRefreshMode: kubelet을 폴링하기 위한 트리거 조건을 결정합니다. NUMA Resources Operator는 결과 정보를 API 서버에 보고합니다.
  • infoRefreshPeriod: 폴링 업데이트 사이의 기간을 결정합니다.
  • podsFingerprinting: 노드에서 실행되는 현재 Pod 세트에 대한 지정 시간 정보가 폴링 업데이트에서 노출되는지 여부를 결정합니다.

    참고

    podsFingerprinting 의 기본값은 EnabledExclusiveResources 입니다. 스케줄러 성능을 최적화하려면 podsFingerprintingEnabledExclusiveResources 또는 Enabled 로 설정합니다. 또한 NUMAResourcesScheduler CR(사용자 정의 리소스)에서 cacheResyncPeriod 를 0보다 큰 값으로 구성합니다. 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
    Copy to Clipboard Toggle word wrap
    1
    유효한 값은 Periodic,Events,periodicAndEvents 입니다. Periodic 을 사용하여 infoRefreshPeriod 에 정의된 간격으로 kubelet을 폴링합니다. 이벤트를 사용하여 모든 Pod 라이프사이클 이벤트에서 kubelet을 폴링합니다. PeriodicAndEvents 를 사용하여 두 가지 방법을 모두 활성화합니다.
    2
    Periodic 또는 PeriodicAndEvents 새로 고침 모드의 폴링 간격을 정의합니다. 새로 고침 모드가 Events 인 경우 필드가 무시됩니다.
    3
    유효한 값은 enabled,DisabledEnabledExclusiveResources. NUMAResources의 cacheResyncPeriod 사양을 Enabled 또는 EnabledExclusiveResources 로 설정하는 것은 NUMAResourcesSchedulercacheResyncPeriod 사양에 대한 요구 사항입니다.

검증

  1. NUMA Resources Operator를 배포한 후 다음 명령을 실행하여 노드 그룹 구성이 적용되었는지 확인합니다.

    $ oc get numaresop numaresourcesoperator -o json | jq '.status'
    Copy to Clipboard Toggle word wrap

    출력 예

          ...
    
            "config": {
            "infoRefreshMode": "Periodic",
            "infoRefreshPeriod": "10s",
            "podsFingerprinting": "Enabled"
          },
          "name": "worker"
    
          ...
    Copy to Clipboard Toggle word wrap

9.5. NUMA 인식 스케줄링 문제 해결

NUMA 인식 Pod 예약의 일반적인 문제를 해결하려면 다음 단계를 수행합니다.

사전 요구 사항

  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • NUMA Resources Operator를 설치하고 NUMA 인식 보조 스케줄러를 배포합니다.

프로세스

  1. 다음 명령을 실행하여 noderesourcetopologies CRD가 클러스터에 배포되었는지 확인합니다.

    $ oc get crd | grep noderesourcetopologies
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                                              CREATED AT
    noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 NUMA 인식 스케줄러 이름이 NUMA 인식 워크로드에 지정된 이름과 일치하는지 확인합니다.

    $ oc get numaresourcesschedulers.nodetopology.openshift.io numaresourcesscheduler -o json | jq '.status.schedulerName'
    Copy to Clipboard Toggle word wrap

    출력 예

    topo-aware-scheduler
    Copy to Clipboard Toggle word wrap

  3. NUMA 인식 가능 노드에 noderesourcetopologies CR이 적용되는지 확인합니다. 다음 명령을 실행합니다.

    $ oc get noderesourcetopologies.topology.node.k8s.io
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                    AGE
    compute-0.example.com   17h
    compute-1.example.com   17h
    Copy to Clipboard Toggle word wrap

    참고

    노드 수는 머신 구성 풀(mcp) 작업자 정의로 구성된 작업자 노드 수와 같아야 합니다.

  4. 다음 명령을 실행하여 예약 가능한 모든 노드에 대한 NUMA 영역 단위를 확인합니다.

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    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: ""
    Copy to Clipboard Toggle word wrap

    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
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                     AGE
      numaresourcesscheduler   92m
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler
      Copy to Clipboard Toggle word wrap

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
      Copy to Clipboard Toggle word wrap

  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.17"
      cacheResyncPeriod: "5s" 
    1
    Copy to Clipboard Toggle word wrap
    1
    스케줄러 캐시의 동기화를 위해 간격 값을 초 단위로 입력합니다. 값 5s 는 대부분의 구현에 일반적인 값입니다.
  3. 다음 명령을 실행하여 업데이트된 NUMAResourcesScheduler 리소스를 만듭니다.

    $ oc create -f nro-scheduler-cacheresync.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
    Copy to Clipboard Toggle word wrap

검증 단계

  1. NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.

      $ oc get crd | grep numaresourcesschedulers
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

      $ oc get numaresourcesschedulers.nodetopology.openshift.io
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                     AGE
      numaresourcesscheduler   3h26m
      Copy to Clipboard Toggle word wrap

  2. 스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      출력 예

      ...
      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"
      Copy to Clipboard Toggle word wrap

9.5.2. NUMA 인식 스케줄러 로그 확인

로그를 검토하여 NUMA 인식 스케줄러의 문제를 해결합니다. 필요한 경우 NUMAResourcesScheduler 리소스의 spec.logLevel 필드를 수정하여 스케줄러 로그 수준을 늘릴 수 있습니다. 허용 가능한 값은 Normal,DebugTrace 이며 Trace 는 가장 자세한 옵션입니다.

참고

보조 스케줄러의 로그 수준을 변경하려면 실행 중인 스케줄러 리소스를 삭제하고 변경된 로그 수준으로 다시 배포합니다. 이 다운타임 동안 새 워크로드를 예약할 수 없습니다.

사전 요구 사항

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

프로세스

  1. 현재 실행 중인 NUMAResourcesScheduler 리소스를 삭제합니다.

    1. 다음 명령을 실행하여 활성 NUMAResourcesScheduler 를 가져옵니다.

      $ oc get NUMAResourcesScheduler
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                     AGE
      numaresourcesscheduler   90m
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 보조 스케줄러 리소스를 삭제합니다.

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler
      Copy to Clipboard Toggle word wrap

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted
      Copy to Clipboard Toggle word wrap

  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.17"
      logLevel: Debug
    Copy to Clipboard Toggle word wrap
  3. 다음 명령을 실행하여 업데이트된 Debug logging NUMAResourcesScheduler 리소스를 만듭니다.

    $ oc create -f nro-scheduler-debug.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created
    Copy to Clipboard Toggle word wrap

검증 단계

  1. NUMA 인식 스케줄러가 성공적으로 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 CRD가 성공적으로 생성되었는지 확인합니다.

      $ oc get crd | grep numaresourcesschedulers
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 새 사용자 정의 스케줄러를 사용할 수 있는지 확인합니다.

      $ oc get numaresourcesschedulers.nodetopology.openshift.io
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                     AGE
      numaresourcesscheduler   3h26m
      Copy to Clipboard Toggle word wrap

  2. 스케줄러의 로그에 증가된 로그 수준이 표시되는지 확인합니다.

    1. 다음 명령을 실행하여 openshift-numaresources 네임스페이스에서 실행 중인 Pod 목록을 가져옵니다.

      $ oc get pods -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                                               READY   STATUS    RESTARTS   AGE
      numaresources-controller-manager-d87d79587-76mrm   1/1     Running   0          46h
      numaresourcesoperator-worker-5wm2k                 2/2     Running   0          45h
      numaresourcesoperator-worker-pb75c                 2/2     Running   0          45h
      secondary-scheduler-7976c4d466-qm4sc               1/1     Running   0          21m
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 보조 스케줄러 Pod의 로그를 가져옵니다.

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources
      Copy to Clipboard Toggle word wrap

      출력 예

      ...
      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"
      Copy to Clipboard Toggle word wrap

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]}"
    Copy to Clipboard Toggle word wrap

    출력 예

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}
    Copy to Clipboard Toggle word wrap

  2. 이전 단계의 name 에 대한 값을 사용하여 관심 있는 데몬 세트의 레이블을 가져옵니다.

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"
    Copy to Clipboard Toggle word wrap

    출력 예

    {"name":"resource-topology"}
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 resource-topology 레이블을 사용하여 Pod를 가져옵니다.

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                                 READY   STATUS    RESTARTS   AGE    IP            NODE
    numaresourcesoperator-worker-5wm2k   2/2     Running   0          2d1h   10.135.0.64   compute-0.example.com
    numaresourcesoperator-worker-pb75c   2/2     Running   0          2d1h   10.132.2.33   compute-1.example.com
    Copy to Clipboard Toggle word wrap

  4. 문제 해결 중인 노드에 해당하는 작업자 Pod에서 실행 중인 resource-topology-exporter 컨테이너의 로그를 검사합니다. 다음 명령을 실행합니다.

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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"
Copy to Clipboard Toggle word wrap

이 로그 메시지는 필요한 구성이 있는 kubeletconfig 가 클러스터에 제대로 적용되지 않아 RTE configmap 이 누락되었음을 나타냅니다. 예를 들어 다음 클러스터에 numaresourcesoperator-worker configmap CR (사용자 정의 리소스)이 없습니다.

$ oc get configmap
Copy to Clipboard Toggle word wrap

출력 예

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
Copy to Clipboard Toggle word wrap

올바르게 구성된 클러스터에서 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
      Copy to Clipboard Toggle word wrap

      출력 예

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 mcp 레이블을 확인합니다.

      $ oc get mcp worker -o yaml
      Copy to Clipboard Toggle word wrap

      출력 예

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""
      Copy to Clipboard Toggle word wrap

      cnf-worker-tuning: enabled 레이블은 MachineConfigPool 오브젝트에 없습니다.

  2. 누락된 라벨을 포함하도록 MachineConfigPool CR을 편집합니다. 예를 들면 다음과 같습니다.

    $ oc edit mcp worker -o yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    labels:
      machineconfiguration.openshift.io/mco-built-in: ""
      pools.operator.machineconfiguration.openshift.io/worker: ""
      cnf-worker-tuning: enabled
    Copy to Clipboard Toggle word wrap

  3. 레이블 변경 사항을 적용하고 클러스터가 업데이트된 구성을 적용할 때까지 기다립니다. 다음 명령을 실행합니다.

검증

  • 누락된 numaresourcesoperator-worker configmap CR이 적용되었는지 확인합니다.

    $ oc get configmap
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    Copy to Clipboard Toggle word wrap

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.17
    Copy to Clipboard Toggle word wrap

10장. 확장성 및 성능 최적화

10.1. 스토리지 최적화

스토리지를 최적화하면 모든 리소스에서 스토리지 사용을 최소화할 수 있습니다. 관리자는 스토리지를 최적화하여 기존 스토리지 리소스가 효율적으로 작동하도록 합니다.

10.1.1. 사용 가능한 영구 스토리지 옵션

OpenShift Container Platform 환경을 최적화할 수 있도록 영구 스토리지 옵션에 대해 알아보십시오.

Expand
표 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 구성 요소가 데이터를 쓰는 기본 디렉터리가 요약되어 있습니다.

Expand
표 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.2. 라우팅 최적화

OpenShift Container Platform HAProxy 라우터는 성능을 최적화하도록 스케일링하거나 구성할 수 있습니다.

10.2.1. 기본 Ingress 컨트롤러(라우터) 성능

OpenShift Container Platform Ingress 컨트롤러 또는 라우터는 경로 및 인그레스를 사용하여 구성된 애플리케이션 및 서비스의 수신 트래픽의 수신 지점입니다.

초당 처리된 HTTP 요청 측면에서 단일 HAProxy 라우터 성능을 평가할 때 성능은 여러 요인에 따라 달라집니다. 특히 중요한 요인은 다음과 같습니다.

  • HTTP 연결 유지/닫기 모드
  • 경로 유형
  • TLS 세션 재개 클라이언트 지원
  • 대상 경로당 동시 연결 수
  • 대상 경로 수
  • 백엔드 서버 페이지 크기
  • 기본 인프라(네트워크, CPU 등)

특정 환경의 성능은 달라질 수 있으나 Red Hat 랩은 크기가 4 vCPU/16GB RAM인 퍼블릭 클라우드 인스턴스에서 테스트합니다. 1kB 정적 페이지를 제공하는 백엔드에서 종료한 100개의 경로를 처리하는 단일 HAProxy 라우터가 처리할 수 있는 초당 트랜잭션 수는 다음과 같습니다.

HTTP 연결 유지 모드 시나리오에서는 다음과 같습니다.

Expand
EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

HTTP 닫기(연결 유지 제외) 시나리오에서는 다음과 같습니다.

Expand
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배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.

Expand
애플리케이션 수애플리케이션 유형

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 값을 업데이트할 수 있습니다.

Expand
매개변수설명

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}}]}}}}'
Copy to Clipboard Toggle word wrap

검증

$ 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
Copy to Clipboard Toggle word wrap

10.2.3. HAProxy 재로드 간격 구성

경로와 연결된 경로 또는 끝점을 업데이트하면 OpenShift Container Platform 라우터에서 HAProxy 구성을 업데이트합니다. 그런 다음 HAProxy는 이러한 변경 사항을 적용하기 위해 업데이트된 구성을 다시 로드합니다. HAProxy가 다시 로드되면 업데이트된 구성을 사용하여 새 연결을 처리하는 새 프로세스가 생성됩니다.

HAProxy는 이러한 연결이 모두 종료될 때까지 기존 프로세스를 계속 실행하여 기존 연결을 처리합니다. 이전 프로세스에 수명이 긴 연결이 있는 경우 이러한 프로세스는 리소스를 누적하고 사용할 수 있습니다.

기본 최소 HAProxy 재로드 간격은 5초입니다. spec.tuningOptions.reloadInterval 필드를 사용하여 Ingress 컨트롤러를 구성하여 최소 다시 로드 간격을 더 오래 설정할 수 있습니다.

주의

최소 HAProxy 재로드 간격에 대해 큰 값을 설정하면 경로 및 엔드포인트에 대한 업데이트를 관찰하는 대기 시간이 발생할 수 있습니다. 위험을 줄이려면 업데이트에 허용되는 대기 시간보다 큰 값을 설정하지 마십시오.

프로세스

  • 다음 명령을 실행하여 기본 Ingress 컨트롤러의 최소 HAProxy 재로드 간격을 15초로 변경합니다.

    $ oc -n openshift-ingress-operator patch ingresscontrollers/default --type=merge --patch='{"spec":{"tuningOptions":{"reloadInterval":"15s"}}}'
    Copy to Clipboard Toggle word wrap

10.3. 네트워킹 최적화

OVN-Kubernetes 는 Geneve와 유사한 프로토콜을 사용하여 노드 간 트래픽을 터널링하기 위해 일반 네트워크 가상화 캡슐화(Geneve)를 사용합니다. 이 네트워크는 NIC(네트워크 인터페이스 컨트롤러) 오프로드를 사용하여 조정할 수 있습니다.

Geneve는 VLAN에 비해 네트워크가 4096개에서 1억 개 이상으로 증가, 물리적 네트워크 전반에 걸쳐 계층 2 연결과 같은 이점을 제공합니다. 이를 통해 서비스 뒤에 있는 모든 Pod가 서로 다른 시스템에서 실행되는 경우에도 서로 통신할 수 있습니다.

Geneve는 UDP(사용자 데이터그램 프로토콜) 패킷의 터널링된 모든 트래픽을 캡슐화합니다. 그러나 이로 인해 CPU 사용량이 증가합니다. 이러한 외부 및 내부 패킷은 전송 중에 데이터가 손상되지 않도록하기 위해 일반 체크섬 규칙을 따릅니다. CPU 성능에 따라 이러한 추가 처리 오버헤드는 처리량이 감소하고 기존 비 오버레이 네트워크에 비해 대기 시간이 증가할 수 있습니다.

클라우드, 가상 머신, 베어 메탈 CPU 성능은 많은 Gbps의 네트워크 처리량을 처리할 수 있습니다. 10 또는 40Gbps와 같은 높은 대역폭 링크를 사용하는 경우 성능이 저하될 수 있습니다. 이는 Geneve 기반 환경에서 알려진 문제이며 컨테이너 또는 OpenShift Container Platform에만 국한되지 않습니다. Geneve 또는 VXLAN 터널에 의존하는 네트워크는 터널 구현으로 인해 유사하게 수행됩니다.

Gbps을 초과하여 푸시하려는 경우 다음을 수행할 수 있습니다.

  • BGP(Border Gateway Protocol)와 같은 다양한 라우팅 기술을 구현하는 네트워크 플러그인을 평가합니다.
  • Geneve-offload 가능 네트워크 어댑터를 사용합니다. Geneve-offload는 패킷 체크섬 계산 및 관련 CPU 오버헤드를 시스템 CPU에서 네트워크 어댑터의 전용 하드웨어로 이동합니다. 이를 통해 Pod 및 애플리케이션에서 사용할 CPU 사이클을 확보하고 사용자는 네트워크 인프라의 전체 대역폭을 사용할 수 있습니다.

Geneve-offload는 대기 시간을 단축하지 않습니다. 그러나 대기 시간 테스트에서도 CPU 사용량이 감소합니다.

10.3.1. 네트워크에 대한 MTU 최적화

중요한 MTU(최대 전송 단위)에는 NIC(네트워크 인터페이스 컨트롤러) MTU와 클러스터 네트워크 MTU가 있습니다.

NIC MTU는 OpenShift Container Platform을 설치할 때만 구성됩니다. MTU는 네트워크 NIC에서 지원되는 최대 값과 작거나 같아야 합니다. 처리량을 최적화하려면 가능한 가장 큰 값을 선택합니다. 최소 지연을 최적화하려면 더 낮은 값을 선택합니다.

OVN 및 Geneve의 경우 MTU는 NIC MTU보다 최소 100바이트 작아야 합니다.

10.3.3. IPsec 영향

노드 호스트의 암호화 및 암호 해독은 CPU를 사용하기 때문에 사용 중인 IP 보안 시스템에 관계없이 암호화를 사용할 때 노드의 처리량과 CPU 사용량 모두에서 성능에 영향을 미칩니다.

IPsec은 NIC에 도달하기 전에 IP 페이로드 수준에서 트래픽을 암호화하여 NIC 오프로드에 사용되는 필드를 보호합니다. 즉, IPSec가 활성화되면 일부 NIC 가속 기능을 사용할 수 없으며 처리량이 감소하고 CPU 사용량이 증가합니다.

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
    Copy to Clipboard Toggle word wrap
  2. 다음 명령을 실행하여 마운트 네임스페이스 MachineConfig CR을 적용합니다.

    $ oc apply -f mount_namespace_config.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    machineconfig.machineconfiguration.openshift.io/99-kubens-master created
    machineconfig.machineconfiguration.openshift.io/99-kubens-worker created
    Copy to Clipboard Toggle word wrap

  3. MachineConfig CR은 클러스터에 적용되는 데 최대 30분이 걸릴 수 있습니다. 다음 명령을 실행하여 MachineConfig CR의 상태를 확인할 수 있습니다.

    $ oc get mcp
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME     CONFIG                                             UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master   rendered-master-03d4bc4befb0f4ed3566a2c8f7636751   False     True       False      3              0                   0                     0                      45m
    worker   rendered-worker-10577f6ab0117ed1825f8af2ac687ddf   False     True       False      3              1                   1
    Copy to Clipboard Toggle word wrap

  4. 다음 명령을 실행한 후 MachineConfig CR이 모든 컨트롤 플레인 및 작업자 노드에 성공적으로 적용될 때까지 기다립니다.

    $ oc wait --for=condition=Updated mcp --all --timeout=30m
    Copy to Clipboard Toggle word wrap

    출력 예

    machineconfigpool.machineconfiguration.openshift.io/master condition met
    machineconfigpool.machineconfiguration.openshift.io/worker condition met
    Copy to Clipboard Toggle word wrap

검증

클러스터 호스트의 캡슐화를 확인하려면 다음 명령을 실행합니다.

  1. 클러스터 호스트에 대한 디버그 쉘을 엽니다.

    $ oc debug node/<node_name>
    Copy to Clipboard Toggle word wrap
  2. chroot 세션을 엽니다.

    sh-4.4# chroot /host
    Copy to Clipboard Toggle word wrap
  3. systemd 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/1/ns/mnt
    Copy to Clipboard Toggle word wrap

    출력 예

    mnt:[4026531953]
    Copy to Clipboard Toggle word wrap

  4. kubelet 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/$(pgrep kubelet)/ns/mnt
    Copy to Clipboard Toggle word wrap

    출력 예

    mnt:[4026531840]
    Copy to Clipboard Toggle word wrap

  5. CRI-O 마운트 네임스페이스를 확인합니다.

    sh-4.4# readlink /proc/$(pgrep crio)/ns/mnt
    Copy to Clipboard Toggle word wrap

    출력 예

    mnt:[4026531840]
    Copy to Clipboard Toggle word wrap

이러한 명령은 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>
    Copy to Clipboard Toggle word wrap
  2. 제공된 kubensenter 스크립트를 root 사용자로 사용하여 명령을 실행합니다. Kubernetes 네임스페이스 내에서 단일 명령을 실행하려면 명령과 kubensenter 스크립트에 인수를 제공합니다. 예를 들어 Kubernetes 네임스페이스 내에서 findmnt 명령을 실행하려면 다음 명령을 실행합니다.

    [core@control-plane-1 ~]$ sudo kubensenter findmnt
    Copy to Clipboard Toggle word wrap

    출력 예

    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
    ...
    Copy to Clipboard Toggle word wrap

  3. Kubernetes 네임스페이스 내에서 새 대화형 쉘을 시작하려면 인수 없이 kubensenter 스크립트를 실행합니다.

    [core@control-plane-1 ~]$ sudo kubensenter
    Copy to Clipboard Toggle word wrap

    출력 예

    kubensenter: Autodetect: kubens.service namespace found at /run/kubens/mnt
    Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

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 명령 및 적절한 베어 메탈 컴퓨팅 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

베어 메탈 호스트를 설명하는 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>
    Copy to Clipboard Toggle word wrap
    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 주석을 추가하여 자동 스케일링을 구성할 컴퓨팅 머신 세트에 주석을 답니다. <machineset>를 컴퓨팅 머신 세트의 이름으로 바꿉니다.

    $ oc annotate machineset <machineset> -n openshift-machine-api 'metal3.io/autoscale-to-hosts=<any_value>'
    Copy to Clipboard Toggle word wrap

    새로 확장된 머신이 시작될 때까지 기다립니다.

참고

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'
    Copy to Clipboard Toggle word wrap

    새 머신이 시작될 때까지 기다립니다.

    참고

    BareMetalHost 오브젝트를 사용하여 클러스터에 머신을 생성하고 레이블 또는 선택기가 BareMetalHost에서 변경되면 Machine 오브젝트가 생성된 MachineSet에 대해 BareMetalHost 오브젝트가 계속 계산됩니다.

  2. 프로비저닝 사용 사례에서 다음 명령을 사용하여 재부팅이 완료된 후 주석을 제거합니다.

    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'
    Copy to Clipboard Toggle word wrap

12.1. 대규모 페이지의 기능

메모리는 페이지라는 블록으로 관리됩니다. 대부분의 시스템에서 한 페이지는 4Ki입니다. 1Mi 메모리는 256페이지와 같고 1Gi 메모리는 256,000페이지에 해당합니다. CPU에는 하드웨어에서 이러한 페이지 목록을 관리하는 내장 메모리 관리 장치가 있습니다. TLB(Translation Lookaside Buffer)는 가상-물리적 페이지 매핑에 대한 소규모 하드웨어 캐시입니다. TLB에 하드웨어 명령어로 전달된 가상 주소가 있으면 매핑을 신속하게 확인할 수 있습니다. 가상 주소가 없으면 TLB 누락이 발생하고 시스템에서 소프트웨어 기반 주소 변환 속도가 느려져 성능 문제가 발생합니다. TLB 크기는 고정되어 있으므로 TLB 누락 가능성을 줄이는 유일한 방법은 페이지 크기를 늘리는 것입니다.

대규모 페이지는 4Ki보다 큰 메모리 페이지입니다. x86_64 아키텍처에서 일반적인 대규모 페이지 크기는 2Mi와 1Gi입니다. 다른 아키텍처에서는 크기가 달라집니다. 대규모 페이지를 사용하려면 애플리케이션이 인식할 수 있도록 코드를 작성해야 합니다. THP(투명한 대규모 페이지)에서는 애플리케이션 지식 없이 대규모 페이지 관리를 자동화하려고 하지만 한계가 있습니다. 특히 페이지 크기 2Mi로 제한됩니다. THP에서는 THP 조각 모음 작업으로 인해 메모리 사용률이 높아지거나 조각화가 발생하여 노드에서 성능이 저하될 수 있으며 이로 인해 메모리 페이지가 잠길 수 있습니다. 이러한 이유로 일부 애플리케이션은 THP 대신 사전 할당된 대규모 페이지를 사용하도록 설계(또는 권장)할 수 있습니다.

OpenShift Container Platform에서는 Pod의 애플리케이션이 사전 할당된 대규모 페이지를 할당하고 사용할 수 있습니다.

12.2. 앱에서 대규모 페이지를 사용하는 방법

노드에서 대규모 페이지 용량을 보고하려면 노드가 대규모 페이지를 사전 할당해야 합니다. 노드는 단일 크기의 대규모 페이지만 사전 할당할 수 있습니다.

대규모 페이지는 hugepages-<size> 리소스 이름으로 컨테이너 수준 리소스 요구사항에 따라 사용할 수 있습니다. 여기서 크기는 특정 노드에서 지원되는 정수 값이 사용된 가장 간단한 바이너리 표현입니다. 예를 들어 노드에서 2,048KiB 페이지 크기를 지원하는 경우 예약 가능한 리소스 hugepages-2Mi를 공개합니다. CPU 또는 메모리와 달리 대규모 페이지는 초과 커밋을 지원하지 않습니다.

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
Copy to Clipboard Toggle word wrap
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과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.

12.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
    Copy to Clipboard Toggle word wrap

    <.> 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
    Copy to Clipboard Toggle word wrap

검증

  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
    Copy to Clipboard Toggle word wrap

    출력 예

    REQUESTS_HUGEPAGES_1GI=2147483648
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    출력 예

    2
    Copy to Clipboard Toggle word wrap

12.4. 부팅 시 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. 대규모 페이지 예약은 부팅 시 예약하는 방법과 런타임 시 예약하는 방법 두 가지가 있습니다. 부팅 시 예약은 메모리가 아직 많이 조각화되어 있지 않으므로 성공할 가능성이 높습니다. Node Tuning Operator는 현재 특정 노드에서 대규모 페이지에 대한 부팅 시 할당을 지원합니다.

프로세스

노드 재부팅을 최소화하려면 다음 단계를 순서대로 수행해야 합니다.

  1. 동일한 대규모 페이지 설정이 필요한 모든 노드에 하나의 레이블을 지정합니다.

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
    Copy to Clipboard Toggle word wrap
  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
    Copy to Clipboard Toggle word wrap
    1
    Tuned 리소스의 namehugepages로 설정합니다.
    2
    대규모 페이지를 할당할 profile 섹션을 설정합니다.
    3
    일부 플랫폼에서는 다양한 크기의 대규모 페이지를 지원하므로 매개변수 순서가 중요합니다.
    4
    머신 구성 풀 기반 일치를 활성화합니다.
  3. Tuned hugepages 오브젝트를 생성합니다.

    $ oc create -f hugepages-tuned-boottime.yaml
    Copy to Clipboard Toggle word wrap
  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: ""
    Copy to Clipboard Toggle word wrap
  5. 머신 구성 풀을 생성합니다.

    $ oc create -f hugepages-mcp.yaml
    Copy to Clipboard Toggle word wrap

조각화되지 않은 메모리가 충분한 경우 worker-hp 머신 구성 풀의 모든 노드에 50개의 2Mi 대규모 페이지가 할당되어 있어야 합니다.

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
Copy to Clipboard Toggle word wrap
참고

TuneD 부트로더 플러그인은 RHCOS(Red Hat Enterprise Linux CoreOS) 작업자 노드만 지원합니다.

12.5. 투명한 대규모 페이지 비활성화

</