검색

15.3. 성능 프로필을 사용하여 짧은 대기 시간을 실현하도록 노드 튜닝

download PDF

성능 프로필을 사용하면 특정 머신 구성 풀에 속한 노드의 대기 시간 튜닝 측면을 제어할 수 있습니다. 설정을 지정하면 PerformanceProfile 오브젝트가 실제 노드 수준 튜닝을 수행하는 여러 오브젝트로 컴파일됩니다.

  • MachineConfig 파일은 노드를 조작합니다.
  • KubeletConfig 파일은 토폴로지 관리자, CPU 관리자 및 OpenShift Container Platform 노드를 구성합니다.
  • Tuned 프로필은 Node Tuning Operator를 구성합니다.

성능 프로필을 사용하여 커널을 kernel-rt로 업데이트할지 여부를 지정하고, 대규모 페이지를 할당하고, CPU를 분할하여 하우스키핑 작업 수행 또는 워크로드 실행에 사용할 CPU를 분할할 수 있습니다.

참고

PerformanceProfile 오브젝트를 수동으로 생성하거나 Performance Profile Creator(PPC)를 사용하여 성능 프로필을 생성할 수 있습니다. PPC에 대한 자세한 내용은 아래 추가 리소스를 참조하십시오.

성능 프로파일의 예

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
 name: performance
spec:
 cpu:
  isolated: "4-15" 1
  reserved: "0-3" 2
 hugepages:
  defaultHugepagesSize: "1G"
  pages:
  - size: "1G"
    count: 16
    node: 0
 realTimeKernel:
  enabled: true  3
 numa:  4
  topologyPolicy: "best-effort"
 nodeSelector:
  node-role.kubernetes.io/worker-cnf: "" 5

1
이 필드를 사용하여 워크로드의 애플리케이션 컨테이너와 함께 사용할 특정 CPU를 분리합니다. 하이퍼 스레딩이 활성화된 경우 오류 없이 Pod를 실행할 수 있도록 분리된 CPU 수를 설정합니다.
2
이 필드를 사용하여 하우스키핑을 위해 인프라 컨테이너와 함께 사용할 특정 CPU를 예약합니다.
3
이 필드를 사용하여 노드에 실시간 커널을 설치합니다. 유효한 값은 true 또는 false입니다. true 값을 설정하면 실시간 커널이 설치됩니다.
4
이 필드를 사용하여 토폴로지 관리자 정책을 구성합니다. 유효한 값은 none(기본값), best-effort, restrictedsingle-numa-node입니다. 자세한 내용은 토폴로지 관리자 정책을 참조하십시오.
5
이 필드를 사용하여 특정 노드에 성능 프로파일을 적용할 노드 선택기를 지정합니다.

추가 리소스

  • PPC(Performance Profile Creator)를 사용하여 성능 프로필을 생성하는 방법에 대한 자세한 내용은 성능 프로필 생성을 참조하십시오.

15.3.1. 대규모 페이지 구성

노드는 OpenShift Container Platform 클러스터에서 사용되는 대규모 페이지를 사전 할당해야 합니다. Node Tuning Operator를 사용하여 특정 노드에 대규모 페이지를 할당합니다.

OpenShift Container Platform에서는 대규모 페이지를 생성하고 할당하는 방법을 제공합니다. Node Tuning Operator는 성능 프로필을 사용하여 이 작업을 더 쉽게 수행할 수 있는 방법을 제공합니다.

예를 들어 성능 프로필의 hugepages pages 섹션에서 size, countnode(선택사항)로 된 여러 블록을 지정할 수 있습니다.

hugepages:
   defaultHugepagesSize: "1G"
   pages:
   - size:  "1G"
     count:  4
     node:  0 1
1
node는 대규모 페이지가 할당된 NUMA 노드입니다. node를 생략하면 페이지가 모든 NUMA 노드에 균등하게 분산됩니다.
참고

관련 머신 구성 풀 상태에 업데이트가 완료된 것으로 나타날 때까지 기다립니다.

대규모 페이지를 할당하기 위해 수행해야 하는 구성 단계는 이것이 전부입니다.

검증

  • 구성을 검증하려면 노드의 /proc/meminfo 파일을 참조하십시오.

    $ oc debug node/ip-10-0-141-105.ec2.internal
    # grep -i huge /proc/meminfo

    출력 예

    AnonHugePages:    ###### ##
    ShmemHugePages:        0 kB
    HugePages_Total:       2
    HugePages_Free:        2
    HugePages_Rsvd:        0
    HugePages_Surp:        0
    Hugepagesize:       #### ##
    Hugetlb:            #### ##

  • oc describe를 사용하여 새 크기를 보고합니다.

    $ oc describe node worker-0.ocp4poc.example.com | grep -i huge

    출력 예

                                       hugepages-1g=true
     hugepages-###:  ###
     hugepages-###:  ###

15.3.2. 여러 대규모 페이지 크기 할당

동일한 컨테이너에서 다양한 크기의 대규모 페이지를 요청할 수 있습니다. 이 경우 다양한 대규모 페이지 크기 요구사항이 있는 컨테이너로 구성된 더 복잡한 Pod를 정의할 수 있습니다.

예를 들어 1G2M 크기를 정의할 수 있으며 Node Tuning Operator는 다음과 같이 노드에서 두 크기를 모두 구성합니다.

spec:
  hugepages:
    defaultHugepagesSize: 1G
    pages:
    - count: 1024
      node: 0
      size: 2M
    - count: 4
      node: 1
      size: 1G

15.3.3. IRQ 동적 로드 밸런싱을 위한 노드 구성

IRQ 동적 로드 밸런싱을 처리하도록 클러스터 노드를 구성하려면 다음을 수행합니다.

  1. cluster-admin 역할의 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
  2. performance.openshift.io/v2를 사용하도록 성능 프로파일의 apiVersion을 설정합니다.
  3. globallyDisableIrqLoadBalancing 필드를 삭제제거하거나 false로 설정합니다.
  4. 적절한 분리 및 예약된 CPU를 설정합니다. 다음 스니펫에서는 두 개의 CPU를 예약하는 프로파일을 보여줍니다. isolated CPU 세트에서 실행되는 Pod에 대해 IRQ 로드 밸런싱이 활성화됩니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: dynamic-irq-profile
    spec:
      cpu:
        isolated: 2-5
        reserved: 0-1
    ...
    참고

    예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

  5. 전용 CPU를 사용하는 pod를 생성하고 irq-load-balancing.crio.iocpu-quota.crio.io 주석을 disable로 설정합니다. 예를 들어 다음과 같습니다.

    apiVersion: v1
    kind: Pod
    metadata:
      name: dynamic-irq-pod
      annotations:
         irq-load-balancing.crio.io: "disable"
         cpu-quota.crio.io: "disable"
    spec:
      containers:
      - name: dynamic-irq-pod
        image: "registry.redhat.io/openshift4/cnf-tests-rhel8:v4.11"
        command: ["sleep", "10h"]
        resources:
          requests:
            cpu: 2
            memory: "200M"
          limits:
            cpu: 2
            memory: "200M"
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      runtimeClassName: performance-dynamic-irq-profile
    ...
  6. performance-<profile_name> 형식으로 pod runtimeClassName을 입력합니다. 여기서<profile_name>은 PerformanceProfile YAML의 name입니다 (예: performance- dynamic-irq-profile).
  7. 노드 선택기를 cnf-worker 을 대상으로 설정합니다.
  8. Pod가 올바르게 실행되고 있는지 확인합니다. 상태가 running이어야 하며 올바른 cnf-worker 노드를 설정해야 합니다.

    $ oc get pod -o wide

    예상 출력

    NAME              READY   STATUS    RESTARTS   AGE     IP             NODE          NOMINATED NODE   READINESS GATES
    dynamic-irq-pod   1/1     Running   0          5h33m   <ip-address>   <node-name>   <none>           <none>

  9. IRQ 동적 로드 밸런싱을 위해 구성된 Pod가 실행되는 CPU를 가져옵니다.

    $ oc exec -it dynamic-irq-pod -- /bin/bash -c "grep Cpus_allowed_list /proc/self/status | awk '{print $2}'"

    예상 출력

    Cpus_allowed_list:  2-3

  10. 노드 구성이 올바르게 적용되었는지 확인합니다. 구성을 확인하려면 노드에 SSH를 실행합니다.

    $ oc debug node/<node-name>

    예상 출력

    Starting pod/<node-name>-debug ...
    To use host binaries, run `chroot /host`
    
    Pod IP: <ip-address>
    If you don't see a command prompt, try pressing enter.
    
    sh-4.4#

  11. 노드 파일 시스템을 사용할 수 있는지 확인합니다.

    sh-4.4# chroot /host

    예상 출력

    sh-4.4#

  12. 기본 시스템 CPU 선호도 마스크에 dynamic-irq-pod CPU (예: CPU 2 및 3)가 포함되지 않도록 합니다.

    $ cat /proc/irq/default_smp_affinity

    출력 예

    33

  13. IRQ가 dynamic-irq-pod CPU에서 실행되도록 구성되어 있지 않은지 확인합니다.

    find /proc/irq/ -name smp_affinity_list -exec sh -c 'i="$1"; mask=$(cat $i); file=$(echo $i); echo $file: $mask' _ {} \;

    출력 예

    /proc/irq/0/smp_affinity_list: 0-5
    /proc/irq/1/smp_affinity_list: 5
    /proc/irq/2/smp_affinity_list: 0-5
    /proc/irq/3/smp_affinity_list: 0-5
    /proc/irq/4/smp_affinity_list: 0
    /proc/irq/5/smp_affinity_list: 0-5
    /proc/irq/6/smp_affinity_list: 0-5
    /proc/irq/7/smp_affinity_list: 0-5
    /proc/irq/8/smp_affinity_list: 4
    /proc/irq/9/smp_affinity_list: 4
    /proc/irq/10/smp_affinity_list: 0-5
    /proc/irq/11/smp_affinity_list: 0
    /proc/irq/12/smp_affinity_list: 1
    /proc/irq/13/smp_affinity_list: 0-5
    /proc/irq/14/smp_affinity_list: 1
    /proc/irq/15/smp_affinity_list: 0
    /proc/irq/24/smp_affinity_list: 1
    /proc/irq/25/smp_affinity_list: 1
    /proc/irq/26/smp_affinity_list: 1
    /proc/irq/27/smp_affinity_list: 5
    /proc/irq/28/smp_affinity_list: 1
    /proc/irq/29/smp_affinity_list: 0
    /proc/irq/30/smp_affinity_list: 0-5

일부 IRQ 컨트롤러는 IRQ 재조정을 지원하지 않으며 항상 모든 온라인 CPU를 IRQ 마스크로 공개합니다. 이러한 IRQ 컨트롤러는 CPU 0에서 효과적으로 실행됩니다. 호스트 구성에 대한 보다 자세한 내용은 호스트로 SSH를 실행하고 <irq-num>을 쿼리할 CPU 번호를 입력하여 다음을 실행합니다.

$ cat /proc/irq/<irq-num>/effective_affinity

15.3.4. 클러스터의 하이퍼 스레딩 구성

OpenShift Container Platform 클러스터의 하이퍼 스레딩을 구성하려면 성능 프로파일의 CPU 스레드를 예약 또는 분리된 CPU 풀에 구성된 동일한 코어로 설정합니다.

참고

성능 프로파일을 구성하고 호스트의 하이퍼 스레딩 구성을 변경하는 경우 PerformanceProfile YAML의 CPU isolatedreserved 필드를 새 구성과 일치하도록 업데이트해야 합니다.

주의

이전에 활성화된 호스트 하이퍼 스레딩 구성을 비활성화하면 PerformanceProfile YAML에 나열된 CPU 코어 ID가 올바르지 않을 수 있습니다. 이렇게 잘못된 구성으로 인해 나열된 CPU를 더 이상 찾을 수 없으므로 노드를 사용할 수 없게 될 가능성이 있습니다.

사전 요구 사항

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.
  • OpenShift CLI(oc)를 설치합니다.

프로세스

  1. 구성할 호스트의 모든 CPU에서 실행중인 스레드를 확인합니다.

    클러스터에 로그인하고 다음 명령을 실행하여 호스트 CPU에서 실행중인 스레드를 볼 수 있습니다.

    $ lscpu --all --extended

    출력 예

    CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE MAXMHZ    MINMHZ
    0   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    1   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    2   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    3   0    0      3    3:3:3:0       yes    4800.0000 400.0000
    4   0    0      0    0:0:0:0       yes    4800.0000 400.0000
    5   0    0      1    1:1:1:0       yes    4800.0000 400.0000
    6   0    0      2    2:2:2:0       yes    4800.0000 400.0000
    7   0    0      3    3:3:3:0       yes    4800.0000 400.0000

    이 예에서는 4개의 물리적 CPU 코어에서 실행 중인 논리 CPU 코어가 8개 있습니다. CPU0 및 CPU4는 물리적 Core0에서 실행되고 CPU1 및 CPU5는 물리적 Core 1에서 실행되고 있습니다.

    또는 특정 물리적 CPU 코어(다음 예에서는cpu0)에 설정된 스레드를 보려면 명령 프롬프트를 열고 다음을 실행합니다.

    $ cat /sys/devices/system/cpu/cpu0/topology/thread_siblings_list

    출력 예

    0-4

  2. PerformanceProfile YAML에서 분리 및 예약된 CPU를 적용합니다. 예를 들어 논리 코어 CPU0 및 CPU4를 분리된 로, 논리 코어 CPU1을 CPU3으로, CPU5를 CPU7으로 설정할 수 있습니다. 예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

    ...
      cpu:
        isolated: 0,4
        reserved: 1-3,5-7
    ...
    참고

    예약 및 격리된 CPU 풀이 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

중요

하이퍼 스레딩은 대부분의 Intel 프로세서에서 기본적으로 활성화되어 있습니다. 하이퍼 스레딩을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.

15.3.4.1. 지연 시간이 짧은 애플리케이션의 하이퍼 스레딩 비활성화

지연 시간이 짧은 프로세스를 위해 클러스터를 구성할 때 클러스터를 배포하기 전에 하이퍼 스레딩을 비활성화할지 여부를 고려하십시오. 하이퍼 스레딩을 비활성화하려면 다음을 수행합니다.

  1. 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
  2. nosmt를 추가 커널 인수로 설정합니다. 다음 성능 프로파일 예에서는 이 설정에 대해 설명합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: example-performanceprofile
    spec:
      additionalKernelArgs:
        - nmi_watchdog=0
        - audit=0
        - mce=off
        - processor.max_cstate=1
        - idle=poll
        - intel_idle.max_cstate=0
        - nosmt
      cpu:
        isolated: 2-3
        reserved: 0-1
      hugepages:
        defaultHugepagesSize: 1G
        pages:
          - count: 2
            node: 0
            size: 1G
      nodeSelector:
        node-role.kubernetes.io/performance: ''
      realTimeKernel:
        enabled: true
    참고

    예약 및 분리된 CPU를 구성하면 Pod의 인프라 컨테이너는 예약된 CPU를 사용하고 애플리케이션 컨테이너는 분리된 CPU를 사용합니다.

15.3.5. 워크로드 팁 이해

다음 표에서는 전력 소비와 실시간 설정이 대기 시간에 미치는 영향에 대해 설명합니다.

참고

다음 워크로드 힌트를 수동으로 구성할 수 있습니다. Performance Profile Creator를 사용하여 워크로드 힌트를 사용할 수도 있습니다. 성능 프로필에 대한 자세한 내용은 "성능 프로필 생성" 섹션을 참조하십시오. 워크로드 힌트가 수동으로 구성되고 realTime 워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true 입니다.

Performance Profile Creator 설정힌트환경설명

기본값

workloadHints:
highPowerConsumption: false
realTime: false

대기 시간 요구 사항이 없는 높은 처리량 클러스터

CPU 파티셔닝을 통해서만 달성된 성능.

low-latency

workloadHints:
highPowerConsumption: false
realTime: true

지역 데이터센터

전력 절감과 대기 시간이 짧은 경우 모두, 전원 관리, 대기 시간 및 처리량이 저하됩니다.

Ultra-low-latency

workloadHints:
highPowerConsumption: true
realTime: true

긴 엣지 클러스터, 대기 시간 중요한 워크로드

전력 소비 증가의 비용으로 절대 최소 대기 시간과 최대 결정성에 최적화되어 있습니다.

Pod별 전원 관리

workloadHints:
realTime: true
highPowerConsumption: false
perPodPowerManagement: true

심각 및 중요하지 않은 워크로드

Pod당 전원 관리를 허용합니다.

추가 리소스

  • PPC(Performance Profile Creator)를 사용하여 성능 프로필을 생성하는 방법에 대한 자세한 내용은 성능 프로필 생성을 참조하십시오.

15.3.6. 워크로드 힌트 수동 구성

절차

  1. "Works workload hints"의 표에 설명된 대로 환경의 하드웨어 및 토폴로지에 적합한 PerformanceProfile 을 생성합니다. 예상 워크로드와 일치하도록 프로필을 조정합니다. 이 예에서는 가능한 가장 짧은 대기 시간을 튜닝합니다.
  2. highPowerConsumptionrealTime 워크로드 힌트를 추가합니다. 둘 다 true 로 설정되어 있습니다.

        apiVersion: performance.openshift.io/v2
        kind: PerformanceProfile
        metadata:
          name: workload-hints
        spec:
          ...
          workloadHints:
            highPowerConsumption: true 1
            realTime: true 2
    1
    highPowerConsumptiontrue 인 경우 노드가 전력 소비 증가 시 매우 짧은 대기 시간으로 조정됩니다.
    2
    시스템 대기 시간에 영향을 줄 수 있는 일부 디버깅 및 모니터링 기능을 비활성화합니다.
참고

성능 프로파일에서 realTime 워크로드 힌트 플래그가 true 로 설정된 경우 고정 CPU가 있는 보장된 모든 Pod에 cpu-quota.crio.io: disable 주석을 추가합니다. 이 주석은 Pod 내에서 프로세스 성능이 저하되지 않도록 하는 데 필요합니다. realTime 워크로드 힌트가 명시적으로 설정되지 않은 경우 기본값은 true 입니다.

15.3.7. 인프라 및 애플리케이션 컨테이너의 CPU 제한

일반 하우스키핑 및 워크로드 작업은 대기 시간에 민감한 프로세스에 영향을 미칠 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하여 컨텍스트 스위치와 대기 시간이 급증할 수 있습니다. CPU를 분할하면 noisy 프로세스가 서로 분리되어 대기 시간에 민감한 프로세스를 방해할 수 없습니다. 다음 표에서는 Node Tuning Operator를 사용하여 노드를 조정한 후 CPU에서 프로세스를 실행하는 방법을 설명합니다.

표 15.1. 프로세스의 CPU 할당
프로세스 유형세부 정보

BurstableBestEffort Pod

대기 시간이 짧은 워크로드가 실행 중인 위치를 제외하고 모든 CPU에서 실행

인프라 Pod

대기 시간이 짧은 워크로드가 실행 중인 위치를 제외하고 모든 CPU에서 실행

인터럽트

예약된 CPU로 리디렉션(OpenShift Container Platform 4.7 이상에서 선택 사항)

커널 프로세스

예약된 CPU에 고정

대기 시간에 민감한 워크로드 Pod

분리된 풀에서 특정 전용 CPU 세트에 고정

OS 프로세스/systemd 서비스

예약된 CPU에 고정

모든 QoS 프로세스 유형, Burstable,BestEffort 또는 Guaranteed 의 Pod에 대해 노드에 있는 코어의 할당 가능 용량은 격리된 풀의 용량과 동일합니다. 예약된 풀의 용량은 클러스터 및 운영 체제 하우스키핑 작업에서 사용할 노드의 총 코어 용량에서 제거됩니다.

예시 1

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어를 할당하고 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 BestEffort 또는 Burstable Pod에 대해 QoS가 보장된 Pod 및 25개의 코어를 25개에 할당합니다. 이는 격리된 풀의 용량과 일치합니다.

예시 2

노드에는 100개의 코어 용량이 있습니다. 클러스터 관리자는 성능 프로필을 사용하여 분리된 풀에 50개의 코어를 할당하고 예약된 풀에 50개의 코어를 할당합니다. 클러스터 관리자는 QoS가 보장된 Pod에 50개의 코어를 할당하고 BestEffort 또는 Burstable Pod의 코어 1개를 할당합니다. 이는 하나의 코어로 격리된 풀의 용량을 초과합니다. CPU 용량이 부족하여 Pod 예약에 실패합니다.

사용할 정확한 파티션 패턴은 하드웨어, 워크로드 특성 및 예상되는 시스템 로드와 같은 여러 요인에 따라 달라집니다. 일부 샘플 사용 사례는 다음과 같습니다.

  • 대기 시간에 민감한 워크로드에서 NIC(네트워크 인터페이스 컨트롤러)와 같은 특정 하드웨어를 사용하는 경우 분리된 풀의 CPU가 이 하드웨어에 최대한 가깝게 있는지 확인합니다. 최소한 동일한 NUMA(Non-Uniform Memory Access) 노드에 워크로드를 배치해야 합니다.
  • 예약된 풀은 모든 인터럽트를 처리하는 데 사용됩니다. 시스템 네트워킹에 따른 경우 충분한 크기의 예약 풀을 할당하여 들어오는 모든 패킷 인터럽트를 처리합니다. 4.11 이상 버전에서 워크로드는 선택적으로 중요로 레이블을 지정할 수 있습니다.

예약 및 분리된 파티션에 사용할 특정 CPU에 대한 결정에는 자세한 분석과 측정이 필요합니다. 장치 및 메모리의 NUMA 선호도와 같은 요인은 역할을 합니다. 선택 사항은 워크로드 아키텍처 및 특정 사용 사례에 따라 달라집니다.

중요

예약 및 격리된 CPU 풀이 겹치지 않아야 하며 작업자 노드에서 사용 가능한 모든 코어에 걸쳐 있어야 합니다.

하우스키핑 작업 및 워크로드가 서로 간섭하지 않도록 성능 프로파일의 spec 섹션에 두 개의 CPU 그룹을 지정합니다.

  • isolated - 애플리케이션 컨테이너 워크로드의 CPU를 지정합니다. 이러한 CPU는 대기 시간이 가장 짧습니다. 이 그룹의 프로세스에는 중단이 발생하지 않으므로 예를 들어 프로세스가 훨씬 더 높은 DPDK 제로 패킷 손실 대역폭에 도달할 수 있습니다.
  • reserved - 클러스터 및 운영 체제 하우스키핑 작업의 CPU를 지정합니다. 예약 그룹의 스레드는 종종 사용 중입니다. 예약된 그룹에서 대기 시간에 민감한 애플리케이션을 실행하지 마십시오. 대기 시간에 민감한 애플리케이션은 격리된 그룹에서 실행됩니다.

절차

  1. 환경 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.
  2. 인프라 및 애플리케이션 컨테이너에 대해 reservedisolated하려는 CPU와 함께 예약 및 격리된 매개변수를 추가합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: infra-cpus
    spec:
      cpu:
        reserved: "0-4,9" 1
        isolated: "5-8" 2
      nodeSelector: 3
        node-role.kubernetes.io/worker: ""
    1
    클러스터 및 운영 체제 하우스키핑 작업을 수행하기 위해 인프라 컨테이너의 CPU를 지정합니다.
    2
    애플리케이션 컨테이너가 워크로드를 실행하는 CPU를 지정합니다.
    3
    선택 사항: 노드 선택기를 지정하여 특정 노드에 성능 프로파일을 적용합니다.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.