확장 및 성능

OpenShift Container Platform 4.10

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

Red Hat OpenShift Documentation Team

초록

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

4장. Node Tuning Operator 사용

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

4.1. Node Tuning Operator 정보

Node Tuning Operator는 TuneD 데몬을 오케스트레이션하여 노드 수준 튜닝을 관리하는 데 도움이 됩니다. 대부분의 고성능 애플리케이션에는 일정 수준의 커널 튜닝이 필요합니다. Node Tuning Operator는 노드 수준 sysctls 사용자에게 통합 관리 인터페이스를 제공하며 사용자의 필요에 따라 지정되는 사용자 정의 튜닝을 추가할 수 있는 유연성을 제공합니다.

Operator는 OpenShift Container Platform의 컨테이너화된 TuneD 데몬을 Kubernetes 데몬 세트로 관리합니다. 클러스터에서 실행되는 모든 컨테이너화된 TuneD 데몬에 사용자 정의 튜닝 사양이 데몬이 이해할 수 있는 형식으로 전달되도록 합니다. 데몬은 클러스터의 모든 노드에서 노드당 하나씩 실행됩니다.

컨테이너화된 TuneD 데몬을 통해 적용되는 노드 수준 설정은 프로필 변경을 트리거하는 이벤트 시 또는 컨테이너화된 TuneD 데몬이 종료 신호를 수신하고 처리하여 정상적으로 종료될 때 롤백됩니다.

버전 4.1 이상에서는 Node Tuning Operator가 표준 OpenShift Container Platform 설치에 포함되어 있습니다.

4.2. Node Tuning Operator 사양 예에 액세스

이 프로세스를 사용하여 Node Tuning Operator 사양 예에 액세스하십시오.

프로세스

  1. 다음을 실행합니다.

    $ oc get Tuned/default -o yaml -n openshift-cluster-node-tuning-operator

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

주의

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

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

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

apiVersion: tuned.openshift.io/v1
kind: Tuned
metadata:
  name: default
  namespace: openshift-cluster-node-tuning-operator
spec:
  recommend:
  - profile: "openshift-control-plane"
    priority: 30
    match:
    - label: "node-role.kubernetes.io/master"
    - label: "node-role.kubernetes.io/infra"

  - profile: "openshift-node"
    priority: 40

OpenShift Container Platform 4.9부터 모든 OpenShift TuneD 프로필이 TuneD 패키지와 함께 제공됩니다. oc exec 명령을 사용하여 이러한 프로필의 내용을 볼 수 있습니다.

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/openshift{,-control-plane,-node} -name tuned.conf -exec grep -H ^ {} \;

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

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

$ oc get profile -n openshift-cluster-node-tuning-operator

출력 예

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

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

4.5. 사용자 정의 튜닝 사양

Operator의 CR(사용자 정의 리소스)에는 두 가지 주요 섹션이 있습니다. 첫 번째 섹션인 profile:은 TuneD 프로필 및 해당 이름의 목록입니다. 두 번째인 recommend:은 프로필 선택 논리를 정의합니다.

여러 사용자 정의 튜닝 사양은 Operator의 네임스페이스에 여러 CR로 존재할 수 있습니다. 새로운 CR의 존재 또는 오래된 CR의 삭제는 Operator에서 탐지됩니다. 기존의 모든 사용자 정의 튜닝 사양이 병합되고 컨테이너화된 TuneD 데몬의 해당 오브젝트가 업데이트됩니다.

관리 상태

Operator 관리 상태는 기본 Tuned CR을 조정하여 설정됩니다. 기본적으로 Operator는 Managed 상태이며 기본 Tuned CR에는 spec.managementState 필드가 없습니다. Operator 관리 상태에 유효한 값은 다음과 같습니다.

  • Managed: 구성 리소스가 업데이트되면 Operator가 해당 피연산자를 업데이트합니다.
  • Unmanaged: Operator가 구성 리소스에 대한 변경을 무시합니다.
  • Removed: Operator가 프로비저닝한 해당 피연산자 및 리소스를 Operator가 제거합니다.

프로필 데이터

profile: 섹션에는 TuneD 프로필 및 해당 이름이 나열됩니다.

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

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

# ...

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

    # tuned_profile_n profile settings

권장 프로필

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

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

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

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

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

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

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

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

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

중요

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

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

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

위의 CR은 컨테이너화된 TuneD 데몬의 프로필 우선 순위에 따라 recommended.conf 파일로 변환됩니다. 우선 순위가 가장 높은 프로필(10)이 openshift-control-plane-es이므로 이 프로필을 첫 번째로 고려합니다. 지정된 노드에서 실행되는 컨테이너화된 TuneD 데몬은 tuned.openshift.io/elasticsearch 라벨이 설정된 동일한 노드에서 실행되는 Pod가 있는지 확인합니다. 없는 경우 전체 <match> 섹션이 false로 평가됩니다. 라벨이 있는 Pod가 있는 경우 <match> 섹션을 true로 평가하려면 노드 라벨도 node-role.kubernetes.io/master 또는 node-role.kubernetes.io/infra여야 합니다.

우선 순위가 10인 프로필의 라벨이 일치하면 openshift-control-plane-es 프로필이 적용되고 다른 프로필은 고려되지 않습니다. 노드/Pod 라벨 조합이 일치하지 않으면 두 번째로 높은 우선 순위 프로필(openshift-control-plane)이 고려됩니다. 컨테이너화된 TuneD Pod가 node-role.kubernetes.io/master 또는 node-role.kubernetes.io/infra. 라벨이 있는 노드에서 실행되는 경우 이 프로필이 적용됩니다.

마지막으로, openshift-node 프로필은 우선 순위가 가장 낮은 30입니다. 이 프로필에는 <match> 섹션이 없으므로 항상 일치합니다. 지정된 노드에서 우선 순위가 더 높은 다른 프로필이 일치하지 않는 경우 openshift-node 프로필을 설정하는 데 catch-all 프로필 역할을 합니다.

결정 워크플로

예: 머신 구성 풀 기반 일치

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

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

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

4.6. 사용자 정의 튜닝 예

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

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

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

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

중요

사용자 정의 프로필 작성자는 기본 TuneD CR에 제공된 기본 Tuned 데몬 프로필을 포함하는 것이 좋습니다. 위의 예에서는 기본 openshift-control-plane 프로필을 사용하여 작업을 수행합니다.

내장된 TuneD 프로필 사용

NTO 관리 데몬 세트가 성공적으로 롤아웃되면 TuneD 피연산자는 모두 동일한 버전의 TuneD 데몬을 관리합니다. 데몬에서 지원하는 기본 제공 TuneD 프로필을 나열하려면 다음 방식으로 TuneD Pod를 쿼리합니다.

$ oc exec $tuned_pod -n openshift-cluster-node-tuning-operator -- find /usr/lib/tuned/ -name tuned.conf -printf '%h\n' | sed 's|^.*/||'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.1. CPU 관리자 설정

프로세스

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

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

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

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

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

    # oc create -f cpumanager-kubeletconfig.yaml

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

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

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

    출력 예

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

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

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

    출력 예

    cpuManagerPolicy: static        1
    cpuManagerReconcilePeriod: 5s   2

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

    # cat cpumanager-pod.yaml

    출력 예

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

  9. Pod를 생성합니다.

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

    # oc describe pod cpumanager

    출력 예

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

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

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

    QoS(Quality of Service) 계층 Guaranteed의 Pod는 kubepods.slice에 있습니다. 다른 QoS 계층의 Pod는 kubepods의 하위 cgroups에 있습니다.

    # cd /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-pod69c01f8e_6b74_11e9_ac0f_0a2b62178a22.slice/crio-b5437308f1ad1a7db0574c542bdf08563b865c0345c86e9585f8c0b0a655612c.scope
    # for i in `ls cpuset.cpus tasks` ; do echo -n "$i "; cat $i ; done

    출력 예

    cpuset.cpus 1
    tasks 32706

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

    # grep ^Cpus_allowed_list /proc/32706/status

    출력 예

     Cpus_allowed_list:    1

  13. Guaranteed Pod용으로 할당된 코어에서는 시스템의 다른 Pod(이 경우 burstable QoS 계층의 Pod)를 실행할 수 없는지 검증합니다.

    # cat /sys/fs/cgroup/cpuset/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podc494a073_6b77_11e9_98c0_06bba5c387ea.slice/crio-c56982f57b75a2420947f0afc6cafe7534c5734efc34157525fa9abbf99e3849.scope/cpuset.cpus
    0
    # oc describe node perf-node.example.com

    출력 예

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

    이 VM에는 두 개의 CPU 코어가 있습니다. system-reserved 설정은 500밀리코어로 설정되었습니다. 즉, Node Allocatable 양이 되는 노드의 전체 용량에서 한 코어의 절반이 감산되었습니다. Allocatable CPU는 1500 밀리코어임을 확인할 수 있습니다. 즉, Pod마다 하나의 전체 코어를 사용하므로 CPU 관리자 Pod 중 하나를 실행할 수 있습니다. 전체 코어는 1000밀리코어에 해당합니다. 두 번째 Pod를 예약하려고 하면 시스템에서 해당 Pod를 수락하지만 Pod가 예약되지 않습니다.

    NAME                    READY   STATUS    RESTARTS   AGE
    cpumanager-6cqz7        1/1     Running   0          33m
    cpumanager-7qc2t        0/1     Pending   0          11s

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

5.3. 토폴로지 관리자 설정

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

전제 조건

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

절차

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

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

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

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

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

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

spec:
  containers:
  - name: nginx
    image: nginx

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

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

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

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

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

토폴로지 관리자는 이러한 Pod를 고려합니다. 토폴로지 관리자는 포드에 대한 토폴로지 힌트 힌트를 얻으려면 CPU 관리자 및 장치 관리자인 힌트 공급자를 참조합니다.

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

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

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

중요

NUMA 인식 예약은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

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

6.1. NUMA 인식 스케줄링 정보

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

NUMA 아키텍처를 사용하면 여러 메모리 컨트롤러가 있는 CPU가 메모리가 있는 위치에 관계없이 CPU 복잡성에서 사용 가능한 메모리를 사용할 수 있습니다. 이를 통해 성능을 저하시킬 수 있는 유연성이 향상됩니다. NUMA 영역 외부에 있는 메모리를 사용하여 워크로드를 처리하는 CPU는 단일 NUMA 영역에서 처리된 워크로드보다 속도가 느립니다. 또한 I/O 제한 워크로드의 경우 원격 NUMA 영역의 네트워크 인터페이스가 애플리케이션에 도달할 수 있는 속도가 느려집니다. 통신 워크로드와 같은 고성능 워크로드는 이러한 조건에서 사양으로 작동할 수 없습니다. NUMA 인식 예약은 동일한 NUMA 영역에서 요청된 클러스터 컴퓨팅 리소스(CPU, 메모리, 장치)를 정렬하여 대기 시간에 민감한 또는 고성능 워크로드를 효율적으로 처리합니다. NUMA 인식 스케줄링은 리소스 효율성을 높이기 위해 컴퓨팅 노드당 Pod 밀도도 향상시킵니다.

기본 OpenShift Container Platform Pod 스케줄러 스케줄링 논리는 개별 NUMA 영역이 아닌 전체 컴퓨팅 노드의 사용 가능한 리소스를 고려합니다. kubelet 토폴로지 관리자에서 가장 제한적인 리소스 정렬이 요청되면 노드에 Pod를 허용할 때 오류 상태가 발생할 수 있습니다. 반대로, 가장 제한적인 리소스 정렬이 요청되지 않으면 적절한 리소스 정렬 없이 노드에 Pod가 허용되어 성능이 저하되거나 예측되지 않을 수 있습니다. 예를 들어, 토폴로지 유사성 오류 상태를 사용한 runaway Pod 생성은 Pod 스케줄러가 Pod의 요청된 리소스를 사용할 수 있는지 여부를 인식하지 못하여 보장된 Pod 워크로드에 대해 차선적 스케줄링 결정을 내릴 때 발생할 수 있습니다. 불일치 결정에 따라 무기한 Pod 시작 지연이 발생할 수 있습니다. 또한 클러스터 상태 및 리소스 할당에 따라 잘못된 Pod 예약 결정에 따라 시작 시도가 실패하여 클러스터에 추가 로드가 발생할 수 있습니다.

NUMA 리소스 Operator는 사용자 정의 NUMA 리소스 보조 스케줄러 및 기타 리소스를 배포하여 기본 OpenShift Container Platform Pod 스케줄러의 단점에 대해 완화합니다. 다음 다이어그램에서는 NUMA 인식 Pod 스케줄링에 대한 상위 수준 개요를 제공합니다.

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

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

추가 리소스

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

6.2. NUMA Resources Operator 설치

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

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

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

사전 요구 사항

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

프로세스

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

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

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

      $ oc create -f nro-namespace.yaml
  2. NUMA 리소스 Operator의 Operator 그룹을 생성합니다.

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

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

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

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: numaresources-operator
        namespace: openshift-numaresources
      spec:
        channel: "{product-version}"
        name: numaresources-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. 다음 명령을 실행하여 Subscription CR을 생성합니다.

      $ oc create -f nro-sub.yaml

검증

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

    $ oc get csv -n openshift-numaresources

    출력 예

    NAME                            DISPLAY                      VERSION   REPLACES   PHASE
    numaresources-operator.v4.10.0  NUMA Resources Operator      4.10.0               Succeeded

6.2.2. 웹 콘솔을 사용하여 NUMA 리소스 Operator 설치

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

프로세스

  1. OpenShift Container Platform 웹 콘솔을 사용하여 NUMA 리소스 Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 NUMA Resources Operator 를 선택한 다음 설치를 클릭합니다.
  2. 선택 사항: NUMA Resources Operator가 설치되었는지 확인합니다.

    1. Operator설치된 Operator 페이지로 전환합니다.
    2. NUMA 리소스 Operator기본 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

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

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

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

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

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

사전 요구 사항

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

프로세스

  1. 작업자 노드에 대한 사용자 정의 kubelet 구성을 활성화하는 MachineConfigPool 사용자 정의 리소스를 생성합니다.

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

      apiVersion: machineconfiguration.openshift.io/v1
      kind: MachineConfigPool
      metadata:
        labels:
          cnf-worker-tuning: enabled
          machineconfiguration.openshift.io/mco-built-in: ""
          pools.operator.machineconfiguration.openshift.io/worker: ""
        name: worker
      spec:
        machineConfigSelector:
          matchLabels:
            machineconfiguration.openshift.io/role: worker
        nodeSelector:
          matchLabels:
            node-role.kubernetes.io/worker: ""
    2. 다음 명령을 실행하여 MachineConfigPool CR을 생성합니다.

      $ oc create -f nro-machineconfig.yaml
  2. NUMAResourcesOperator 사용자 정의 리소스를 만듭니다.

    1. 다음 YAML을 nrop.yaml 파일에 저장합니다.

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesOperator
      metadata:
        name: numaresourcesoperator
      spec:
        nodeGroups:
        - machineConfigPoolSelector:
            matchLabels:
              pools.operator.machineconfiguration.openshift.io/worker: "" 1
      1
      관련 MachineConfigPool CR의 작업자 노드에 적용되는 레이블과 일치해야 합니다.
    2. 다음 명령을 실행하여 NUMAResourcesOperator CR을 만듭니다.

      $ oc create -f nrop.yaml

검증

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

$ oc get numaresourcesoperators.nodetopology.openshift.io

출력 예

NAME                    AGE
numaresourcesoperator   10m

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

NUMA Resources Operator를 설치한 후 다음을 수행하여 NUMA 인식 보조 Pod 스케줄러를 배포합니다.

  • 필수 머신 프로필에 대한 Pod 승인 정책 구성
  • 필요한 머신 구성 풀을 생성합니다.
  • NUMA 인식 보조 스케줄러 배포

사전 요구 사항

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

프로세스

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

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

      apiVersion: machineconfiguration.openshift.io/v1
      kind: KubeletConfig
      metadata:
        name: cnf-worker-tuning
      spec:
        machineConfigPoolSelector:
          matchLabels:
            cnf-worker-tuning: enabled
        kubeletConfig:
          cpuManagerPolicy: "static" 1
          cpuManagerReconcilePeriod: "5s"
          reservedSystemCPUs: "0,1"
          memoryManagerPolicy: "Static" 2
          evictionHard:
            memory.available: "100Mi"
          kubeReserved:
            memory: "512Mi"
          reservedMemory:
            - numaNode: 0
              limits:
                memory: "1124Mi"
          systemReserved:
            memory: "512Mi"
          topologyManagerPolicy: "single-numa-node" 3
          topologyManagerScope: "pod"
      1
      cpuManagerPolicy 의 경우static 은 소문자 s 를 사용해야 합니다.
      2
      memoryManagerPolicy 의 경우정적 에서는 대문자 S 를 사용해야 합니다.
      3
      topologyManagerPolicysingle-numa-node 로 설정해야 합니다.
    2. 다음 명령을 실행하여 KubeletConfig CR(사용자 정의 리소스)을 생성합니다.

      $ oc create -f nro-kubeletconfig.yaml
  2. NUMA 인식 사용자 정의 Pod 스케줄러를 배포하는 NUMAResourcesScheduler 사용자 정의 리소스를 생성합니다.

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

      apiVersion: nodetopology.openshift.io/v1alpha1
      kind: NUMAResourcesScheduler
      metadata:
        name: numaresourcesscheduler
      spec:
        imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.10"
    2. 다음 명령을 실행하여 NUMAResourcesScheduler CR을 생성합니다.

      $ oc create -f nro-scheduler.yaml

검증

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

$ oc get all -n openshift-numaresources

출력 예

NAME                                                    READY   STATUS    RESTARTS   AGE
pod/numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          13m
pod/numaresourcesoperator-worker-dvj4n                  2/2     Running   0          16m
pod/numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16m
pod/secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          16m
NAME                                          DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR                     AGE
daemonset.apps/numaresourcesoperator-worker   2         2         2       2            2           node-role.kubernetes.io/worker=   16m
NAME                                               READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/numaresources-controller-manager   1/1     1            1           13m
deployment.apps/secondary-scheduler                1/1     1            1           16m
NAME                                                          DESIRED   CURRENT   READY   AGE
replicaset.apps/numaresources-controller-manager-7575848485   1         1         1       13m
replicaset.apps/secondary-scheduler-56994cf6cf                1         1         1       16m

6.5. NUMA 인식 스케줄러로 워크로드 예약

워크로드를 처리하는 데 필요한 최소 리소스를 지정하는 Deployment CR을 사용하여 NUMA 인식 스케줄러로 워크로드를 예약할 수 있습니다.

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

사전 요구 사항

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

프로세스

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

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

    출력 예

    topo-aware-scheduler

  2. 다음과 같이 topo-aware-scheduler 라는 스케줄러를 사용하는 배포 CR을 생성합니다.

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

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

      $ oc create -f nro-deployment.yaml

검증

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

    $ oc get pods -n openshift-numaresources

    출력 예

    NAME                                                READY   STATUS    RESTARTS   AGE
    numa-deployment-1-56954b7b46-pfgw8                  2/2     Running   0          129m
    numaresources-controller-manager-7575848485-bns4s   1/1     Running   0          15h
    numaresourcesoperator-worker-dvj4n                  2/2     Running   0          18h
    numaresourcesoperator-worker-lcg4t                  2/2     Running   0          16h
    secondary-scheduler-56994cf6cf-7qf4q                1/1     Running   0          18h

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

    $ oc describe pod numa-deployment-1-56954b7b46-pfgw8 -n openshift-numaresources

    출력 예

    Events:
      Type    Reason          Age   From                  Message
      ----    ------          ----  ----                  -------
      Normal  Scheduled       130m  topo-aware-scheduler  Successfully assigned openshift-numaresources/numa-deployment-1-56954b7b46-pfgw8 to compute-0.example.com

    참고

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

  3. 예상 할당된 리소스가 노드에 나열되어 있는지 확인합니다. 다음 명령을 실행합니다.

    $ oc describe noderesourcetopologies.topology.node.k8s.io

    출력 예

    ...
    
    Zones:
      Costs:
        Name:   node-0
        Value:  10
        Name:   node-1
        Value:  21
      Name:     node-0
      Resources:
        Allocatable:  39
        Available:    21 1
        Capacity:     40
        Name:         cpu
        Allocatable:  6442450944
        Available:    6442450944
        Capacity:     6442450944
        Name:         hugepages-1Gi
        Allocatable:  134217728
        Available:    134217728
        Capacity:     134217728
        Name:         hugepages-2Mi
        Allocatable:  262415904768
        Available:    262206189568
        Capacity:     270146007040
        Name:         memory
      Type:           Node

    1
    보장된 Pod에 할당된 리소스로 인해 사용 가능한 용량이 줄어듭니다.

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

  4. Best-effort 또는 Burstable 서비스 품질(qosClass)이 있는 Pod의 리소스 할당은 node resourcetopology.topology.node.k8s.io의 NUMA 노드 리소스에 반영되지 않습니다. Pod의 소비된 리소스가 노드 리소스 계산에 반영되지 않은 경우 다음 명령을 실행하여 Pod에 GuaranteedqosClass 가 있는지 확인합니다.

    $ oc get pod <pod_name> -n <pod_namespace> -o jsonpath="{ .status.qosClass }"

    출력 예

    Guaranteed

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

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

사전 요구 사항

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

프로세스

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

    $ oc get crd | grep noderesourcetopologies

    출력 예

    NAME                                                              CREATED AT
    noderesourcetopologies.topology.node.k8s.io                       2022-01-18T08:28:06Z

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

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

    출력 예

    topo-aware-scheduler

  3. NUMA 인식 스케이블 노드에 noderesourcetopECDHE CR이 적용되었는지 확인합니다. 다음 명령을 실행합니다.

    $ oc get noderesourcetopologies.topology.node.k8s.io

    출력 예

    NAME                    AGE
    compute-0.example.com   17h
    compute-1.example.com   17h

    참고

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

  4. 다음 명령을 실행하여 스케줄링 가능한 모든 노드에 대해 NUMA 영역 세분성을 확인합니다.

    $ oc get noderesourcetopologies.topology.node.k8s.io -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: topology.node.k8s.io/v1alpha1
      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/v1alpha1
      kind: NodeResourceTopology
      metadata:
        annotations:
          k8stopoawareschedwg/rte-update: periodic
        creationTimestamp: "2022-06-16T08:55:37Z"
        generation: 62061
        name: worker-1
        resourceVersion: "8450129"
        uid: e8659390-6f8d-4e67-9a51-1ea34bba1cc3
      topologyPolicies:
      - SingleNUMANodeContainerLevel
      zones: 1
      - costs:
        - name: node-0
          value: 10
        - name: node-1
          value: 21
        name: node-0
        resources: 2
        - allocatable: "38"
          available: "38"
          capacity: "40"
          name: cpu
        - allocatable: "6442450944"
          available: "6442450944"
          capacity: "6442450944"
          name: hugepages-1Gi
        - allocatable: "134217728"
          available: "134217728"
          capacity: "134217728"
          name: hugepages-2Mi
        - allocatable: "262391033856"
          available: "262391033856"
          capacity: "270146301952"
          name: memory
        type: Node
      - costs:
        - name: node-0
          value: 21
        - name: node-1
          value: 10
        name: node-1
        resources:
        - allocatable: "40"
          available: "40"
          capacity: "40"
          name: cpu
        - allocatable: "1073741824"
          available: "1073741824"
          capacity: "1073741824"
          name: hugepages-1Gi
        - allocatable: "268435456"
          available: "268435456"
          capacity: "268435456"
          name: hugepages-2Mi
        - allocatable: "269192085504"
          available: "269192085504"
          capacity: "270534262784"
          name: memory
        type: Node
    kind: List
    metadata:
      resourceVersion: ""
      selfLink: ""

    1
    zones 아래의 각 스탠자는 단일 NUMA 영역의 리소스를 설명합니다.
    2
    resources 는 NUMA 영역 리소스의 현재 상태를 설명합니다. items.zones.resources.available 아래에 나열된 리소스가 보장된 각 Pod에 할당된 전용 NUMA 영역 리소스에 해당하는지 확인합니다.

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

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

참고

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

사전 요구 사항

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

프로세스

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

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

      $ oc get NUMAResourcesScheduler

      출력 예

      NAME                     AGE
      numaresourcesscheduler   90m

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

      $ oc delete NUMAResourcesScheduler numaresourcesscheduler

      출력 예

      numaresourcesscheduler.nodetopology.openshift.io "numaresourcesscheduler" deleted

  2. 다음 YAML을 nro-scheduler-debug.yaml 파일에 저장합니다. 이 예제에서는 로그 수준을 Debug 로 변경합니다.

    apiVersion: nodetopology.openshift.io/v1alpha1
    kind: NUMAResourcesScheduler
    metadata:
      name: numaresourcesscheduler
    spec:
      imageSpec: "registry.redhat.io/openshift4/noderesourcetopology-scheduler-container-rhel8:v4.10"
      logLevel: Debug
  3. 다음 명령을 실행하여 업데이트된 Debug 로깅 NUMAResourcesScheduler 리소스를 만듭니다.

    $ oc create -f nro-scheduler-debug.yaml

    출력 예

    numaresourcesscheduler.nodetopology.openshift.io/numaresourcesscheduler created

검증 단계

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

    1. 다음 명령을 실행하여 CRD가 올바르게 생성되었는지 확인합니다.

      $ oc get crd | grep numaresourcesschedulers

      출력 예

      NAME                                                              CREATED AT
      numaresourcesschedulers.nodetopology.openshift.io                 2022-02-25T11:57:03Z

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

      $ oc get numaresourcesschedulers.nodetopology.openshift.io

      출력 예

      NAME                     AGE
      numaresourcesscheduler   3h26m

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

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

      $ oc get pods -n openshift-numaresources

      출력 예

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

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

      $ oc logs secondary-scheduler-7976c4d466-qm4sc -n openshift-numaresources

      출력 예

      ...
      I0223 11:04:55.614788       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.Namespace total 11 items received
      I0223 11:04:56.609114       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.ReplicationController total 10 items received
      I0223 11:05:22.626818       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.StorageClass total 7 items received
      I0223 11:05:31.610356       1 reflector.go:535] k8s.io/client-go/informers/factory.go:134: Watch close - *v1.PodDisruptionBudget total 7 items received
      I0223 11:05:31.713032       1 eventhandlers.go:186] "Add event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"
      I0223 11:05:53.461016       1 eventhandlers.go:244] "Delete event for scheduled pod" pod="openshift-marketplace/certified-operators-thtvq"

6.6.2. 리소스 토폴로지 내보내기 문제 해결

해당 resource-topology-exporter 로그를 검사하여 예기치 않은 결과가 발생하는 노드 리소스 토폴로지의 문제를 해결합니다.

참고

클러스터의 NUMA 리소스 토폴로지 내보내기 인스턴스의 이름이 참조하는 노드의 이름을 지정하는 것이 좋습니다. 예를 들어 이름 worker가 있는 작업자 노드에는 worker 라는 해당 noderesourcetopECDHE 오브젝트 가 있어야 합니다.

사전 요구 사항

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

프로세스

  1. NUMA Resources Operator가 관리하는 daemonsets를 가져옵니다. 각 데몬 세트에는 NUMAResourcesOperator CR에 해당 nodeGroup 이 있습니다. 다음 명령을 실행합니다.

    $ oc get numaresourcesoperators.nodetopology.openshift.io numaresourcesoperator -o jsonpath="{.status.daemonsets[0]}"

    출력 예

    {"name":"numaresourcesoperator-worker","namespace":"openshift-numaresources"}

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

    $ oc get ds -n openshift-numaresources numaresourcesoperator-worker -o jsonpath="{.spec.selector.matchLabels}"

    출력 예

    {"name":"resource-topology"}

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

    $ oc get pods -n openshift-numaresources -l name=resource-topology -o wide

    출력 예

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

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

    $ oc logs -n openshift-numaresources -c resource-topology-exporter numaresourcesoperator-worker-pb75c

    출력 예

    I0221 13:38:18.334140       1 main.go:206] using sysinfo:
    reservedCpus: 0,1
    reservedMemory:
      "0": 1178599424
    I0221 13:38:18.334370       1 main.go:67] === System information ===
    I0221 13:38:18.334381       1 sysinfo.go:231] cpus: reserved "0-1"
    I0221 13:38:18.334493       1 sysinfo.go:237] cpus: online "0-103"
    I0221 13:38:18.546750       1 main.go:72]
    cpus: allocatable "2-103"
    hugepages-1Gi:
      numa cell 0 -> 6
      numa cell 1 -> 1
    hugepages-2Mi:
      numa cell 0 -> 64
      numa cell 1 -> 128
    memory:
      numa cell 0 -> 45758Mi
      numa cell 1 -> 48372Mi

6.6.3. 누락된 리소스 토폴로지 내보내기 구성 맵 수정

클러스터 설정이 잘못 구성된 클러스터에 NUMA Resources Operator를 설치하는 경우 일부 상황에서 Operator가 활성으로 표시되지만 RTE(리소스 토폴로지 내보내기er) 데몬 세트 Pod의 로그에 RTE의 구성이 누락된 것으로 표시됩니다.

Info: couldn't find configuration in "/etc/resource-topology-exporter/config.yaml"

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

$ oc get configmap

출력 예

NAME                           DATA   AGE
0e2a6bd3.openshift-kni.io      0      6d21h
kube-root-ca.crt               1      6d21h
openshift-service-ca.crt       1      6d21h
topo-aware-scheduler-config    1      6d18h

올바르게 구성된 클러스터에서 oc get configmapnumaresourcesoperator-worker configmap CR도 반환합니다.

사전 요구 사항

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

프로세스

  1. 다음 명령을 사용하여 MachineConfigPool (mcp) 작업자 CR의 kubeletconfigmetadata.labels 에서 spec.machineConfigPoolSelector.matchLabels 의 값을 비교합니다.

    1. 다음 명령을 실행하여 kubeletconfig 라벨을 확인합니다.

      $ oc get kubeletconfig -o yaml

      출력 예

      machineConfigPoolSelector:
        matchLabels:
          cnf-worker-tuning: enabled

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

      $ oc get mcp worker -o yaml

      출력 예

      labels:
        machineconfiguration.openshift.io/mco-built-in: ""
        pools.operator.machineconfiguration.openshift.io/worker: ""

      cnf-worker-tuning: enabled 레이블은 MachineConfigPool 오브젝트에 존재하지 않습니다.

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

    $ oc edit mcp worker -o yaml

    출력 예

    labels:
      machineconfiguration.openshift.io/mco-built-in: ""
      pools.operator.machineconfiguration.openshift.io/worker: ""
      cnf-worker-tuning: enabled

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

검증

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

    $ oc get configmap

    출력 예

    NAME                           DATA   AGE
    0e2a6bd3.openshift-kni.io      0      6d21h
    kube-root-ca.crt               1      6d21h
    numaresourcesoperator-worker   1      5m
    openshift-service-ca.crt       1      6d21h
    topo-aware-scheduler-config    1      6d18h

7장. Cluster Monitoring Operator 스케일링

OpenShift Container Platform에서는 Cluster Monitoring Operator가 수집하여 Prometheus 기반 모니터링 스택에 저장하는 지표를 공개합니다. 관리자는 시스템 리소스, 컨테이너 및 구성 요소 지표를 하나의 대시보드 인터페이스인 Grafana에서 볼 수 있습니다.

7.1. Prometheus 데이터베이스 스토리지 요구사항

Red Hat은 여러 스케일링 크기에 대해 다양한 테스트를 수행했습니다.

참고

아래 Prometheus 스토리지 요구 사항은 규정되어 있지 않습니다. 워크로드 활동 및 리소스 사용량에 따라 클러스터에서 리소스 사용량이 높아질 수 있습니다.

표 7.1. 클러스터의 노드/Pod 수에 따른 Prometheus 데이터베이스 스토리지 요구사항

노드 수Pod 수Prometheus 스토리지 증가(1일당)Prometheus 스토리지 증가(15일당)RAM 공간(스케일링 크기당)네트워크(tsdb 청크당)

50

1800

6.3GB

94GB

6GB

16MB

100

3600

13GB

195GB

10GB

26MB

150

5400

19GB

283GB

12GB

36MB

200

7200

25GB

375GB

14GB

46MB

스토리지 요구사항이 계산된 값을 초과하지 않도록 예상 크기의 약 20%가 오버헤드로 추가되었습니다.

위의 계산은 기본 OpenShift Container Platform Cluster Monitoring Operator용입니다.

참고

CPU 사용률은 약간의 영향을 미칩니다. 50개 노드 및 1,800개 Pod당 비율이 약 40개 중 1개 코어입니다.

OpenShift Container Platform 권장 사항

  • 인프라 노드를 3개 이상 사용하십시오.
  • NVMe(Non-Volatile Memory Express) 드라이브를 사용하는 경우 openshift-container-storage 노드를 3개 이상 사용하십시오.

7.2. 클러스터 모니터링 구성

클러스터 모니터링 스택에서 Prometheus 구성 요소의 스토리지 용량을 늘릴 수 있습니다.

프로세스

Prometheus의 스토리지 용량을 늘리려면 다음을 수행합니다.

  1. YAML 구성 파일 cluster-monitoring-config.yaml 을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    data:
      config.yaml: |
        prometheusK8s:
          retention: {{PROMETHEUS_RETENTION_PERIOD}} 1
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          volumeClaimTemplate:
            spec:
              storageClassName: {{STORAGE_CLASS}} 2
              resources:
                requests:
                  storage: {{PROMETHEUS_STORAGE_SIZE}} 3
        alertmanagerMain:
          nodeSelector:
            node-role.kubernetes.io/infra: ""
          volumeClaimTemplate:
            spec:
              storageClassName: {{STORAGE_CLASS}} 4
              resources:
                requests:
                  storage: {{ALERTMANAGER_STORAGE_SIZE}} 5
    metadata:
      name: cluster-monitoring-config
      namespace: openshift-monitoring
    1
    일반적인 값은 PROMETHEUS_RETENTION_PERIOD=15d입니다. 단위는 s, m, h, d 접미사 중 하나를 사용하는 시간으로 측정됩니다.
    2 4
    클러스터의 스토리지 클래스입니다.
    3
    일반적인 값은 PROMETHEUS_STORAGE_SIZE=2000Gi입니다. 스토리지 값은 일반 정수일 수도 있고 E, P, T, G, M, K 접미사 중 하나를 사용하는 고정 소수점 정수일 수도 있습니다. Ei, Pi, Ti, Gi, Mi, Ki 같은 2의 거듭제곱을 사용할 수도 있습니다.
    5
    일반적인 값은 ALERTMANAGER_STORAGE_SIZE=20Gi입니다. 스토리지 값은 일반 정수일 수도 있고 E, P, T, G, M, K 접미사 중 하나를 사용하는 고정 소수점 정수일 수도 있습니다. Ei, Pi, Ti, Gi, Mi, Ki 같은 2의 거듭제곱을 사용할 수도 있습니다.
  2. 보존 기간, 스토리지 클래스 및 스토리지 크기에 대한 값을 추가합니다.
  3. 파일을 저장합니다.
  4. 다음을 실행하여 변경사항을 적용합니다.

    $ oc create -f cluster-monitoring-config.yaml

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

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

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

중요

이러한 지침은 OVN(Open Virtual Network)이 아닌 SDN(소프트웨어 정의 네트워킹)을 사용하는 OpenShift Container Platform에 적용됩니다.

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

주의

Pod 시작 및 중지 Pod와 같이 빠른 변경이 발생하는 클러스터는 문서화된 것보다 실제 가능한 최대 크기를 줄일 수 있습니다.

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

OpenShift Container Platform 3.x에 대해 테스트된 클라우드 플랫폼은 RHOSP(Red Hat OpenStack Platform), Amazon Web Services 및 Microsoft Azure입니다. OpenShift Container Platform 4.x에 대해 테스트된 클라우드 플랫폼은 Amazon Web Services, Microsoft Azure 및 Google Cloud Platform입니다.

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

노드 수

2,000

2,000 [1]

Pod [2]

150,000

150,000

노드당 Pod 수

250

500 [3]

코어당 Pod 수

기본값 없음

기본값 없음

네임스페이스 수 [4]

10,000

10,000

빌드 수

10,000(기본 Pod RAM 512Mi) - Pipeline 전략

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

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

25,000

25,000

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

라우터당 2,000개

라우터당 2,000개

보안 수

80,000

80,000

구성 맵 수

90,000

90,000

서비스 수 [7]

10,000

10,000

네임스페이스당 서비스 수

5,000

5,000

서비스당 백엔드 수

5,000

5,000

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

2,000

2,000

빌드 구성 수

12,000

12,000

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

기본값 없음

512 [7]

  1. 노드 규모에 OpenShift Container Platform의 컨트롤 플레인 구성 요소를 과부하시키기 위해 Pod 일시 중지가 배포되었습니다.
  2. 여기에 표시된 Pod 수는 테스트 Pod 수입니다. 실제 Pod 수는 애플리케이션 메모리, CPU 및 스토리지 요구사항에 따라 달라집니다.
  3. 이 테스트는 작업자 노드가 100개이며 작업자 노드당 Pod가 500개인 클러스터에서 수행되었습니다. 기본 maxPods는 계속 250입니다. maxPods가 500이 되도록 하려면 사용자 정의 kubelet 구성을 사용하여 500으로 설정된 maxPods가 포함된 클러스터를 생성해야 합니다. 500개의 사용자 Pod가 필요한 경우 노드에서 이미 실행되고 있는 시스템 Pod가 10~15개가 있으므로 hostPrefix 22가 필요합니다. 연결된 PVC(영구 볼륨 클레임)가 있는 Pod의 최대 수는 PVC가 할당된 스토리지 백엔드에 따라 달라집니다. 이 테스트에서는 OpenShift Data Foundation v4(OCS v4)만 이 문서에서 설명하는 노드당 Pod 수를 충족할 수 있었습니다.
  4. 활성 프로젝트 수가 많은 경우 키 공간이 지나치게 커져서 공간 할당량을 초과하면 etcd 성능이 저하될 수 있습니다. etcd 스토리지를 확보하기 위해 조각 모음을 포함한 etcd의 유지보수를 정기적으로 사용하는 것이 좋습니다.
  5. 시스템에는 일부 상태 변경에 대한 대응으로 지정된 네임스페이스의 모든 오브젝트에서 반복해야 하는 컨트롤 루프가 많습니다. 단일 네임스페이스에 지정된 유형의 오브젝트가 많이 있으면 루프 비용이 많이 들고 지정된 상태 변경 처리 속도가 느려질 수 있습니다. 이 제한을 적용하면 애플리케이션 요구사항을 충족하기에 충분한 CPU, 메모리 및 디스크가 시스템에 있다고 가정합니다.
  6. 각 서비스 포트와 각 서비스 백엔드는 iptables에 해당 항목이 있습니다. 지정된 서비스의 백엔드 수는 끝점 오브젝트의 크기에 영향을 미치므로 시스템 전체에서 전송되는 데이터의 크기에 영향을 미칩니다.
  7. OpenShift Container Platform에는 OpenShift Container Platform에서 설치한 제품, OpenShift Container Platform 및 사용자 생성 CRD와 통합된 제품을 포함하여 총 512개의 CRD(사용자 정의 리소스 정의) 제한이 있습니다. 512개 이상의 CRD가 생성되는 경우 oc 명령 요청이 제한될 수 있습니다.
참고

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

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

8.2.1. AWS 클라우드 플랫폼

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

컨트롤 플레인/etcd [1]

r5.4xlarge

16

128

gp3

220

3

us-west-2

인프라 [2]

m5.12xlarge

48

192

gp3

100

3

us-west-2

워크로드 [3]

m5.4xlarge

16

64

gp3

500 [4]

1

us-west-2

Compute

m5.2xlarge

8

32

gp3

100

3/25/250/500 [5]

us-west-2

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

8.2.2. IBM Power 플랫폼

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

컨트롤 플레인/etcd [1]

16

32

io1

GiB당 120 / 10 IOPS

3

인프라 [2]

16

64

gp2

120

2

워크로드 [3]

16

256

gp2

120 [4]

1

Compute

16

64

gp2

120

2~100 [5]

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

8.2.3. IBM Z 플랫폼

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

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

8

32

ds8k

300 / LCU 1

3

Compute [1,3]

8

32

ds8k

150 / LCU 2

노드 4개 (노드당 100/250/500 Pod로 확장)

  1. etcd는 I/O 집약적이고 지연 시간에 민감하므로 두 개의 논리 제어 단위(LCU)에 분산되어 컨트롤 플레인/etcd 노드의 디스크 I/O 로드를 최적화합니다. etcd I/O 수요가 다른 워크로드를 방해하지 않아야 합니다.
  2. 컴퓨팅 노드 4개가 동시에 100/250/500개의 Pod로 여러 반복을 실행하는 테스트에 사용됩니다. 먼저 유휴 Pod를 사용하여 Pod를 인스턴스할 수 있는지 평가합니다. 다음으로, 네트워크 및 CPU의 우선 순위 클라이언트/서버 워크로드가 강조되는 시스템의 안정성을 평가하는 데 사용되었습니다. 클라이언트 및 서버 Pod가 쌍으로 배포되었으며 각 쌍이 두 개의 컴퓨팅 노드에 분배되었습니다.
  3. 별도의 워크로드 노드가 사용되지 않았습니다. 워크로드는 두 개의 컴퓨팅 노드 간에 마이크로 서비스 워크로드를 시뮬레이션합니다.
  4. 사용되는 물리적 프로세서 수는 6개의 IIFL(Integrated F facility)입니다.
  5. 사용된 총 물리 메모리는 512GiB입니다.

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

중요

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

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

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

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

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

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

시나리오 예

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

2200 / 500 = 4.4

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

2200 / 20 = 110

다음과 같습니다.

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

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

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

Pod 유형Pod 수량최대 메모리CPU 코어 수영구 스토리지

apache

100

500MB

0.5

1GB

node.js

200

1GB

1

1GB

postgresql

100

1GB

2

10GB

JBoss EAP

100

1GB

1

1GB

예상 요구사항은 CPU 코어 550개, RAM 450GB 및 스토리지 1.4TB입니다.

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

노드 유형수량CPURAM(GB)

노드(옵션 1)

100

4

16

노드(옵션 2)

50

8

32

노드(옵션 3)

25

16

64

어떤 애플리케이션은 초과 커밋된 환경에 적합하지만 어떤 애플리케이션은 그렇지 않습니다. 대부분의 Java 애플리케이션과 대규모 페이지를 사용하는 애플리케이션은 초과 커밋에 적합하지 않은 애플리케이션의 예입니다. 해당 메모리는 다른 애플리케이션에 사용할 수 없습니다. 위의 예에 나온 환경에서는 초과 커밋이 약 30%이며, 이는 일반적으로 나타나는 비율입니다.

애플리케이션 Pod는 환경 변수 또는 DNS를 사용하여 서비스에 액세스할 수 있습니다. 환경 변수를 사용하는 경우 노드에서 Pod가 실행될 때 활성 서비스마다 kubelet을 통해 변수를 삽입합니다. 클러스터 인식 DNS 서버는 새로운 서비스의 Kubernetes API를 확인하고 각각에 대해 DNS 레코드 세트를 생성합니다. 클러스터 전체에서 DNS가 활성화된 경우 모든 Pod가 자동으로 해당 DNS 이름을 통해 서비스를 확인할 수 있어야 합니다. 서비스가 5,000개를 넘어야 하는 경우 DNS를 통한 서비스 검색을 사용할 수 있습니다. 서비스 검색에 환경 변수를 사용하는 경우 네임스페이스에서 서비스가 5,000개를 넘은 후 인수 목록이 허용되는 길이를 초과하면 Pod 및 배포가 실패하기 시작합니다. 이 문제를 해결하려면 배포의 서비스 사양 파일에서 서비스 링크를 비활성화하십시오.

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

네임스페이스에서 실행할 수 있는 애플리케이션 Pod 수는 서비스 검색에 환경 변수가 사용될 때 서비스 수와 서비스 이름의 길이에 따라 달라집니다. ARG_MAX는 새로운 프로세스의 최대 인수 길이를 정의하고 기본적으로 2097152 KiB로 설정됩니다. Kubelet은 네임스페이스에서 실행되도록 예약된 각 pod에 환경 변수를 삽입합니다. 여기에는 다음이 포함됩니다.

  • <SERVICE_NAME>_SERVICE_HOST=<IP>
  • <SERVICE_NAME>_SERVICE_PORT=<PORT>
  • <SERVICE_NAME>_PORT=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP=tcp://<IP>:<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PROTO=tcp
  • <SERVICE_NAME>_PORT_<PORT>_TCP_PORT=<PORT>
  • <SERVICE_NAME>_PORT_<PORT>_TCP_ADDR=<ADDR>

인수 길이가 허용된 값을 초과하고 서비스 이름의 문자 수에 영향을 미치는 경우 네임스페이스의 Pod가 실패합니다. 예를 들어, 5000개의 서비스가 있는 네임스페이스에서 서비스 이름의 제한은 33자이며, 네임스페이스에서 5000개의 Pod를 실행할 수 있습니다.

9장. 스토리지 최적화

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

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

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

표 9.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 프로비저닝을 지원합니다.
중요

OpenShift Container Platform 4.10에서는 현재 CNS가 지원되지 않습니다.

9.3. 데이터 스토리지 관리

다음 표에는 OpenShift Container Platform 구성 요소가 데이터를 쓰는 기본 디렉터리가 요약되어 있습니다.

표 9.3. OpenShift Container Platform 데이터를 저장하는 기본 디렉터리

디렉터리참고크기 조정예상 증가

/var/log

모든 구성 요소의 로그 파일입니다.

10~30GB입니다.

로그 파일이 빠르게 증가할 수 있습니다. 크기는 디스크를 늘리거나 로그 회전을 사용하여 관리할 수 있습니다.

/var/lib/etcd

데이터베이스를 저장할 때 etcd 스토리지에 사용됩니다.

20GB 미만입니다.

데이터베이스는 최대 8GB까지 증가할 수 있습니다.

환경과 함께 천천히 증가합니다. 메타데이터만 저장합니다.

추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다.

/var/lib/containers

CRI-O 런타임의 마운트 옵션입니다. Pod를 포함한 활성 컨테이너 런타임에 사용되는 스토리지 및 로컬 이미지 스토리지입니다. 레지스트리 스토리지에는 사용되지 않습니다.

16GB 메모리가 있는 노드의 경우 50GB가 증가합니다. 이 크기 조정은 최소 클러스터 요구사항을 결정하는 데 사용하면 안 됩니다.

추가로 메모리가 8GB 증가할 때마다 추가로 20~25GB가 증가합니다.

컨테이너 실행 용량에 의해 증가가 제한됩니다.

/var/lib/kubelet

Pod용 임시 볼륨 스토리지입니다. 런타임 시 컨테이너로 마운트된 외부 요소가 모두 포함됩니다. 영구 볼륨에서 지원하지 않는 환경 변수, kube 보안 및 데이터 볼륨이 포함됩니다.

변동 가능

스토리지가 필요한 Pod가 영구 볼륨을 사용하는 경우 최소입니다. 임시 스토리지를 사용하는 경우 빠르게 증가할 수 있습니다.

9.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장. 라우팅 최적화

OpenShift Container Platform HAProxy 라우터는 성능을 최적화하도록 확장 또는 구성할 수 있습니다.

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

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

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

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

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

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

EncryptionLoadBalancerServiceHostNetwork

none

21515

29622

edge

16743

22913

passthrough

36786

53295

re-encrypt

21583

25198

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

EncryptionLoadBalancerServiceHostNetwork

none

5719

8273

edge

2729

4069

passthrough

4121

5344

re-encrypt

2320

2941

기본 Ingress 컨트롤러 구성은 spec.tuningOptions.threadCount 필드에서 4 로 설정된 상태에서 사용되었습니다. 두 가지 엔드 포인트 게시 전략이 테스트되었습니다: Load Balancer Service 및 Host Network. 암호화된 경로에는 TLS 세션 재개가 사용되었습니다. HTTP keep-alive를 사용하면 단일 HAProxy 라우터가 8kB의 작은 페이지 크기에서 1Gbit NIC를 포화시킬 수 있습니다.

최신 프로세서가 있는 베어 메탈에서 실행하는 경우 성능이 위 퍼블릭 클라우드 인스턴스의 약 2배가 될 것을 예상할 수 있습니다. 이 오버헤드는 퍼블릭 클라우드에서 가상화 계층에 의해 도입되며 프라이빗 클라우드 기반 가상화에도 적용됩니다. 다음 표는 라우터 뒤에서 사용할 애플리케이션 수에 대한 가이드입니다.

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

5-10

정적 파일/웹 서버 또는 캐싱 프록시

100-1000

동적 콘텐츠를 생성하는 애플리케이션

일반적으로 HAProxy는 사용 중인 기술에 따라 최대 1000개의 애플리케이션 경로를 지원할 수 있습니다. Ingress 컨트롤러 성능은 언어 또는 정적 콘텐츠 대비 동적 콘텐츠 등 지원하는 애플리케이션의 기능과 성능에 따라 제한될 수 있습니다.

Ingress 또는 라우터 샤딩을 사용하여 애플리케이션에 대한 경로를 더 많이 제공하면 라우팅 계층을 수평으로 확장하는 데 도움이 됩니다.

Ingress 샤딩에 대한 자세한 내용은 경로 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성네임스페이스 레이블을 사용하여 Ingress 컨트롤러 샤딩 구성을 참조하십시오.

tuningOptions 에 대한 자세한 내용은 Ingress 컨트롤러 구성 매개변수를 참조하십시오.

시간 초과 및 Ingress 컨트롤러 사양의 기타 튜닝 구성에 대한 스레드Ingress 컨트롤러 구성 매개변수 설정에 제공된 정보를 사용하여 Ingress 컨트롤러 배포를 수정할 수 있습니다.

11장. 네트워킹 최적화

OpenShift SDN은 OpenvSwitch, VXLAN(Virtual Extensible LAN) 터널, OpenFlow 규칙 및 iptables를 사용합니다. 이 네트워크는 점보 프레임, NIC(네트워크 인터페이스 컨트롤러) 오프로드, 멀티 큐 및 ethtool 설정을 사용하여 조정할 수 있습니다.

OVN-Kubernetes는 VXLAN 대신 Geneve(Generic Network Virtualization Encapsulation)를 터널 프로토콜로 사용합니다.

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

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

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

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

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

VXLAN 오프로드는 대기 시간을 단축시키지 않습니다. 그러나 대기 시간 테스트에서도 CPU 사용량이 감소합니다.

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

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

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

OpenShift SDN 네트워크 플러그인 오버레이 MTU는 NIC MTU보다 최소 50바이트 작아야 합니다. 이 계정은 SDN 오버레이 헤더에 대한 계정입니다. 따라서 일반적인 이더넷 네트워크에서는 이 값을 1450 으로 설정해야 합니다. 점보 프레임 이더넷 네트워크에서는 이 값을 8950 으로 설정해야 합니다. 이러한 값은 NIC의 구성된 MTU를 기반으로 Cluster Network Operator에서 자동으로 설정해야 합니다. 따라서 클러스터 관리자는 일반적으로 이러한 값을 업데이트하지 않습니다. AWS(Amazon Web Services) 및 베어 메탈 환경은 점보 프레임 이더넷 네트워크를 지원합니다. 이 설정은 특히 TCP(Transmission Control Protocol)에서 처리량에 도움이 됩니다.

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

참고

50바이트 오버레이 헤더는 OpenShift SDN 네트워크 플러그인과 관련이 있습니다. 기타 SDN 솔루션에서는 이 값이 더 크거나 작아야 할 수 있습니다.

11.3. IPsec 영향

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

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

12장. 베어 메탈 호스트 관리

베어 메탈 클러스터에 OpenShift Container Platform을 설치할 때 클러스터에 있는 베어 메탈 호스트에 대한 machinemachineset CR(사용자 정의 리소스)을 사용하여 베어 메탈 노드를 프로비저닝하고 관리할 수 있습니다.

12.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에 지정된 대로 호스트에 해당하는 베어 메탈 노드를 프로비저닝합니다.

12.2. 베어 메탈 호스트 유지관리

OpenShift Container Platform 웹 콘솔에서 클러스터의 베어 메탈 호스트의 세부 정보를 유지 관리할 수 있습니다. 컴퓨팅베어 메탈 호스트로 이동하여 작업 드롭다운 메뉴에서 작업을 선택합니다. 여기에서 BMC 세부 정보, 호스트의 MAC 주소 부팅, 전원 관리 활성화 등의 항목을 관리할 수 있습니다. 네트워크 인터페이스의 세부 정보와 호스트에 대한 드라이브도 검토할 수 있습니다.

베어 메탈 호스트를 유지 관리 모드로 이동할 수 있습니다. 호스트를 유지 관리 모드로 이동할 때 스케줄러는 모든 관리 워크로드를 해당 베어 메탈 노드에서 이동합니다. 유지 관리 모드에서는 새 워크로드가 예약되지 않습니다.

웹 콘솔에서 베어 메탈 호스트를 프로비저닝 해제할 수 있습니다. 호스트 프로비저닝 해제는 다음 작업을 수행합니다.

  1. cluster.k8s.io/delete-machine: true를 사용하여 베어 메탈 호스트 CR에 주석을 답니다.
  2. 관련 머신 세트를 축소합니다.
참고

먼저 데몬 세트와 관리되지 않는 정적 Pod를 다른 노드로 이동하지 않고 호스트의 전원을 끄면 서비스가 중단되고 데이터가 손실될 수 있습니다.

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

12.2.2. 웹 콘솔에서 YAML을 사용하여 클러스터에 베어 메탈 호스트 추가

베어 메탈 호스트를 설명하는 YAML 파일을 사용하여 웹 콘솔의 클러스터에 베어 메탈 호스트를 추가할 수 있습니다.

사전 요구 사항

  • 클러스터에 사용할 RHCOS 컴퓨팅 머신을 베어메탈 인프라에 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 베어 메탈 호스트의 Secret CR을 생성합니다.

절차

  1. 웹 콘솔에서 ComputeBare Metal Hosts로 이동합니다.
  2. Add HostNew from YAML을 선택합니다.
  3. 아래 YAML을 복사하고 붙여넣고 호스트의 세부 정보로 관련 필드를 수정합니다.

    apiVersion: metal3.io/v1alpha1
    kind: BareMetalHost
    metadata:
      name: <bare_metal_host_name>
    spec:
      online: true
      bmc:
        address: <bmc_address>
        credentialsName: <secret_credentials_name>  1
        disableCertificateVerification: True 2
      bootMACAddress: <host_boot_mac_address>
    1
    credentialsName은 유효한 Secret CR을 참조해야 합니다. baremetal-operatorcredentialsName에서 참조되는 유효한 Secret 없이 베어 메탈 호스트를 관리할 수 없습니다. 시크릿 및 시크릿 생성 방법에 대한 자세한 내용은 시크릿 이해하기에서 참조하십시오.
    2
    disableCertificateVerificationtrue 로 설정하면 클러스터와 BMC(Baseboard Management Controller) 간 TLS 호스트 유효성 검사가 비활성화됩니다.
  4. Create를 선택하여 YAML을 저장하고 새 베어 메탈 호스트를 생성합니다.
  5. 사용 가능한 베어 메탈 호스트 수와 일치하도록 복제본 수를 확장합니다. ComputeMachineSets로 이동하고 Actions 드롭다운 메뉴에서 Edit Machine count를 선택하여 클러스터의 머신 수를 늘립니다.

    참고

    oc scale 명령 및 적절한 베어 메탈 머신 세트를 사용하여 베어 메탈 노드 수를 관리할 수도 있습니다.

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

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

참고

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

12.2.4. provisioner 노드에서 베어 메탈 호스트 제거

특정 상황에서는 프로비저너 노드에서 베어 메탈 호스트를 일시적으로 삭제할 수 있습니다. 예를 들어 OpenShift Container Platform 관리 콘솔을 사용하거나 Machine Config Pool 업데이트로 인해 베어 메탈 호스트 재부팅이 트리거되는 경우 OpenShift Container Platform은 통합된 Dell Remote Access Controller(iDrac)에 로그인하여 작업 대기열 삭제를 발행합니다.

사용 가능한 BareMetalHost 오브젝트 수와 일치하는 Machine 오브젝트 수를 관리하지 않으려면 baremetalhost.metal3.io/detached 주석을 MachineSet 오브젝트에 추가합니다.

참고

이 주석은 Provisioned,ExternallyProvisioned 또는 Ready/Available 상태인 BareMetalHost 오브젝트에만 적용됩니다.

사전 요구 사항

  • 클러스터에서 사용할 RHCOS 베어 메탈 컴퓨팅 머신을 설치하고 해당 BareMetalHost 오브젝트를 생성합니다.
  • OpenShift Container Platform CLI (oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. baremetalhost.metal3.io/detached 주석을 추가하여 프로비저너 노드에서 삭제할 컴퓨팅 머신 세트에 주석을 답니다.

    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached'

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

    참고

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

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

    $ oc annotate machineset <machineset> -n openshift-machine-api 'baremetalhost.metal3.io/detached-'

13장. 대규모 페이지의 기능과 애플리케이션에서 대규모 페이지를 사용하는 방법

13.1. 대규모 페이지의 기능

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

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

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

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

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

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

apiVersion: v1
kind: Pod
metadata:
  generateName: hugepages-volume-
spec:
  containers:
  - securityContext:
      privileged: true
    image: rhel7:latest
    command:
    - sleep
    - inf
    name: example
    volumeMounts:
    - mountPath: /dev/hugepages
      name: hugepage
    resources:
      limits:
        hugepages-2Mi: 100Mi 1
        memory: "1Gi"
        cpu: "1"
  volumes:
  - name: hugepage
    emptyDir:
      medium: HugePages
1
hugepages의 메모리 양은 할당할 정확한 양으로 지정하십시오. 이 값을 hugepages의 메모리 양과 페이지 크기를 곱한 값으로 지정하지 마십시오. 예를 들어 대규모 페이지 크기가 2MB이고 애플리케이션에 100MB의 대규모 페이지 지원 RAM을 사용하려면 50개의 대규모 페이지를 할당합니다. OpenShift Container Platform에서 해당 계산을 처리합니다. 위의 예에서와 같이 100MB를 직접 지정할 수 있습니다.

특정 크기의 대규모 페이지 할당

일부 플랫폼에서는 여러 대규모 페이지 크기를 지원합니다. 특정 크기의 대규모 페이지를 할당하려면 대규모 페이지 부팅 명령 매개변수 앞에 대규모 페이지 크기 선택 매개변수 hugepagesz=<size>를 지정합니다. <size> 값은 바이트 단위로 지정해야 하며 스케일링 접미사 [kKmMgG]를 선택적으로 사용할 수 있습니다. 기본 대규모 페이지 크기는 default_hugepagesz=<size> 부팅 매개변수로 정의할 수 있습니다.

대규모 페이지 요구사항

  • 대규모 페이지 요청은 제한과 같아야 합니다. 제한은 지정되었으나 요청은 지정되지 않은 경우 제한이 기본값입니다.
  • 대규모 페이지는 Pod 범위에서 격리됩니다. 컨테이너 격리는 향후 반복에서 계획됩니다.
  • 대규모 페이지에서 지원하는 EmptyDir 볼륨은 Pod 요청보다 더 많은 대규모 페이지 메모리를 사용하면 안 됩니다.
  • SHM_HUGETLBshmget()를 통해 대규모 페이지를 사용하는 애플리케이션은 proc/sys/vm/hugetlb_shm_group과 일치하는 보조 그룹을 사용하여 실행되어야 합니다.

13.3. Downward API를 사용하여 Huge Page 리소스 사용

Downward API를 사용하여 컨테이너에서 사용하는 Huge Page 리소스에 대한 정보를 삽입할 수 있습니다.

리소스 할당을 환경 변수, 볼륨 플러그인 또는 둘 다로 삽입할 수 있습니다. 컨테이너에서 개발하고 실행하는 애플리케이션은 지정된 볼륨에서의 환경 변수 또는 파일을 읽고 사용할 수 있는 리소스를 확인할 수 있습니다.

절차

  1. 다음 예와 유사한 hugepages-volume-pod.yaml 파일을 생성합니다.

    apiVersion: v1
    kind: Pod
    metadata:
      generateName: hugepages-volume-
      labels:
        app: hugepages-example
    spec:
      containers:
      - securityContext:
          capabilities:
            add: [ "IPC_LOCK" ]
        image: rhel7:latest
        command:
        - sleep
        - inf
        name: example
        volumeMounts:
        - mountPath: /dev/hugepages
          name: hugepage
        - mountPath: /etc/podinfo
          name: podinfo
        resources:
          limits:
            hugepages-1Gi: 2Gi
            memory: "1Gi"
            cpu: "1"
          requests:
            hugepages-1Gi: 2Gi
        env:
        - name: REQUESTS_HUGEPAGES_1GI <.>
          valueFrom:
            resourceFieldRef:
              containerName: example
              resource: requests.hugepages-1Gi
      volumes:
      - name: hugepage
        emptyDir:
          medium: HugePages
      - name: podinfo
        downwardAPI:
          items:
            - path: "hugepages_1G_request" <.>
              resourceFieldRef:
                containerName: example
                resource: requests.hugepages-1Gi
                divisor: 1Gi

    <.> requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 REQUESTS_HUGEPAGES_1GI 환경 변수로 표시하도록 지정합니다. <.>는 requests.hugepages-1Gi에서 리소스 사용을 읽고 값을 파일 /etc/podinfo/hugepages_1G_request로 표시하도록 지정합니다.

  2. volume-pod.yaml 파일에서 Pod를 생성합니다.

    $ oc create -f hugepages-volume-pod.yaml

검증

  1. REQUESTS_HUGEPAGES_1GI 환경 변수 값을 확인합니다.

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
         -- env | grep REQUESTS_HUGEPAGES_1GI

    출력 예

    REQUESTS_HUGEPAGES_1GI=2147483648

  2. /etc/podinfo/hugepages_1G_request 파일의 값을 확인합니다.

    $ oc exec -it $(oc get pods -l app=hugepages-example -o jsonpath='{.items[0].metadata.name}') \
         -- cat /etc/podinfo/hugepages_1G_request

    출력 예

    2

13.4. 대규모 페이지 구성

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

13.4.1. 부팅 시

절차

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

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

    $ oc label node <node_using_hugepages> node-role.kubernetes.io/worker-hp=
  2. 다음 콘텐츠로 파일을 생성하고 이름을 hugepages-tuned-boottime.yaml로 지정합니다.

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      name: hugepages 1
      namespace: openshift-cluster-node-tuning-operator
    spec:
      profile: 2
      - data: |
          [main]
          summary=Boot time configuration for hugepages
          include=openshift-node
          [bootloader]
          cmdline_openshift_node_hugepages=hugepagesz=2M hugepages=50 3
        name: openshift-node-hugepages
    
      recommend:
      - machineConfigLabels: 4
          machineconfiguration.openshift.io/role: "worker-hp"
        priority: 30
        profile: openshift-node-hugepages
    1
    Tuned 리소스의 namehugepages로 설정합니다.
    2
    대규모 페이지를 할당할 profile 섹션을 설정합니다.
    3
    일부 플랫폼에서는 다양한 크기의 대규모 페이지를 지원하므로 매개변수 순서가 중요합니다.
    4
    머신 구성 풀 기반 일치를 활성화합니다.
  3. Tuned hugepages 오브젝트를 생성합니다.

    $ oc create -f hugepages-tuned-boottime.yaml
  4. 다음 콘텐츠로 파일을 생성하고 이름을 hugepages-mcp.yaml로 지정합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: worker-hp
      labels:
        worker-hp: ""
    spec:
      machineConfigSelector:
        matchExpressions:
          - {key: machineconfiguration.openshift.io/role, operator: In, values: [worker,worker-hp]}
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker-hp: ""
  5. 머신 구성 풀을 생성합니다.

    $ oc create -f hugepages-mcp.yaml

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

$ oc get node <node_using_hugepages> -o jsonpath="{.status.allocatable.hugepages-2Mi}"
100Mi
참고

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

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

THP(Transparent Huge Page)는 대규모 페이지를 생성, 관리 및 사용하는 대부분의 측면을 자동화하려고 합니다. THP는 대규모 페이지를 자동으로 관리하므로 모든 유형의 워크로드에 대해 항상 최적으로 처리되지는 않습니다. THP는 많은 애플리케이션이 대규모 페이지를 자체적으로 처리하므로 성능 회귀를 유발할 수 있습니다. 따라서 THP를 비활성화하는 것이 좋습니다. 다음 단계에서는 NTO(Node Tuning Operator)를 사용하여 THP를 비활성화하는 방법을 설명합니다.

절차

  1. 다음 콘텐츠로 파일을 생성하고 이름을 thp-disable-tuned.yaml 로 지정합니다.

    apiVersion: tuned.openshift.io/v1
    kind: Tuned
    metadata:
      name: thp-workers-profile
      namespace: openshift-cluster-node-tuning-operator
    spec:
      profile:
      - data: |
          [main]
          summary=Custom tuned profile for OpenShift to turn off THP on worker nodes
          include=openshift-node
    
          [vm]
          transparent_hugepages=never
        name: openshift-thp-never-worker
    
      recommend:
      - match:
        - label: node-role.kubernetes.io/worker
        priority: 25
        profile: openshift-thp-never-worker
  2. Tuned 오브젝트를 생성합니다.

    $ oc create -f thp-disable-tuned.yaml
  3. 활성 프로필 목록을 확인합니다.

    $ oc get profile -n openshift-cluster-node-tuning-operator

검증

  • 노드 중 하나에 로그인하고 일반 THP 검사를 수행하여 노드가 프로필을 성공적으로 적용되었는지 확인합니다.

    $ cat /sys/kernel/mm/transparent_hugepage/enabled

    출력 예

    always madvise [never]

14장. 대기 시간이 짧은 노드를 위한 Performance Addon Operator

14.1. 짧은 대기 시간 이해

Telco/5G 영역에서 Edge 컴퓨팅이 등장하여 대기 시간 및 정체 문제를 줄이고 애플리케이션 성능을 개선하는 데 핵심적인 역할을 하고 있습니다.

간단히 말해, 대기 시간이 데이터(패킷)가 발신자에서 수신자로 이동하고 수신자의 처리 후 발신자로 반환되는 속도를 결정합니다. 5G의 네트워크 성능 요구사항을 충족하려면 대기 시간 지연이 가능한 한 짧아지도록 네트워크 아키텍처를 유지보수하는 것이 중요합니다. 평균 대기 시간이 50ms인 4G 기술에 비해, 5G에서는 1ms 이하의 대기 시간 수치에 도달하는 것을 목표로 합니다. 이렇게 대기 시간이 감소하면 무선 처리량이 10배 증가합니다.

Telco 공간에 배포된 많은 애플리케이션에서는 제로 패킷 손실이 가능한 짧은 대기 시간을 요구하고 있습니다. 제로 패킷 손실 튜닝은 네트워크 성능을 저하시키는 고유한 문제를 완화하는 데 도움이 됩니다. 자세한 내용은 RHOSP(Red Hat OpenStack Platform)에서 제로 패킷 손실 튜닝을 참조하십시오.

Edge 컴퓨팅 이니셔티브는 대기 시간을 줄이는 데에도 큰 역할을 합니다. 말 그대로 클라우드 엣지(Edge)에 있어 사용자에게 더 가깝다고 생각해 보십시오. 이렇게 되면 멀리 있는 데이터 센터와 사용자 간 거리를 크게 줄여 애플리케이션 응답 시간과 성능 대기 시간이 단축됩니다.

관리자는 많은 엣지 사이트와 로컬 서비스를 중앙 집중식으로 관리하여 가능한 한 가장 낮은 관리 비용으로 모든 배포를 실행할 수 있어야 합니다. 또한, 실시간 짧은 대기 시간과 높은 성능을 실현할 수 있도록 클러스터의 특정 노드를 쉽게 배포하고 구성할 수 있어야 합니다. 대기 시간이 짧은 노드는 CNF(클라우드 네이티브 네트워크 기능) 및 DPDK(데이터 플레인 개발 키트)와 같은 애플리케이션에 유용합니다.

OpenShift Container Platform에서는 현재 실시간 실행과 짧은 대기 시간(약 20마이크로초 미만의 반응 시간)을 지원하기 위해 OpenShift Container Platform 클러스터의 소프트웨어를 튜닝하는 메커니즘을 제공합니다. 이 메커니즘에는 커널 및 OpenShift Container Platform 설정 값 튜닝, 커널 설치, 머신 재구성이 포함되어 있습니다. 하지만 이 방법을 사용하려면 4가지 Operator를 설정해야 하며 수동으로 수행할 경우 복잡하고 실수하기 쉬운 많은 구성을 수행해야 합니다.

OpenShift Container Platform에서는 OpenShift 애플리케이션에 대해 짧은 대기 시간 성능을 실현할 수 있도록 자동 튜닝을 구현하는 Performance Addon Operator를 제공합니다. 클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 더욱 쉽게 수행할 수 있습니다. 관리자는 커널을 kernel-rt로 업데이트할지 여부를 지정하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하여 워크로드를 실행할 수 있습니다.

14.1.1. 짧은 대기 시간과 실시간 애플리케이션의 하이퍼 스레딩 정보

하이퍼 스레딩은 물리 CPU 프로세서 코어가 두 개의 논리 코어로 작동하여 두 개의 독립 스레드를 동시에 실행할 수 있는 Intel 프로세서 기술입니다. 하이퍼 스레딩을 사용하면 병렬 처리가 효과적인 특정 워크로드 유형에 대한 시스템 처리량이 향상시킬 수 있습니다. 기본 OpenShift Container Platform 설정에서는 기본적으로 하이퍼 스레딩을 활성화하도록 설정해야합니다.

통신 애플리케이션의 경우 가능한 한 대기 시간을 최소화하도록 애플리케이션 인프라를 설계하는 것이 중요합니다. 하이퍼 스레딩은 성능을 저하시킬 수 있으며 대기 시간이 짧은 컴퓨팅 집약적 워크로드의 처리량에 부정적인 영향을 미칠 수 있습니다. 하이퍼 스레딩을 비활성화하면 예측 가능한 성능이 보장되고 이러한 워크로드의 처리 시간을 줄일 수 있습니다.

참고

OpenShift Container Platform을 실행하는 하드웨어에 따라 하이퍼 스레딩 구현 및 구성이 다릅니다. 해당 하드웨어와 관련된 하이퍼 스레딩 구현에 대한 자세한 내용은 관련 호스트 하드웨어 튜닝 정보를 참조하십시오. 하이퍼 스레딩을 비활성화하면 클러스터 코어당 비용이 증가할 수 있습니다.

14.2. Performance Addon Operator 설치

Performance Addon Operator는 노드 세트에서 고급 노드 성능 튜닝을 활성화하는 기능을 제공합니다. 클러스터 관리자는 OpenShift Container Platform CLI 또는 웹 콘솔을 사용하여 Performance Addon Operator를 설치할 수 있습니다.

14.2.1. CLI를 사용하여 Operator 설치

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

전제 조건

  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 다음 조치를 완료하여 Performance Addon Operator의 네임스페이스를 생성합니다.

    1. openshift-performance-addon-operator 네임스페이스를 정의하는 다음 네임스페이스 CR(사용자 정의 리소스)을 생성하고 해당 YAML을 pao-namespace.yaml 파일에 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: openshift-performance-addon-operator
        annotations:
          workload.openshift.io/allowed: management
    2. 다음 명령을 실행하여 네임스페이스를 생성합니다.

      $ oc create -f pao-namespace.yaml
  2. 다음 오브젝트를 생성하여 이전 단계에서 생성한 네임스페이스에 Performance Addon Operator를 설치합니다.

    1. 다음 OperatorGroup CR을 생성하고 해당 YAML을 pao-operatorgroup.yaml 파일에 저장합니다.

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

      $ oc create -f pao-operatorgroup.yaml
    3. 다음 명령을 실행하여 후속 단계에 필요한 채널 값을 가져옵니다.

      $ oc get packagemanifest performance-addon-operator -n openshift-marketplace -o jsonpath='{.status.defaultChannel}'

      출력 예

      4.10

    4. 다음 서브스크립션 CR을 생성하고 해당 YAML을 pao-sub.yaml 파일에 저장합니다.

      서브스크립션의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-performance-addon-operator-subscription
        namespace: openshift-performance-addon-operator
      spec:
        channel: "<channel>" 1
        name: performance-addon-operator
        source: redhat-operators 2
        sourceNamespace: openshift-marketplace

      1
      .status.defaultChannel 매개변수에 이전 단계에서 가져온 값을 지정합니다.
      2
      redhat-operators 값을 지정해야 합니다.
    5. 다음 명령을 실행하여 서브스크립션 오브젝트를 생성합니다.

      $ oc create -f pao-sub.yaml
    6. openshift-performance-addon-operator 프로젝트로 변경합니다.

      $ oc project openshift-performance-addon-operator

14.2.2. 웹 콘솔을 사용하여 Performance Addon Operator 설치

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

참고

이전 섹션에서 언급한 것처럼 Namespace CR 및 OperatorGroup CR을 생성해야 합니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔을 사용하여 Performance Addon Operator를 설치합니다.

    1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub를 클릭합니다.
    2. 사용 가능한 Operator 목록에서 Performance Addon Operator를 선택하고 설치를 클릭합니다.
    3. Install Operator 페이지에서 All namespaces on the cluster를 선택합니다. 그런 다음, 설치를 클릭합니다.
  2. 선택사항: performance-addon-operator가 성공적으로 설치되었는지 검증합니다.

    1. Operator설치된 Operator 페이지로 전환합니다.
    2. Performance Addon Operatoropenshift-operators 프로젝트에 성공 상태로 나열되어 있는지 확인합니다.

      참고

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

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 문제를 해결할 수 있습니다.

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

14.3. Performance Addon Operator 업그레이드

웹 콘솔을 사용하여 수동으로 Performance Addon Operator의 다음 마이너 버전으로 업그레이드하고 업데이트 상태를 모니터링할 수 있습니다.

14.3.1. Performance Addon Operator 업그레이드 정보

  • OpenShift Container Platform 웹 콘솔을 사용하여 Operator 서브스크립션 채널을 변경하면 Performance Addon Operator의 다음 마이너 버전으로 업그레이드 할 수 있습니다.
  • Performance Addon Operator 설치 중에 자동 z-stream 업데이트를 활성화할 수 있습니다.
  • 업데이트는 OpenShift Container Platform 설치 중에 배포되는 Marketplace Operator를 통해 제공됩니다. Marketplace Operator는 클러스터에서 외부 Operator를 사용할 수 있도록 합니다.
  • 업데이트를 완료하는 데 걸리는 시간은 네트워크 연결에 따라 달라집니다. 대부분의 자동 업데이트는 15분 이내에 완료됩니다.

14.3.1.1. Performance Addon Operator 업그레이드가 클러스터에 미치는 영향

  • 대기 시간이 짧은 튜닝이나 많은 페이지 수는 클러스터에 영향을 미치지 않습니다.
  • Operator 업데이트로 인해 예기치 않은 재부팅이 발생하지 않습니다.

14.3.1.2. Performance Addon Operator를 다음 마이너 버전으로 업그레이드

OpenShift Container Platform 웹 콘솔을 사용하여 Operator 서브스크립션 채널을 변경하면 수동으로 Performance Addon Operator를 다음 마이너 버전으로 업그레이드할 수 있습니다.

전제 조건

  • cluster-admin 역할을 가진 사용자로 클러스터에 액세스합니다.

절차

  1. 웹 콘솔에 액세스하여 OperatorsInstalled Operators로 이동합니다.
  2. Performance Addon Operator를 클릭하여 Operator details 페이지를 엽니다.
  3. Subscription 탭을 클릭하여 Subscription details 페이지를 엽니다.
  4. Update channel 창에서 버전 번호 오른쪽의 연필 아이콘을 클릭하여 Change Subscription update channel 창을 엽니다.
  5. 다음 마이너 버전을 선택합니다. 예를 들어 Performance Addon Operator 4.10 으로 업그레이드하려면 4.10을 선택합니다.
  6. 저장을 클릭합니다.
  7. Operator → 설치된 Operator로 이동하여 업그레이드 상태를 확인합니다. 다음 oc 명령을 실행하여 상태를 확인할 수도 있습니다.

    $ oc get csv -n openshift-performance-addon-operator

14.3.1.3. 이전에 특정 네임스페이스에 설치된 경우 Performance Addon Operator 업그레이드

이전에 Performance Addon Operator를 클러스터의 특정 네임스페이스 (예: openshift-performance-addon-operator)에 설치한 경우를 업그레이드하기 전에 OperatorGroup 개체를 수정하여 targetNamespaces 항목을 제거하십시오.

사전 요구 사항

  • OpenShift Container Platform CLI, oc를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 OpenShift 클러스터에 로그인합니다.

절차

  1. Performance Addon Operator OperatorGroup CR을 편집하고 다음 명령을 실행하여 targetNamespaces 항목이 포함된 spec 요소를 제거합니다.

    $ oc patch operatorgroup -n openshift-performance-addon-operator openshift-performance-addon-operator --type json -p '[{ "op": "remove", "path": "/spec" }]'
  2. OLM(Operator Lifecycle Manager)이 변경 사항을 처리할 때까지 기다립니다.
  3. OperatorGroup CR 변경이 성공적으로 적용되었는지 확인합니다. OperatorGroup CR spec 요소가 제거되었는지 확인합니다.

    $ oc describe -n openshift-performance-addon-operator og openshift-performance-addon-operator
  4. Performance Addon Operator 업그레이드를 진행합니다.

14.3.2. 업그레이드 상태 모니터링

Performance Addon Operator 업그레이드 상태를 모니터링하는 가장 좋은 방법은 CSV(ClusterServiceVersion) PHASE를 확인하는 것입니다. 웹 콘솔에서 또는 oc get csv 명령을 실행하여 CSV 상태를 모니터링할 수도 있습니다.

참고

PHASE 및 조건 값은 사용 가능한 정보를 기반으로 한 근사치입니다.

전제 조건

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

절차

  1. 다음 명령을 실행합니다.

    $ oc get csv
  2. PHASE 필드를 확인하여 출력을 검토합니다. 예를 들면 다음과 같습니다.

    VERSION    REPLACES                                         PHASE
    4.10.0      performance-addon-operator.v4.10.0                Installing
    4.8.0                                                       Replacing
  3. get csv를 다시 실행하여 출력을 검증합니다.

    # oc get csv

    출력 예

    NAME                                DISPLAY                      VERSION   REPLACES                            PHASE
    performance-addon-operator.v4.10.0   Performance Addon Operator   4.10.0     performance-addon-operator.v4.8.0   Succeeded

14.4. 실시간 및 짧은 대기 시간 워크로드 프로비저닝

많은 업계와 조직에서 매우 높은 성능의 컴퓨팅을 필요로 하고 있으며 특히 금융 및 통신 업계에서는 짧고 예측 가능한 대기 시간이 요구될 수 있습니다. 고유한 요구사항을 가지고 있는 이러한 업계에서 사용할 수 있도록 OpenShift Container Platform에서는 OpenShift Container Platform 애플리케이션에 대해 짧은 대기 시간 성능과 일관된 응답 시간을 실현할 수 있도록 자동 튜닝을 구현하는 Performance Addon Operator를 제공합니다.

클러스터 관리자는 이 성능 프로필 구성을 사용하여 보다 안정적인 방식으로 이러한 변경을 수행할 수 있습니다. 관리자는 커널을 kernel-rt(실시간)로 업데이트할지 여부를 지정하고, Pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 CPU를 예약하고, 애플리케이션 컨테이너의 CPU를 분리하여 워크로드를 실행할 수 있습니다.

주의

실행 프로브를 보장된 CPU가 필요한 애플리케이션과 함께 사용하면 대기 시간이 급증할 수 있습니다. 대체 방법으로 올바르게 구성된 네트워크 프로브 세트와 같은 다른 프로브를 사용하는 것이 좋습니다.

14.4.1. 실시간에 대한 알려진 제한 사항

참고

대부분의 배포에서 kernel-rt는 3개의 컨트롤 플레인 노드와 작업자 노드가 3개인 표준 클러스터를 사용하는 경우에만 작업자 노드에서 지원됩니다. OpenShift Container Platform 배포 시 컴팩트하고 단일 노드에 대한 예외가 있습니다. 단일 노드에 설치하려면 단일 컨트롤 플레인 노드에서 kernel-rt가 지원됩니다.

실시간 모드를 완전히 활용하려면 상승된 권한으로 컨테이너를 실행해야 합니다. 권한 부여에 대한 자세한 내용은 컨테이너에 대한 기능 설정을 참조하십시오.

OpenShift Container Platform에서는 허용되는 기능을 제한하므로 SecurityContext를 생성해야 할 수도 있습니다.

참고

RHCOS(Red Hat Enterprise Linux CoreOS) 시스템을 사용하는 베어 메탈 설치에서는 이러한 절차가 완전하게 지원됩니다.

적합한 성능 기대치를 설정한다는 것은 실시간 커널이 만능 해결책이 아니라는 것을 나타냅니다. 설정의 목표는 예측 가능한 응답 시간을 제공하는 일관되고 대기 시간이 짧은 결정성을 갖추는 것입니다. 실시간 커널에는 연관된 추가 커널 오버헤드가 있습니다. 이러한 오버헤드는 주로 별도로 예약된 스레드에서 하드웨어 중단을 처리하는 데서 발생합니다. 일부 워크로드에서 오버헤드가 증가하면 전반적으로 처리량 성능이 저하됩니다. 정확한 저하 수치는 워크로드에 따라 달라지며, 범위는 0%에서 30% 사이입니다. 하지만 이러한 저하는 결정성에 대한 대가입니다.

14.4.2. 실시간 기능이 있는 작업자 프로비저닝

  1. 클러스터에 Performance Addon Operator를 설치합니다.
  2. 선택사항: OpenShift Container Platform 클러스터에 노드를 추가합니다. BIOS 매개변수 설정을 참조하십시오.
  3. oc 명령을 사용하여 실시간 기능이 필요한 작업자 노드에 레이블 worker-rt 를 추가합니다.
  4. 실시간 노드에 대한 새 머신 구성 풀을 생성합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfigPool
    metadata:
      name: worker-rt
      labels:
        machineconfiguration.openshift.io/role: worker-rt
    spec:
      machineConfigSelector:
        matchExpressions:
          - {
               key: machineconfiguration.openshift.io/role,
               operator: In,
               values: [worker, worker-rt],
            }
      paused: false
      nodeSelector:
        matchLabels:
          node-role.kubernetes.io/worker-rt: ""

    이름이 worker-rt인 노드 그룹에 대해 머신 구성 풀 worker-rt 가 생성됩니다.

  5. 노드 역할 레이블을 사용하여 적절한 머신 구성 풀에 노드를 추가합니다.

    참고

    실시간 워크로드로 구성된 노드를 결정해야 합니다. 클러스터의 모든 노드 또는 노드의 하위 집합을 구성할 수 있습니다. 모든 노드가 예상되는 Performance Addon Operator는 전용 머신 구성 풀의 일부입니다. 모든 노드를 사용하는 경우 작업자 노드 역할 레이블에 대해 Performance Addon Operator를 가리켜야 합니다. 서브 세트를 사용하는 경우 해당 노드를 새 머신 구성 풀로 그룹화해야 합니다.

  6. 적절한 하우스키핑 코어 세트와 realTimeKernel: enabled: true를 사용하여 PerformanceProfile을 생성합니다.
  7. PerformanceProfile 에서 machineConfigPoolSelector 를 설정해야 합니다.

      apiVersion: performance.openshift.io/v2
      kind: PerformanceProfile
      metadata:
       name: example-performanceprofile
      spec:
      ...
        realTimeKernel:
          enabled: true
        nodeSelector:
           node-role.kubernetes.io/worker-rt: ""
        machineConfigPoolSelector:
           machineconfiguration.openshift.io/role: worker-rt
  8. 레이블과 일치하는 머신 구성 풀이 있는지 검증합니다.

    $ oc describe mcp/worker-rt

    출력 예

    Name:         worker-rt
    Namespace:
    Labels:       machineconfiguration.openshift.io/role=worker-rt

  9. OpenShift Container Platform에서 노드 구성을 시작합니다. 이 작업에서는 여러 번 재부팅이 수행될 수 있습니다. 노드가 설정될 때까지 기다리십시오. 사용하는 하드웨어에 따라 시간이 오래 걸릴 수 있으며 노드당 20분으로 예상됩니다.
  10. 모든 요소가 예상대로 작동하는지 검증하십시오.

14.4.3. 실시간 커널 설치 검증

다음 명령을 사용하여 실시간 커널이 설치되었는지 검증합니다.

$ oc get node -o wide

4.18.0-305.30.1.rt7.102.el8_4.x86_64 cri-o://1.23.0-99.rhaos4.gitc31de.el8 문자열이 포함된 worker-rt 역할이 있는 작업자를 기록해 둡니다.

NAME                               	STATUS   ROLES           	AGE 	VERSION                  	INTERNAL-IP
EXTERNAL-IP   OS-IMAGE                                       	KERNEL-VERSION
CONTAINER-RUNTIME
rt-worker-0.example.com	          Ready	 worker,worker-rt   5d17h   v1.23.0
128.66.135.107   <none>    	        Red Hat Enterprise Linux CoreOS 46.82.202008252340-0 (Ootpa)
4.18.0-305.30.1.rt7.102.el8_4.x86_64   cri-o://1.23.0-99.rhaos4.10.gitc3131de.el8
[...]

14.4.4. 실시간으로 작동하는 워크로드 생성

실시간 기능을 사용할 워크로드를 준비하려면 다음 절차를 사용하십시오.

프로세스

  1. QoS 클래스가 Guaranteed인 Pod를 생성합니다.
  2. 선택사항: DPDK에 대해 CPU 부하 분산을 비활성화합니다.
  3. 적절한 노드 선택기를 할당합니다.

애플리케이션을 작성하는 경우 애플리케이션 튜닝 및 배포에 설명된 일반 권장 사항을 따르십시오.

14.4.5. QoS 클래스가 Guaranteed인 Pod 생성

QoS 클래스가 Guaranteed로 지정된 Pod를 생성하는 경우 다음 사항에 유의하십시오.

  • Pod의 모든 컨테이너에는 메모리 제한과 메모리 요청이 있어야 하며 동일해야 합니다.
  • Pod의 모든 컨테이너에는 CPU 제한과 CPU 요청이 있어야 하며 동일해야 합니다.

다음 예에서는 컨테이너가 하나인 Pod의 구성 파일을 보여줍니다. 이 컨테이너에는 메모리 제한과 메모리 요청이 있으며 둘 다 200MiB입니다. 이 컨테이너에는 CPU 제한과 CPU 요청이 있으며 둘 다 CPU 1개입니다.

apiVersion: v1
kind: Pod
metadata:
  name: qos-demo
  namespace: qos-example
spec:
  containers:
  - name: qos-demo-ctr
    image: <image-pull-spec>
    resources:
      limits:
        memory: "200Mi"
        cpu: "1"
      requests:
        memory: "200Mi"
        cpu: "1"
  1. Pod를 생성합니다.

    $ oc  apply -f qos-pod.yaml --namespace=qos-example
  2. Pod에 대한 자세한 정보를 봅니다.

    $ oc get pod qos-demo --namespace=qos-example --output=yaml

    출력 예

    spec:
      containers:
        ...
    status:
      qosClass: Guaranteed

    참고

    컨테이너가 자체 메모리 제한은 지정하지만 메모리 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 메모리 요청을 자동으로 할당합니다. 마찬가지로, 컨테이너가 자체 CPU 제한은 지정하지만 CPU 요청은 지정하지 않으면 OpenShift Container Platform에서 제한과 일치하는 CPU 요청을 자동으로 할당합니다.

14.4.6. 선택사항: DPDK에 대해 CPU 부하 분산 비활성화

CPU 부하 분산을 비활성화하거나 활성화하는 기능은 CRI-O 수준에서 구현됩니다. CRI-O 아래의 코드는 다음 요구사항이 충족되는 경우에만 CPU 부하 분산을 비활성화하거나 활성화합니다.

  • Pod는 performance-<profile-name> 런타임 클래스를 사용해야 합니다. 다음과 같이 성능 프로필의 상태를 보고 적절한 이름을 가져올 수 있습니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    ...
    status:
      ...
      runtimeClass: performance-manual
  • Pod에는 cpu-load-balancing.crio.io: true 주석이 있어야 합니다.

Performance Addon Operator는 관련 노드 아래에 고성능 런타임 처리기 구성 스니펫을 생성해야 하고 클러스터 아래에 고성능 런타임 클래스를 생성해야 합니다. CPU 부하 분산 구성 기능을 활성화하는 것을 제외하고는 기본 런타임 처리기와 콘텐츠가 동일합니다.

Pod에 대해 CPU 부하 분산을 비활성화하려면 Pod 사양에 다음 필드가 포함되어야 합니다.

apiVersion: v1
kind: Pod
metadata:
  ...
  annotations:
    ...
    cpu-load-balancing.crio.io: "disable"
    ...
  ...
spec:
  ...
  runtimeClassName: performance-<profile_name>
  ...
참고

CPU 관리자 static 정책이 활성화되어 있는 경우 전체 CPU를 사용하는 guaranteed QoS가 있는 Pod에 대해서만 CPU 부하 분산을 비활성화하십시오. 그렇지 않은 경우 CPU 부하 분산을 비활성화하면 클러스터에 있는 다른 컨테이너의 성능에 영향을 미칠 수 있습니다.

14.4.7. 적절한 노드 선택기 할당

노드에 Pod를 할당하는 기본 방법은 다음과 같이 성능 프로필에서 사용한 것과 동일한 노드 선택기를 사용하는 것입니다.

apiVersion: v1
kind: Pod
metadata:
  name: example
spec:
  # ...
  nodeSelector:
    node-role.kubernetes.io/worker-rt: ""

자세한 내용은 노드 선택기를 사용하여 특정 노드에 Pod 배치를 참조하십시오.

14.4.8. 실시간 기능이 있는 작업자에 대해 워크로드 예약

Performance Addon Operator에서 짧은 대기 시간을 위해 구성한 머신 구성 풀에 연결된 노드와 일치하는 레이블 선택기를 사용합니다. 자세한 내용은 노드에 Pod 할당을 참조하십시오.

14.4.9. 보장된 pod 분리 CPU의 장치 중단 처리 관리

Performance Addon Operator는 호스트 CPU를 pod 인프라 컨테이너를 포함하여 클러스터 및 운영 체제 하우스키핑 작업을 위해 예약된 CPU와 워크로드를 실행하는 애플리케이션 컨테이너를 위한 분리된 CPU로 나누어 호스트 CPU를 관리할 수 있습니다. 이를 통해 대기 시간이 짧은 워크로드의 CPU를 분리된 상태로 설정할 수 있습니다.

장치 중단은 보장된 pod가 실행 중인 CPU를 제외하고 CPU의 과부하를 방지하기 위해 모든 분리된 CPU와 예약된 CPU 간에 균형을 유지합니다. pod에 관련 주석이 설정되어 있으면 보장된 Pod CPU가 장치 인터럽트를 처리하지 못합니다.

새로운 성능 프로파일 필드 globallyDisableIrqLoadBalancing은 장치 중단을 처리할지 여부를 관리하는 데 사용할 수 있습니다. 특정 워크로드의 경우 예약된 CPU는 장치 인터럽트를 처리하기에 충분하지 않으며, 이러한 이유로 장치 인터럽트는 분리된 CPU에서 전역적으로 비활성화되지 않습니다. 기본적으로 Performance Addon Operator는 분리된 CPU에서 장치 인터럽트를 비활성화하지 않습니다.

워크로드에 대한 대기 시간을 단축하기 위해 일부(전체) pod에는 장치 인터럽트를 처리하지 않기 위한 실행 중인 CPU가 필요합니다. pod 주석 irq-load-balancing.crio.io는 장치 인터럽트의 처리 여부를 정의하는 데 사용됩니다. 설정되어 있는 경우 CRI-O는 pod가 실행되는 경우에만 장치 인터럽트를 비활성화합니다.

14.4.9.1. CPU CFS 할당량 비활성화

보장된 개별 Pod의 CPU 제한을 줄이려면 cpu-quota.crio.io: "disable" 주석이 있는 Pod 사양을 생성합니다. 이 주석은 Pod 실행 시 CPU를 완전히 공정한 스케줄러(CFS) 할당량을 비활성화합니다. 다음 Pod 사양에는 이 주석이 포함되어 있습니다.

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      cpu-quota.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...
참고

CPU 관리자 static 정책이 활성화되고 전체 CPU를 사용하는 보장된 QoS가 있는 Pod의 경우 CPU CFS 할당량만 비활성화합니다. 그러지 않으면 CPU CFS 할당량을 비활성화하면 클러스터의 다른 컨테이너 성능에 영향을 줄 수 있습니다.

14.4.9.2. Performance Addon Operator에서 글로벌 장치 인터럽트 처리 비활성화

분리된 CPU 세트에 대한 글로벌 장치 인터럽트를 비활성화하도록 Performance Addon Operator를 구성하려면 성능 프로필에서 globallyDisableIrqLoadBalancing 필드를 true로 설정합니다. true인 경우 충돌하는 Pod 주석이 무시됩니다. false인 경우 IRQ 로드는 모든 CPU에서 균형을 유지합니다.

성능 프로파일 스니펫에서는 이 설정을 보여줍니다.

apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
  name: manual
spec:
  globallyDisableIrqLoadBalancing: true
...

14.4.9.3. 개별 pod에 대한 인터럽트 처리 비활성화

개별 pod의 인터럽트 처리를 비활성화하려면 성능 프로필에서 globallyDisableIrqLoadBalancingfalse 로 설정되어 있는지 확인합니다. 그런 다음 Pod 사양에서 irq-load-balancing.crio.io Pod 주석을 비활성화하도록 설정합니다. 다음 Pod 사양에는 이 주석이 포함되어 있습니다.

apiVersion: performance.openshift.io/v2
kind: Pod
metadata:
  annotations:
      irq-load-balancing.crio.io: "disable"
spec:
    runtimeClassName: performance-<profile_name>
...

14.4.10. 장치 인터럽트 처리를 사용하기 위해 성능 프로파일을 업그레이드

Performance Addon Operator 성능 프로필 CRD(사용자 정의 리소스 정의)를 v1 또는 v1alpha1에서 v2 로 업그레이드하는 경우 기존 프로필에서 globallyDisableIrqLoadBalancingtrue로 설정됩니다.

참고

격리된 CPU 세트에 대해 IRQ 로드 밸런싱이 비활성화되는지의 globallyDisableIrqLoadBalancing 토글입니다. 옵션을 true 로 설정하면 격리된 CPU 세트에 대한 IRQ 로드 밸런싱이 비활성화됩니다. 옵션을 false 로 설정하면 IRQ를 모든 CPU 간에 분산할 수 있습니다.

14.4.10.1. 지원되는 API 버전

Performance Addon Operator는 성능 프로파일 apiVersion 필드의 v2, v1, v1alpha1을 지원합니다. v1 및 v1alpha1 API는 동일합니다. v2 API에는 기본값인 false 값을 사용하여 선택적 부울 필드 loballyDisableIrqLoadBalancing이 포함됩니다.

14.4.10.1.1. Performance Addon Operator의 v1alpha1에서 v1으로 업그레이드

Performance Addon Operator API 버전을 v1alpha1에서 v1로 업그레이드하는 경우 "None" 변환 전략을 사용하여 v1alpha1 성능 프로파일이 즉시 변환되며 API 버전 v1을 사용하여 Performance Addon Operator에 제공됩니다.

14.4.10.1.2. Performance Addon Operator API를 v1alpha1 또는 v1에서 v2로 업그레이드

이전 Performance Addon Operator API 버전에서 업그레이드할 때 기존 v1 및 v1alpha1 성능 프로파일은 true 값으로 globallyDisableIrqLoadBalancing 필드에 삽입하는 변환 Webhook를 사용하여 변환됩니다.

14.4.11. 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.10"
        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

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

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 프로세서에서 기본적으로 활성화되어 있습니다. 하이퍼 스레딩을 활성화하면 특정 코어에서 처리되는 모든 스레드를 동일한 코어에서 분리하거나 처리해야 합니다.

14.4.12.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를 사용합니다.

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

성능 프로필을 사용하면 특정 머신 구성 풀에 속한 노드의 대기 시간 튜닝 측면을 제어할 수 있습니다. 설정을 지정하면 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)를 사용하여 성능 프로파일을 생성하는 방법에 대한 자세한 내용은 성능 프로필 생성을 참조하십시오.

14.5.1. 대규모 페이지 구성

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

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

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

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

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

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

검증

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

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

    출력 예

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

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

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

    출력 예

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

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

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

예를 들어 1G2M 크기를 정의할 수 있습니다. 그러면 Performance Addon Operator가 다음과 같이 노드에서 크기를 둘 다 구성합니다.

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

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

일반 하우스키핑 및 워크로드 작업에서는 대기 시간에 민감한 프로세스에 영향을 줄 수 있는 방식으로 CPU를 사용합니다. 기본적으로 컨테이너 런타임은 모든 온라인 CPU를 사용하여 모든 컨테이너를 함께 실행하여 컨텍스트 전환 및 대기 시간이 급증할 수 있습니다. CPU를 파티셔닝하면 noisy 프로세스가 서로 분리하여 대기 시간에 민감한 프로세스를 방해하는 것을 방지합니다. 다음 표에서는 Performance Add-On Operator를 사용하여 노드를 튜닝한 후 CPU에서 프로세스가 실행되는 방법을 설명합니다.

표 14.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.10 이상 버전에서 워크로드는 선택적으로 민감하게 레이블이 지정될 수 있습니다.

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

중요

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

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

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

절차

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

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

14.6. Performance Addon Operator를 사용하여 NIC 큐 단축

Performance Addon Operator를 사용하면 성능 프로필을 구성하여 각 네트워크 장치에 대한 NIC(네트워크 인터페이스 컨트롤러) 대기열 수를 조정할 수 있습니다. 장치 네트워크 대기열을 사용하면 서로 다른 물리적 대기열 간에 패킷을 배포할 수 있으며 각 대기열은 패킷 처리를 위해 별도의 스레드를 가져옵니다.

실시간 또는 짧은 대기 시간 시스템에서 분리된 CPU에 고정된 불필요한 인터럽트 요청 라인(IRQ)을 예약 또는 하우스키핑 CPU로 이동해야 합니다.

시스템이 필요한 애플리케이션 배포에서 OpenShift Container Platform 네트워킹 또는 DPDK(Data Plane Development Kit) 워크로드와의 혼합 배포에서 우수한 처리량을 달성하려면 여러 대기열이 필요하며 NIC 큐 수는 조정되거나 변경되지 않아야 합니다. 예를 들어 대기 시간을 단축하려면 DPDK 기반 워크로드의 NIC 대기열 수를 예약 또는 하우스키핑 CPU 수만큼 줄여야 합니다.

각 CPU에 대해 기본적으로 너무 많은 대기열이 생성되며 낮은 대기 시간을 위해 튜닝할 때 하우스키핑 CPU에 대한 인터럽트 테이블에 맞지 않습니다. 큐 수를 줄이면 적절한 튜닝이 가능합니다. 큐 수가 적을수록 IRQ 테이블에 맞는 인터럽트 수가 적다는 것을 의미합니다.

14.6.1. 성능 프로파일을 사용하여 NIC 큐 조정

성능 프로파일을 사용하면 각 네트워크 장치의 대기열 수를 조정할 수 있습니다.

지원되는 네트워크 장치는 다음과 같습니다.

  • 비가상 네트워크 장치
  • 멀티 큐(채널)를 지원하는 네트워크 장치

지원되지 않는 네트워크 장치는 다음과 같습니다.

  • Pure Software 네트워크 인터페이스
  • 블록 장치
  • Intel DPDK 가상 기능

사전 요구 사항

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

절차

  1. cluster-admin 권한이 있는 사용자로 Performance Addon Operator를 실행하는 OpenShift Container 클러스터에 로그인합니다.
  2. 하드웨어 및 토폴로지에 적합한 성능 프로파일을 만들고 적용합니다. 프로파일 생성에 대한 지침은 "성능 프로파일 생성" 섹션을 참조하십시오.
  3. 생성된 성능 프로파일을 편집합니다.

    $ oc edit -f <your_profile_name>.yaml
  4. spec 필드를 net 오브젝트로 채웁니다. 오브젝트 목록에는 다음 두 개의 필드가 포함될 수 있습니다.

    • userLevelNetworking은 부울 플래그로 지정된 필수 필드입니다. userLevelNetworkingtrue인 경우 지원되는 모든 장치에 대해 대기열 수가 예약된 CPU 수로 설정됩니다. 기본값은 false입니다.
    • devices는 예약된 CPU 수로 큐를 설정할 장치 목록을 지정하는 선택적 필드입니다. 장치 목록이 비어 있으면 구성이 모든 네트워크 장치에 적용됩니다. 구성은 다음과 같습니다.

      • interfacename: 이 필드는 인터페이스 이름을 지정하고, 양수 또는 음수일 수 있는 쉘 스타일 와일드카드를 지원합니다.

        • 와일드카드 구문의 예는 다음과 같습니다. <string> .*
        • 음수 규칙 앞에는 느낌표가 붙습니다. 제외된 목록이 아닌 모든 장치에 넷 큐 변경 사항을 적용하려면 !<device>를 사용합니다(예: !eno1).
      • vendorID: 접두사가 0x인 16비트 16진수로 표시되는 네트워크 장치 공급업체 ID입니다.
      • deviceID: 0x 접두사가 있는 16비트 16진수로 표시되는 네트워크 장치 ID(모델)입니다.

        참고

        deviceID가 지정되어 있는 경우 vendorID도 정의해야 합니다. 장치 항목 interfaceName, vendorID, vendorIDdeviceID의 쌍에 지정된 모든 장치 식별자와 일치하는 장치는 네트워크 장치로 간주됩니다. 그러면 이 네트워크 장치의 네트워크 대기열 수가 예약된 CPU 수로 설정됩니다.

        두 개 이상의 장치가 지정되면 네트워크 대기열 수가 해당 장치 중 하나와 일치하는 모든 네트워크 장치로 설정됩니다.

  5. 다음 예제 성능 프로필을 사용하여 대기열 수를 모든 장치에 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,54-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  6. 다음 예제 성능 프로필을 사용하여 정의된 장치 식별자와 일치하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,54-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: “eth0”
        - interfaceName: “eth1”
        - vendorID: “0x1af4”
        - deviceID: “0x1000”
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  7. 다음 예제 성능 프로필을 사용하여 인터페이스 이름 eth로 시작하는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,54-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: “eth*”
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  8. 이 예제 성능 프로필을 사용하여 이름이 eno1 이외의 인터페이스가 있는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,54-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: “!eno1”
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  9. 인터페이스 이름 eth0, 0x1af4vendorID0x1000deviceID는 모든 장치에 대해 대기열 수를 예약된 CPU 수로 설정합니다. 성능 프로파일 예는 다음과 같습니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: manual
    spec:
      cpu:
        isolated: 3-51,54-103
        reserved: 0-2,52-54
      net:
        userLevelNetworking: true
        devices:
        - interfaceName: “eth0”
        - vendorID: “0x1af4”
        - deviceID: “0x1000”
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
  10. 업데이트된 성능 프로필을 적용합니다.

    $ oc apply -f <your_profile_name>.yaml

추가 리소스

14.6.2. 대기열 상태 확인

이 섹션에서는 다양한 성능 프로필과 변경 사항이 적용되었는지 확인하는 방법에 대한 여러 예시가 있습니다.

예시 1

이 예에서 네트워크 대기열 수는 지원되는 모든 장치에 대해 예약된 CPU 수(2)로 설정됩니다.

성능 프로필의 관련 섹션은 다음과 같습니다.

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
# ...
  • 다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.

    참고

    성능 프로필이 적용된 노드에서 이 명령을 실행합니다.

    $ ethtool -l <device>
  • 프로필을 적용하기 전에 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4

  • 프로필이 적용된 후 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 1

1
결합된 채널은 지원되는 모든 장치에 대해 예약된 CPU의 총 수가 2임을 보여줍니다. 이는 성능 프로필에 구성된 항목과 일치합니다.

예시 2

이 예에서 네트워크 대기열 수는 특정 vendorID가 있는 지원되는 모든 네트워크 장치에 대해 예약된 CPU 수(2)로 설정됩니다.

성능 프로필의 관련 섹션은 다음과 같습니다.

apiVersion: performance.openshift.io/v2
metadata:
  name: performance
spec:
  kind: PerformanceProfile
  spec:
    cpu:
      reserved: 0-1  #total = 2
      isolated: 2-8
    net:
      userLevelNetworking: true
      devices:
      - vendorID = 0x1af4
# ...
  • 다음 명령을 사용하여 장치와 연결된 대기열의 상태를 표시합니다.

    참고

    성능 프로필이 적용된 노드에서 이 명령을 실행합니다.

    $ ethtool -l <device>
  • 프로필이 적용된 후 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 1

1
vendorID=0x1af4를 사용하는 지원되는 모든 장치에 대해 예약된 CPU의 총 수는 2입니다. 예를 들어 vendorID=0x1af4가 있는 다른 네트워크 장치 ens2가 별도로 존재하는 경우 총 네트워크 대기열 수는 2입니다. 이는 성능 프로필에 구성된 항목과 일치합니다.

예시 3

이 예에서 네트워크 대기열 수는 정의된 장치 식별자와 일치하는 지원되는 모든 네트워크 장치에 대해 예약된 CPU 수(2)로 설정됩니다.

udevadm info는 장치에 대한 자세한 보고서를 제공합니다. 이 예에서 장치는 다음과 같습니다.

# udevadm info -p /sys/class/net/ens4
...
E: ID_MODEL_ID=0x1000
E: ID_VENDOR_ID=0x1af4
E: INTERFACE=ens4
...
# udevadm info -p /sys/class/net/eth0
...
E: ID_MODEL_ID=0x1002
E: ID_VENDOR_ID=0x1001
E: INTERFACE=eth0
...
  • interfaceNameeth0인 장치 및 다음 성능 프로필이 있는 vendorID=0x1af4가 있는 모든 장치에 대해 네트워크 대기열을 2로 설정합니다.

    apiVersion: performance.openshift.io/v2
    metadata:
      name: performance
    spec:
      kind: PerformanceProfile
        spec:
          cpu:
            reserved: 0-1  #total = 2
            isolated: 2-8
          net:
            userLevelNetworking: true
            devices:
            - interfaceName = eth0
            - vendorID = 0x1af4
    ...
  • 프로필이 적용된 후 대기열 상태를 확인합니다.

    $ ethtool -l ens4

    출력 예

    Channel parameters for ens4:
    Pre-set maximums:
    RX:         0
    TX:         0
    Other:      0
    Combined:   4
    Current hardware settings:
    RX:         0
    TX:         0
    Other:      0
    Combined:   2 1

    1
    vendorID=0x1af4를 사용하는 지원되는 모든 장치에 대해 예약된 CPU의 총 개수가 2로 설정됩니다. 예를 들어 vendorID=0x1af4가 있는 다른 네트워크 장치 ens2가 있는 경우 총 네트워크 대기열도 2로 설정됩니다. 마찬가지로 interfaceNameeth0인 장치에는 총 네트워크 대기열이 2로 설정됩니다.

14.6.3. NIC 대기열 조정과 관련된 로깅

할당된 장치를 자세히 설명하는 로그 메시지는 각 Tuned 데몬 로그에 기록됩니다. /var/log/tuned/tuned.log 파일에 다음 메시지가 기록될 수 있습니다.

  • 성공적으로 할당된 장치를 자세히 설명하는 INFO 메시지가 기록됩니다.

    INFO tuned.plugins.base: instance net_test (net): assigning devices ens1, ens2, ens3
  • 장치를 할당할 수 없는 경우 WARNING 메시지가 기록됩니다.

    WARNING  tuned.plugins.base: instance net_test: no matching devices available

14.7. 짧은 대기 시간 CNF 튜닝 상태 디버깅

PerformanceProfile CR(사용자 정의 리소스)에는 튜닝 상태를 보고하고 대기 시간 성능 저하 문제를 디버깅하기 위한 상태 필드가 있습니다. 이러한 필드는 상태를 보고하여 Operator 조정 기능의 상태에 대해 설명합니다.

일반적으로 성능 프로필에 연결된 머신 구성 풀의 상태가 성능 저하 상태이면 PerformanceProfile이 성능 저하 상태가 되는 문제가 발생할 수 있습니다. 이 경우 머신 구성 풀에서 실패 메시지를 발행합니다.

Performance Addon Operator에는 performanceProfile.spec.status.Conditions 상태 필드가 있습니다.

Status:
  Conditions:
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Available
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                True
    Type:                  Upgradeable
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Progressing
    Last Heartbeat Time:   2020-06-02T10:01:24Z
    Last Transition Time:  2020-06-02T10:01:24Z
    Status:                False
    Type:                  Degraded

Status 필드에는 성능 프로필의 상태를 나타내는 Type 값을 지정하는 Conditions가 포함되어 있습니다.

Available
모든 머신 구성 및 Tuned 프로필이 성공적으로 생성되었으며 구성 요소에서 처리해야 하는 클러스터에 사용할 수 있습니다(NTO, MCO, Kubelet).
Upgradeable
Operator에서 유지보수하는 리소스가 업그레이드하기에 안전한 상태인지를 나타냅니다.
Progressing
성능 프로필의 배포 프로세스가 시작되었음을 나타냅니다.
Degraded

다음과 같은 경우 오류를 표시합니다.

  • 성능 프로필 검증에 실패했습니다.
  • 모든 관련 구성 요소 생성이 성공적으로 완료되지 않았습니다.

이러한 각 유형에는 다음 필드가 포함되어 있습니다.

상태
특정 유형의 상태(true 또는 false)입니다.
Timestamp
트랜잭션 타임스탬프입니다.
Reason string
머신에서 읽을 수 있는 이유입니다.
Message string
상태 및 오류 세부 정보(있는 경우)를 설명하는 사람이 읽을 수 있는 이유입니다.

14.7.1. 머신 구성 풀

성능 프로필 및 생성된 제품은 연관 MCP(머신 구성 풀)에 따라 노드에 적용됩니다. MCP에는 성능 애드온을 통해 생성되었고 커널 인수, kube 구성, 대규모 페이지 할당, rt-커널 배포를 포괄하는 머신 구성의 적용 진행 상황에 대한 중요한 정보가 들어 있습니다. 성능 애드온 컨트롤러는 MCP의 변경사항을 모니터링하여 성능 프로필 상태를 적절하게 업데이트합니다.

MCP가 성능 프로필 상태로 값을 반환하는 유일한 상태는 MCP가 Degraded인 경우이며, 이 경우에는 performaceProfile.status.condition.Degraded = true가 됩니다.

다음은 생성된 연관 머신 구성 풀(worker-cnf)이 있는 성능 프로필의 예입니다.

  1. 연관 머신 구성 풀이 성능 저하 상태입니다.

    # oc get mcp

    출력 예

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-2ee57a93fa6c9181b546ca46e1571d2d       True      False      False      3              3                   3                     0                      2d21h
    worker       rendered-worker-d6b2bdc07d9f5a59a6b68950acf25e5f       True      False      False      2              2                   2                     0                      2d21h
    worker-cnf   rendered-worker-cnf-6c838641b8a08fff08dbd8b02fb63f7c   False     True       True       2              1                   1                     1                      2d20h

  2. MCP의 describe 섹션은 이유를 보여줍니다.

    # oc describe mcp worker-cnf

    출력 예

      Message:               Node node-worker-cnf is reporting: "prepping update:
      machineconfig.machineconfiguration.openshift.io \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not
      found"
        Reason:                1 nodes are reporting degraded status on sync

  3. degraded = true로 표시된 성능 프로필 status 필드 아래에도 성능 저하 상태가 표시되어야 합니다.

    # oc describe performanceprofiles performance

    출력 예

    Message: Machine config pool worker-cnf Degraded Reason: 1 nodes are reporting degraded status on sync.
    Machine config pool worker-cnf Degraded Message: Node yquinn-q8s5v-w-b-z5lqn.c.openshift-gce-devel.internal is
    reporting: "prepping update: machineconfig.machineconfiguration.openshift.io
    \"rendered-worker-cnf-40b9996919c08e335f3ff230ce1d170\" not found".    Reason:  MCPDegraded
       Status:  True
       Type:    Degraded

14.8. Red Hat 지원을 받기 위한 짧은 대기 시간 튜닝 디버깅 데이터 수집

지원 사례를 여는 경우 클러스터에 대한 디버깅 정보를 Red Hat 지원에 제공하면 도움이 됩니다.

must-gather 툴을 사용하면 노드 튜닝과 NUMA 토폴로지, 짧은 대기 시간 설정으로 인한 문제를 디버깅하는 데 필요한 다른 정보를 비롯하여 OpenShift Container Platform 클러스터에 대한 진단 정보를 수집할 수 있습니다.

즉각 지원을 받을 수 있도록 OpenShift Container Platform 및 짧은 대기 시간 튜닝 둘 다에 대한 진단 정보를 제공하십시오.

14.8.1. must-gather 툴 정보

oc adm must-gather CLI 명령은 다음과 같이 문제를 디버깅하는 데 필요할 가능성이 높은 클러스터 정보를 수집합니다.

  • 리소스 정의
  • 감사 로그
  • 서비스 로그

--image 인수를 포함하여 명령을 실행하는 경우 이미지를 하나 이상 지정할 수 있습니다. 이미지를 지정하면 툴에서 해당 기능 또는 제품과 관련된 데이터를 수집합니다. oc adm must-gather를 실행하면 클러스터에 새 Pod가 생성됩니다. 해당 Pod에 대한 데이터가 수집되어 must-gather.local로 시작하는 새 디렉터리에 저장됩니다. 이 디렉터리는 현재 작업 디렉터리에 생성됩니다.

14.8.2. 짧은 대기 시간 튜닝 데이터 수집 정보

oc adm must-gather CLI 명령을 사용하여 다음과 같은 짧은 대기 시간 튜닝과 연관된 기능 및 오브젝트를 포함한 클러스터 정보를 수집합니다.

  • Performance Addon Operator 네임스페이스 및 하위 오브젝트.
  • MachineConfigPool 및 연관 MachineConfig 오브젝트.
  • Node Tuning Operator 및 연관 Tuned 오브젝트.
  • Linux Kernel 명령줄 옵션.
  • CPU 및 NUMA 토폴로지.
  • 기본 PCI 장치 정보 및 NUMA 위치.

must-gather 를 사용하여 Performance Addon Operator 디버깅 정보를 수집하려면 Performance Addon Operator must-gather 이미지를 지정해야 합니다.

--image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.10.

14.8.3. 특정 기능에 대한 데이터 수집

oc adm must-gather CLI 명령을 --image 또는 --image-stream 인수와 함께 사용하여 특정 기능에 대한 디버깅 정보를 수집할 수 있습니다. must-gather 툴은 여러 이미지를 지원하므로 단일 명령을 실행하여 둘 이상의 기능에 대한 데이터를 수집할 수 있습니다.

참고

특정 기능 데이터 외에도 기본 must-gather 데이터를 수집하려면 --image-stream=openshift/must-gather 인수를 추가하십시오.

사전 요구 사항

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

프로세스

  1. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  2. --image 또는 --image-stream 인수를 하나 이상 사용하여 oc adm must-gather 명령을 실행합니다. 예를 들어 다음 명령은 기본 클러스터 데이터와 Performance Addon Operator 관련 정보를 모두 수집합니다.

    $ oc adm must-gather \
     --image-stream=openshift/must-gather \ 1
    
     --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.10 2
    1
    기본 OpenShift Container Platform must-gather 이미지입니다.
    2
    짧은 대기 시간 튜닝 진단을 위한 must-gather 이미지입니다.
  3. 작업 디렉터리에 생성된 must-gather 디렉터리의 압축 파일을 생성합니다. 예를 들어 Linux 운영 체제를 사용하는 컴퓨터에서 다음 명령을 실행합니다.

     $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1
    1
    must-gather-local.5421342344627712289/를 실제 디렉터리 이름으로 바꿉니다.
  4. Red Hat Customer Portal에서 해당 지원 사례에 압축 파일을 첨부합니다.

추가 리소스

15장. 플랫폼 검증을 위해 대기 시간 테스트 수행

CNF(클라우드 네이티브 네트워크 기능) 테스트 이미지를 사용하여 CNF 워크로드 실행에 필요한 모든 구성 요소가 설치된 CNF 지원 OpenShift Container Platform 클러스터에서 대기 시간 테스트를 실행할 수 있습니다. 대기 시간 테스트를 실행하여 워크로드에 대한 노드 튜닝을 검증합니다.

cnf-tests 컨테이너 이미지는 registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 에서 사용할 수 있습니다.

중요

cnf-tests 이미지에는 현재 Red Hat에서 지원하지 않는 여러 테스트도 포함되어 있습니다. Red Hat에서 대기 시간 테스트만 지원합니다.

15.1. 대기 시간 테스트 실행을 위한 사전 요구 사항

대기 시간 테스트를 실행하려면 클러스터가 다음 요구 사항을 충족해야 합니다.

  1. Performance Addon Operator를 사용하여 성능 프로필을 구성했습니다.
  2. 클러스터에 필요한 모든 CNF 구성을 적용했습니다.
  3. 클러스터에 기존 MachineConfigPool CR이 적용되어 있습니다. 기본 작업자 풀은 worker-cnf 입니다.

추가 리소스

15.2. 대기 시간 테스트의 검색 모드 정보

검색 모드를 사용하여 구성을 변경하지 않고 클러스터의 기능을 검증합니다. 기존 환경 구성이 테스트에 사용됩니다. 테스트에서는 필요한 구성 항목을 찾고 해당 항목을 사용하여 테스트를 실행할 수 있습니다. 특정 테스트를 실행하는 데 필요한 리소스를 찾을 수 없는 경우에는 테스트를 건너뛰고 사용자에게 적절한 메시지를 제공합니다. 테스트 완료 후 사전 구성한 구성 항목을 정리하지 않으며, 테스트 환경을 다른 테스트 실행에 즉시 사용할 수 있습니다.

중요

대기 시간 테스트를 실행하는 경우 항상 -e DISCOVERY_MODE=true 로 테스트를 실행하고 -ginkgo.focus 를 적절한 대기 시간 테스트로 설정합니다. 검색 모드에서 대기 시간 테스트를 실행하지 않으면 테스트 실행에 의해 기존 라이브 클러스터 성능 프로필 구성이 수정됩니다.

테스트 중 사용되는 노드 제한

NODES_SELECTOR 환경 변수(예: -e NODES_SELECTOR=node-role.kubernetes.io/worker-cnf )를 지정하여 테스트가 실행되는 노드를 제한할 수 있습니다. 테스트에서 생성된 리소스는 라벨이 일치하는 노드로 제한됩니다.

참고

기본 작업자 풀을 재정의하려면 -e ROLE_WORKER_CNF=<custom_worker_pool > 변수를 적절한 레이블을 지정하는 명령에 전달합니다.

15.3. 대기 시간 측정

cnf-tests 이미지는 세 가지 툴을 사용하여 시스템의 대기 시간을 측정합니다.

  • hwlatdetect
  • cyclictest
  • oslat

각 툴에는 특정 사용이 있습니다. 순서대로 도구를 사용하여 안정적인 테스트 결과를 얻을 수 있습니다.

hwlatdetect
베어 메탈 하드웨어에서 수행할 수 있는 기준을 측정합니다. 다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고한 대기 시간이 운영 체제 튜닝을 통해 하드웨어 대기 시간 급증을 수정할 수 없기 때문에 필요한 임계값을 충족하는지 확인합니다.
cyclictest
hwlatdetect 가 검증을 통과한 후 실시간 커널 스케줄러 대기 시간을 확인합니다. cyclictest 툴은 반복된 타이머를 예약하고 원하는 트리거 시간과 실제 트리거 시간 간의 차이를 측정합니다. 차이점은 인터럽트 또는 프로세스 우선순위로 인한 튜닝의 기본적인 문제를 발견할 수 있습니다. 도구는 실시간 커널에서 실행해야 합니다.
oslat
CPU 집약적 DPDK 애플리케이션과 유사하게 작동하며 CPU 사용량이 많은 데이터 처리를 시뮬레이션하는 사용 중인 루프에 대한 모든 중단 및 중단을 측정합니다.

테스트에서는 다음과 같은 환경 변수를 도입합니다.

표 15.1. 대기 시간 테스트 환경 변수

환경 변수설명

LATENCY_TEST_DELAY

테스트 실행을 시작한 후 시간(초)을 지정합니다. 변수를 사용하여 CPU 관리자 조정 루프가 기본 CPU 풀을 업데이트할 수 있습니다. 기본값은 0입니다.

LATENCY_TEST_CPUS

대기 시간 테스트를 실행하는 Pod에서 사용하는 CPU 수를 지정합니다. 변수를 설정하지 않으면 기본 구성에 분리된 모든 CPU가 포함됩니다.

LATENCY_TEST_RUNTIME

대기 시간 테스트를 실행해야 하는 시간(초)을 지정합니다. 기본값은 300초입니다.

HWLATDETECT_MAXIMUM_LATENCY

워크로드 및 운영 체제에 대해 허용되는 최대 하드웨어 대기 시간(마이크로초)을 지정합니다. HWLATDETECT_MAXIMUM_LATENCY 또는 MAXIMUM_LATENCY 값을 설정하지 않으면 툴에서 기본 예상 임계값(20octets)과 도구 자체의 실제 최대 대기 시간을 비교합니다. 그런 다음 테스트가 실패하거나 그에 따라 성공합니다.

CYCLICTEST_MAXIMUM_LATENCY

cyclictest 실행 중에 모든 스레드가 예상하는 최대 대기 시간을 지정합니다. CYCLIEST_MAXIMUM_LATENCY 또는 MAXIMUM_LATEN CY 값을 설정하지 않으면 툴에서 예상과 실제 최대 대기 시간 비교를 건너뜁니다.

OSLAT_MAXIMUM_LATENCY

oslat 테스트 결과에 대해 microseconds의 최대 허용 대기 시간을 지정합니다. OSLAT_MAXIMUM_LATENCY 또는 MAXIMUM_LATENCY 값을 설정하지 않으면 툴에서 예상과 실제 최대 대기 시간 비교를 건너뜁니다.

MAXIMUM_LATENCY

microseconds에서 허용되는 최대 대기 시간을 지정하는 통합 변수입니다. 사용 가능한 모든 대기 시간 툴에 적용됩니다.

LATENCY_TEST_RUN

테스트 실행 여부를 나타내는 부울 매개변수입니다. LATENCY_TEST_RUN 은 기본적으로 false 로 설정됩니다. 대기 시간 테스트를 실행하려면 이 값을 true 로 설정합니다.

참고

대기 시간 툴과 관련된 변수가 통합 변수보다 우선합니다. 예를 들어 OSLAT_MAXIMUM_LATENCY 가 30 마이크로초로 설정되고 MAXIMUM_LATENCY 가 10 마이크로초로 설정된 경우 oslat 테스트가 최대 허용 가능한 대기 시간 30마이크로 실행됩니다.

15.4. 대기 시간 테스트 실행

클러스터 대기 시간 테스트를 실행하여 CNF(클라우드 네이티브 네트워크 기능) 워크로드에 대한 노드 튜닝을 검증합니다.

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

절차

  1. kubeconfig 파일이 포함된 디렉터리에서 쉘 프롬프트를 엽니다.

    테스트 이미지에 현재 디렉터리에 kubeconfig 파일 및 볼륨을 통해 마운트된 관련 $KUBECONFIG 환경 변수를 제공합니다. 이를 통해 실행 중인 컨테이너에서 컨테이너 내부에서 kubeconfig 파일을 사용할 수 있습니다.

  2. 다음 명령을 입력하여 대기 시간 테스트를 실행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
  3. 선택 사항: Append -ginkgo.dryRun 을 사용하여 시험 실행 모드에서 대기 시간 테스트를 실행합니다. 이 명령은 테스트 실행을 확인하는 데 유용합니다.
  4. 선택 사항: Append -ginkgo.v 를 사용하여 향상된 동사를 사용하여 테스트를 실행합니다.
  5. 선택 사항: 특정 성능 프로필에 대해 대기 시간 테스트를 실행하려면 다음 명령을 실행하여 적절한 값을 대체합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e LATENCY_TEST_RUN=true -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
    -e PERF_TEST_PROFILE=<performance_profile> registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh -ginkgo.focus="[performance]\ Latency\ Test"

    다음과 같습니다.

    <performance_profile>
    는 대기 시간 테스트를 실행할 성능 프로필의 이름입니다.
    중요

    유효한 대기 시간 테스트 결과의 경우 최소 12시간 동안 테스트를 실행합니다.

15.4.1. hwlatdetect 실행

hwlatdetect 툴은 RHEL(Red Hat Enterprise Linux) 8.x의 일반 서브스크립션과 함께 rt-kernel 패키지에서 사용할 수 있습니다.

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

사전 요구 사항

  • 클러스터에 실시간 커널이 설치되어 있습니다.
  • 고객 포털 인증 정보를 사용하여 registry.redhat.io 에 로그인했습니다.

절차

  • hwlatdetect 테스트를 실행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=worker-cnf \
    -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="hwlatdetect"

    hwlatdetect 테스트는 10분(600초) 동안 실행됩니다. 최대 관찰 대기 시간이 MAXIMUM_LATENCY (20 ECDHEs)보다 작으면 테스트가 성공적으로 실행됩니다.

    결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

    중요

    유효한 결과를 얻으려면 최소 12 시간 동안 검사를 실행해야 합니다.

    실패 출력 예

    running /usr/bin/validationsuite -ginkgo.v -ginkgo.focus=hwlatdetect
    I0210 17:08:38.607699       7 request.go:668] Waited for 1.047200253s due to client-side throttling, not priority and fairness, request: GET:https://api.ocp.demo.lab:6443/apis/apps.openshift.io/v1?timeout=32s
    Running Suite: CNF Features e2e validation
    ==========================================
    Random Seed: 1644512917
    Will run 0 of 48 specs
    
    SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
    Ran 0 of 48 Specs in 0.001 seconds
    SUCCESS! -- 0 Passed | 0 Failed | 0 Pending | 48 Skipped
    
    PASS
    Discovery mode enabled, skipping setup
    running /usr/bin/cnftests -ginkgo.v -ginkgo.focus=hwlatdetect
    I0210 17:08:41.179269      40 request.go:668] Waited for 1.046001096s due to client-side throttling, not priority and fairness, request: GET:https://api.ocp.demo.lab:6443/apis/storage.k8s.io/v1beta1?timeout=32s
    Running Suite: CNF Features e2e integration tests
    =================================================
    Random Seed: 1644512920
    Will run 1 of 151 specs
    
    SSSSSSS
    ------------------------------
    [performance] Latency Test with the hwlatdetect image
      should succeed
      /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:221
    STEP: Waiting two minutes to download the latencyTest image
    STEP: Waiting another two minutes to give enough time for the cluster to move the pod to Succeeded phase
    Feb 10 17:10:56.045: [INFO]: found mcd machine-config-daemon-dzpw7 for node ocp-worker-0.demo.lab
    Feb 10 17:10:56.259: [INFO]: found mcd machine-config-daemon-dzpw7 for node ocp-worker-0.demo.lab
    Feb 10 17:11:56.825: [ERROR]: timed out waiting for the condition
    
    • Failure [193.903 seconds]
    [performance] Latency Test
    /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:60
      with the hwlatdetect image
      /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:213
        should succeed [It]
        /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:221
    
        Log file created at: 2022/02/10 17:08:45
        Running on machine: hwlatdetect-cd8b6
        Binary: Built with gc go1.16.6 for linux/amd64
        Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
        I0210 17:08:45.716288       1 node.go:37] Environment information: /proc/cmdline: BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-56fabc639a679b757ebae30e5f01b2ebd38e9fde9ecae91c41be41d3e89b37f8/vmlinuz-4.18.0-305.34.2.rt7.107.el8_4.x86_64 random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ignition.platform.id=qemu ostree=/ostree/boot.0/rhcos/56fabc639a679b757ebae30e5f01b2ebd38e9fde9ecae91c41be41d3e89b37f8/0 root=UUID=56731f4f-f558-46a3-85d3-d1b579683385 rw rootflags=prjquota skew_tick=1 nohz=on rcu_nocbs=3-5 tuned.non_isolcpus=ffffffc7 intel_pstate=disable nosoftlockup tsc=nowatchdog intel_iommu=on iommu=pt isolcpus=managed_irq,3-5 systemd.cpu_affinity=0,1,2,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31 + +
        I0210 17:08:45.716782       1 node.go:44] Environment information: kernel version 4.18.0-305.34.2.rt7.107.el8_4.x86_64
        I0210 17:08:45.716861       1 main.go:50] running the hwlatdetect command with arguments [/usr/bin/hwlatdetect --threshold 1 --hardlimit 1 --duration 10 --window 10000000us --width 950000us]
        F0210 17:08:56.815204       1 main.go:53] failed to run hwlatdetect command; out: hwlatdetect:  test duration 10 seconds
           detector: tracer
           parameters:
                Latency threshold: 1us 1
                Sample window:     10000000us
                Sample width:      950000us
             Non-sampling period:  9050000us
                Output File:       None
    
        Starting test
        test finished
        Max Latency: 24us 2
        Samples recorded: 1
        Samples exceeding threshold: 1
        ts: 1644512927.163556381, inner:20, outer:24
        ; err: exit status 1
        goroutine 1 [running]:
        k8s.io/klog.stacks(0xc000010001, 0xc00012e000, 0x25b, 0x2710)
            /remote-source/app/vendor/k8s.io/klog/klog.go:875 +0xb9
        k8s.io/klog.(*loggingT).output(0x5bed00, 0xc000000003, 0xc0000121c0, 0x53ea81, 0x7, 0x35, 0x0)
            /remote-source/app/vendor/k8s.io/klog/klog.go:829 +0x1b0
        k8s.io/klog.(*loggingT).printf(0x5bed00, 0x3, 0x5082da, 0x33, 0xc000113f58, 0x2, 0x2)
            /remote-source/app/vendor/k8s.io/klog/klog.go:707 +0x153
        k8s.io/klog.Fatalf(...)
            /remote-source/app/vendor/k8s.io/klog/klog.go:1276
        main.main()
            /remote-source/app/cnf-tests/pod-utils/hwlatdetect-runner/main.go:53 +0x897
    
        goroutine 6 [chan receive]:
        k8s.io/klog.(*loggingT).flushDaemon(0x5bed00)
            /remote-source/app/vendor/k8s.io/klog/klog.go:1010 +0x8b
        created by k8s.io/klog.init.0
            /remote-source/app/vendor/k8s.io/klog/klog.go:411 +0xd8
    
        goroutine 7 [chan receive]:
        k8s.io/klog/v2.(*loggingT).flushDaemon(0x5bede0)
            /remote-source/app/vendor/k8s.io/klog/v2/klog.go:1169 +0x8b
        created by k8s.io/klog/v2.init.0
            /remote-source/app/vendor/k8s.io/klog/v2/klog.go:420 +0xdf
        Unexpected error:
            <*errors.errorString | 0xc000418ed0>: {
                s: "timed out waiting for the condition",
            }
            timed out waiting for the condition
        occurred
    
        /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:433
    ------------------------------
    SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
    JUnit report was created: /junit.xml/cnftests-junit.xml
    
    
    Summarizing 1 Failure:
    
    [Fail] [performance] Latency Test with the hwlatdetect image [It] should succeed
    /remote-source/app/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:433
    
    Ran 1 of 151 Specs in 222.254 seconds
    FAIL! -- 0 Passed | 1 Failed | 0 Pending | 150 Skipped
    
    --- FAIL: TestTest (222.45s)
    FAIL

    1
    MAXIMUM_LATENCY 또는 HWLATDETECT_MAXIMUM_LATENCY 환경 변수를 사용하여 대기 시간 임계값을 구성할 수 있습니다.
    2
    테스트 중 측정된 최대 대기 시간 값입니다.
hwlatdetect 테스트 결과의 예

다음 유형의 결과를 캡처할 수 있습니다.

  • 테스트 전체에서 수행된 변경 사항에 대한 영향을 만들기 위해 각 실행 후 수집된 대략적인 결과.
  • 최상의 결과 및 구성 설정을 사용하여 대략적인 테스트 집합을 결합합니다.

좋은 결과 예

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:
Latency threshold: 10us
Sample window: 1000000us
Sample width: 950000us
Non-sampling period: 50000us
Output File: None

Starting test
test finished
Max Latency: Below threshold
Samples recorded: 0

hwlatdetect 툴에서는 샘플이 지정된 임계값을 초과하는 경우에만 출력을 제공합니다.

잘못된 결과 예

hwlatdetect: test duration 3600 seconds
detector: tracer
parameters:Latency threshold: 10usSample window: 1000000us
Sample width: 950000usNon-sampling period: 50000usOutput File: None

Starting tests:1610542421.275784439, inner:78, outer:81
ts: 1610542444.330561619, inner:27, outer:28
ts: 1610542445.332549975, inner:39, outer:38
ts: 1610542541.568546097, inner:47, outer:32
ts: 1610542590.681548531, inner:13, outer:17
ts: 1610543033.818801482, inner:29, outer:30
ts: 1610543080.938801990, inner:90, outer:76
ts: 1610543129.065549639, inner:28, outer:39
ts: 1610543474.859552115, inner:28, outer:35
ts: 1610543523.973856571, inner:52, outer:49
ts: 1610543572.089799738, inner:27, outer:30
ts: 1610543573.091550771, inner:34, outer:28
ts: 1610543574.093555202, inner:116, outer:63

hwlatdetect 의 출력은 여러 샘플이 임계값을 초과함을 보여줍니다. 그러나 동일한 출력은 다음과 같은 요인에 따라 다른 결과를 나타낼 수 있습니다.

  • 테스트 기간
  • CPU 코어 수
  • 호스트 펌웨어 설정
주의

다음 대기 시간 테스트를 진행하기 전에 hwlatdetect 에서 보고하는 대기 시간이 필요한 임계값을 충족하는지 확인합니다. 하드웨어에서 도입된 대기 시간을 수정하려면 시스템 벤더 지원에 문의해야 할 수 있습니다.

모든 대기 시간 급증이 하드웨어와 관련이 있는 것은 아닙니다. 호스트 펌웨어를 튜닝하여 워크로드 요구 사항을 충족해야 합니다. 자세한 내용은 시스템 튜닝의 펌웨어 매개변수 설정을 참조하십시오.

15.4.2. cyclictest

cyclictest 툴은 지정된 CPU에서 실시간 커널 스케줄러 대기 시간을 측정합니다.

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

사전 요구 사항

  • 고객 포털 인증 정보를 사용하여 registry.redhat.io 에 로그인했습니다.
  • 클러스터에 실시간 커널이 설치되어 있습니다.
  • Performance addon operator를 사용하여 클러스터 성능 프로필을 적용했습니다.

절차

  • cyclictest 를 수행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=worker-cnf \
    -e LATENCY_TEST_CPUS=10 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="cyclictest"

    이 명령은 10분(600초) 동안 cyclictest 툴을 실행합니다. 최대 관찰 대기 시간이 MAXIMUM_LATENCY 보다 작으면 테스트가 성공적으로 실행됩니다(이 예제에서는 20 ECDHE). 20 ECDHE 이상의 대기 시간 급증은 일반적으로 telco RAN 워크로드에는 허용되지 않습니다.

    결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

    중요

    유효한 결과를 얻으려면 최소 12 시간 동안 검사를 실행해야 합니다.

    실패 출력 예

    Discovery mode enabled, skipping setup
    running /usr/bin//cnftests -ginkgo.v -ginkgo.focus=cyclictest
    I0811 15:02:36.350033      20 request.go:668] Waited for 1.049965918s due to client-side throttling, not priority and fairness, request: GET:https://api.cnfdc8.t5g.lab.eng.bos.redhat.com:6443/apis/machineconfiguration.openshift.io/v1?timeout=32s
    Running Suite: CNF Features e2e integration tests
    =================================================
    Random Seed: 1628694153
    Will run 1 of 138 specs
    
    SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
    ------------------------------
    [performance] Latency Test with the cyclictest image
      should succeed
      /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:200
    STEP: Waiting two minutes to download the latencyTest image
    STEP: Waiting another two minutes to give enough time for the cluster to move the pod to Succeeded phase
    Aug 11 15:03:06.826: [INFO]: found mcd machine-config-daemon-wf4w8 for node cnfdc8.clus2.t5g.lab.eng.bos.redhat.com
    
    • Failure [22.527 seconds]
    [performance] Latency Test
    /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:84
      with the cyclictest image
      /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:188
        should succeed [It]
        /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:200
    
        The current latency 27 is bigger than the expected one 20
        Expected
            <bool>: false
        to be true
    
        /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:219
    
    Log file created at: 2021/08/11 15:02:51
    Running on machine: cyclictest-knk7d
    Binary: Built with gc go1.16.6 for linux/amd64
    Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    I0811 15:02:51.092254       1 node.go:37] Environment information: /proc/cmdline: BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/vmlinuz-4.18.0-305.10.2.rt7.83.el8_4.x86_64 ip=dhcp random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ostree=/ostree/boot.1/rhcos/612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/0 ignition.platform.id=openstack root=UUID=5a4ddf16-9372-44d9-ac4e-3ee329e16ab3 rw rootflags=prjquota skew_tick=1 nohz=on rcu_nocbs=1-3 tuned.non_isolcpus=000000ff,ffffffff,ffffffff,fffffff1 intel_pstate=disable nosoftlockup tsc=nowatchdog intel_iommu=on iommu=pt isolcpus=managed_irq,1-3 systemd.cpu_affinity=0,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103 default_hugepagesz=1G hugepagesz=2M hugepages=128 nmi_watchdog=0 audit=0 mce=off processor.max_cstate=1 idle=poll intel_idle.max_cstate=0
    I0811 15:02:51.092427       1 node.go:44] Environment information: kernel version 4.18.0-305.10.2.rt7.83.el8_4.x86_64
    I0811 15:02:51.092450       1 main.go:48] running the cyclictest command with arguments \
    [-D 600 -95 1 -t 10 -a 2,4,6,8,10,54,56,58,60,62 -h 30 -i 1000 --quiet]
    I0811 15:03:06.147253       1 main.go:54] succeeded to run the cyclictest command: # /dev/cpu_dma_latency set to 0us
    # Histogram
    000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000
    000001 000000   005561  027778  037704  011987  000000  120755  238981  081847  300186
    000002 587440   581106  564207  554323  577416  590635  474442  357940  513895  296033
    000003 011751   011441  006449  006761  008409  007904  002893  002066  003349  003089
    000004 000527   001079  000914  000712  001451  001120  000779  000283  000350  000251
    
    More histogram entries ...
    # Min Latencies: 00002 00001 00001 00001 00001 00002 00001 00001 00001 00001
    # Avg Latencies: 00002 00002 00002 00001 00002 00002 00001 00001 00001 00001
    # Max Latencies: 00018 00465 00361 00395 00208 00301 02052 00289 00327 00114
    # Histogram Overflows: 00000 00220 00159 00128 00202 00017 00069 00059 00045 00120
    # Histogram Overflow at cycle number:
    # Thread 0:
    # Thread 1: 01142 01439 05305 … # 00190 others
    # Thread 2: 20895 21351 30624 … # 00129 others
    # Thread 3: 01143 17921 18334 … # 00098 others
    # Thread 4: 30499 30622 31566 ... # 00172 others
    # Thread 5: 145221 170910 171888 ...
    # Thread 6: 01684 26291 30623 ...# 00039 others
    # Thread 7: 28983 92112 167011 … 00029 others
    # Thread 8: 45766 56169 56171 ...# 00015 others
    # Thread 9: 02974 08094 13214 ... # 00090 others

cyclictest 결과 예

동일한 출력은 다른 워크로드에 대해 다른 결과를 나타낼 수 있습니다. 예를 들어 최대 18ECDHE의 급증은 4G DU 워크로드에는 허용되지만 5G DU 워크로드에서는 사용할 수 없습니다.

좋은 결과 예

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 579506   535967  418614  573648  532870  529897  489306  558076  582350  585188  583793  223781  532480  569130  472250  576043
More histogram entries ...
# Total: 000600000 000600000 000600000 000599999 000599999 000599999 000599998 000599998 000599998 000599997 000599997 000599996 000599996 000599995 000599995 000599995
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00005 00005 00004 00005 00004 00004 00005 00005 00006 00005 00004 00005 00004 00004 00005 00004
# Histogram Overflows: 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000
# Histogram Overflow at cycle number:
# Thread 0:
# Thread 1:
# Thread 2:
# Thread 3:
# Thread 4:
# Thread 5:
# Thread 6:
# Thread 7:
# Thread 8:
# Thread 9:
# Thread 10:
# Thread 11:
# Thread 12:
# Thread 13:
# Thread 14:
# Thread 15:

잘못된 결과 예

running cmd: cyclictest -q -D 10m -p 1 -t 16 -a 2,4,6,8,10,12,14,16,54,56,58,60,62,64,66,68 -h 30 -i 1000 -m
# Histogram
000000 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000001 000000   000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000  000000
000002 564632   579686  354911  563036  492543  521983  515884  378266  592621  463547  482764  591976  590409  588145  589556  353518
More histogram entries ...
# Total: 000599999 000599999 000599999 000599997 000599997 000599998 000599998 000599997 000599997 000599996 000599995 000599996 000599995 000599995 000599995 000599993
# Min Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Avg Latencies: 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002 00002
# Max Latencies: 00493 00387 00271 00619 00541 00513 00009 00389 00252 00215 00539 00498 00363 00204 00068 00520
# Histogram Overflows: 00001 00001 00001 00002 00002 00001 00000 00001 00001 00001 00002 00001 00001 00001 00001 00002
# Histogram Overflow at cycle number:
# Thread 0: 155922
# Thread 1: 110064
# Thread 2: 110064
# Thread 3: 110063 155921
# Thread 4: 110063 155921
# Thread 5: 155920
# Thread 6:
# Thread 7: 110062
# Thread 8: 110062
# Thread 9: 155919
# Thread 10: 110061 155919
# Thread 11: 155918
# Thread 12: 155918
# Thread 13: 110060
# Thread 14: 110060
# Thread 15: 110059 155917

15.4.3. oslat 실행

oslat 테스트는 CPU 집약적 DPDK 애플리케이션을 시뮬레이션하고 모든 중단 및 중단을 측정하여 클러스터가 CPU의 과도한 데이터 처리를 처리하는 방법을 테스트합니다.

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

사전 요구 사항

  • 고객 포털 인증 정보를 사용하여 registry.redhat.io 에 로그인했습니다.
  • Performance Addon Operator를 사용하여 클러스터 성능 프로필을 적용했습니다.

절차

  • oslat 테스트를 수행하려면 다음 명령을 실행하여 변수 값을 적절하게 대체합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e LATENCY_TEST_RUN=true -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=worker-cnf \
    -e LATENCY_TEST_CPUS=7 -e LATENCY_TEST_RUNTIME=600 -e MAXIMUM_LATENCY=20 \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh -ginkgo.v -ginkgo.focus="oslat"

    LATENCY_TEST_CPUSoslat 명령으로 테스트할 CPU 목록을 표시합니다.

    이 명령은 10분(600초) 동안 oslat 툴을 실행합니다. 최대 관찰 대기 시간이 MAXIMUM_LATENCY (20 ECDHEs)보다 작으면 테스트가 성공적으로 실행됩니다.

    결과가 대기 시간 임계값을 초과하면 테스트가 실패합니다.

    중요

    유효한 결과를 얻으려면 최소 12 시간 동안 검사를 실행해야 합니다.

    실패 출력 예

    running /usr/bin//validationsuite -ginkgo.v -ginkgo.focus=oslat
    I0829 12:36:55.386776       8 request.go:668] Waited for 1.000303471s due to client-side throttling, not priority and fairness, request: GET:https://api.cnfdc8.t5g.lab.eng.bos.redhat.com:6443/apis/authentication.k8s.io/v1?timeout=32s
    Running Suite: CNF Features e2e validation
    ==========================================
    
    Discovery mode enabled, skipping setup
    running /usr/bin//cnftests -ginkgo.v -ginkgo.focus=oslat
    I0829 12:37:01.219077      20 request.go:668] Waited for 1.050010755s due to client-side throttling, not priority and fairness, request: GET:https://api.cnfdc8.t5g.lab.eng.bos.redhat.com:6443/apis/snapshot.storage.k8s.io/v1beta1?timeout=32s
    Running Suite: CNF Features e2e integration tests
    =================================================
    Random Seed: 1630240617
    Will run 1 of 142 specs
    
    SSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSS
    ------------------------------
    [performance] Latency Test with the oslat image
      should succeed
      /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:134
    STEP: Waiting two minutes to download the latencyTest image
    STEP: Waiting another two minutes to give enough time for the cluster to move the pod to Succeeded phase
    Aug 29 12:37:59.324: [INFO]: found mcd machine-config-daemon-wf4w8 for node cnfdc8.clus2.t5g.lab.eng.bos.redhat.com
    
    • Failure [49.246 seconds]
    [performance] Latency Test
    /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:59
      with the oslat image
      /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:112
        should succeed [It]
        /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:134
    
        The current latency 27 is bigger than the expected one 20 1
        Expected
            <bool>: false
        to be true
     /go/src/github.com/openshift-kni/cnf-features-deploy/vendor/github.com/openshift-kni/performance-addon-operators/functests/4_latency/latency.go:168
    
    Log file created at: 2021/08/29 13:25:21
    Running on machine: oslat-57c2g
    Binary: Built with gc go1.16.6 for linux/amd64
    Log line format: [IWEF]mmdd hh:mm:ss.uuuuuu threadid file:line] msg
    I0829 13:25:21.569182       1 node.go:37] Environment information: /proc/cmdline: BOOT_IMAGE=(hd0,gpt3)/ostree/rhcos-612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/vmlinuz-4.18.0-305.10.2.rt7.83.el8_4.x86_64 ip=dhcp random.trust_cpu=on console=tty0 console=ttyS0,115200n8 ostree=/ostree/boot.0/rhcos/612d89f4519a53ad0b1a132f4add78372661bfb3994f5fe115654971aa58a543/0 ignition.platform.id=openstack root=UUID=5a4ddf16-9372-44d9-ac4e-3ee329e16ab3 rw rootflags=prjquota skew_tick=1 nohz=on rcu_nocbs=1-3 tuned.non_isolcpus=000000ff,ffffffff,ffffffff,fffffff1 intel_pstate=disable nosoftlockup tsc=nowatchdog intel_iommu=on iommu=pt isolcpus=managed_irq,1-3 systemd.cpu_affinity=0,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51,52,53,54,55,56,57,58,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92,93,94,95,96,97,98,99,100,101,102,103 default_hugepagesz=1G hugepagesz=2M hugepages=128 nmi_watchdog=0 audit=0 mce=off processor.max_cstate=1 idle=poll intel_idle.max_cstate=0
    I0829 13:25:21.569345       1 node.go:44] Environment information: kernel version 4.18.0-305.10.2.rt7.83.el8_4.x86_64
    I0829 13:25:21.569367       1 main.go:53] Running the oslat command with arguments \
    [--duration 600 --rtprio 1 --cpu-list 4,6,52,54,56,58 --cpu-main-thread 2]
    I0829 13:35:22.632263       1 main.go:59] Succeeded to run the oslat command: oslat V 2.00
    Total runtime:    600 seconds
    Thread priority:  SCHED_FIFO:1
    CPU list:     4,6,52,54,56,58
    CPU for main thread:  2
    Workload:     no
    Workload mem:     0 (KiB)
    Preheat cores:    6
    
    Pre-heat for 1 seconds...
    Test starts...
    Test completed.
    
            Core:  4 6 52 54 56 58
        CPU Freq:  2096 2096 2096 2096 2096 2096 (Mhz)
        001 (us):  19390720316 19141129810 20265099129 20280959461 19391991159 19119877333
        002 (us):  5304 5249 5777 5947 6829 4971
        003 (us):  28 14 434 47 208 21
        004 (us):  1388 853 123568 152817 5576 0
        005 (us):  207850 223544 103827 91812 227236 231563
        006 (us):  60770 122038 277581 323120 122633 122357
        007 (us):  280023 223992 63016 25896 214194 218395
        008 (us):  40604 25152 24368 4264 24440 25115
        009 (us):  6858 3065 5815 810 3286 2116
        010 (us):  1947 936 1452 151 474 361
      ...
         Minimum:  1 1 1 1 1 1 (us)
         Average:  1.000 1.000 1.000 1.000 1.000 1.000 (us)
         Maximum:  37 38 49 28 28 19 (us)
         Max-Min:  36 37 48 27 27 18 (us)
        Duration:  599.667 599.667 599.667 599.667 599.667 599.667 (sec)

    1
    이 예에서 측정된 대기 시간은 최대 허용된 값 외부에 있습니다.

15.5. 대기 시간 테스트 실패 보고서 생성

다음 절차에 따라 JUnit 대기 시간 테스트 출력 및 테스트 실패 보고서를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

절차

  • --report 매개변수를 보고서가 덤프되는 경로와 함께 전달하여 문제 해결을 위한 클러스터 상태 및 리소스에 대한 정보가 포함된 테스트 실패 보고서를 생성합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/reportdest:<report_folder_path> \
    -e KUBECONFIG=/kubeconfig/kubeconfig  -e DISCOVERY_MODE=true \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh --report <report_folder_path> \
    -ginkgo.focus="\[performance\]\ Latency\ Test"

    다음과 같습니다.

    <report_folder_path>
    보고서가 생성된 폴더의 경로입니다.

15.6. JUnit 대기 시간 테스트 보고서 생성

다음 절차에 따라 JUnit 대기 시간 테스트 출력 및 테스트 실패 보고서를 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

절차

  • 보고서가 덤프되는 경로와 함께 --junit 매개변수를 전달하여 JUnit 호환 XML 보고서를 생성합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -v $(pwd)/junitdest:<junit_folder_path> \
    -e KUBECONFIG=/kubeconfig/kubeconfig  -e DISCOVERY_MODE=true \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh --junit <junit_folder_path> \
    -ginkgo.focus="\[performance\]\ Latency\ Test"

    다음과 같습니다.

    <junit_folder_path>
    junit 보고서가 생성되는 폴더의 경로입니다.

15.7. 단일 노드 OpenShift 클러스터에서 대기 시간 테스트 실행

단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행할 수 있습니다.

중요

항상 DISCOVERY_MODE=true 세트를 사용하여 대기 시간 테스트를 실행합니다. 그렇지 않은 경우 테스트 모음에서 실행 중인 클러스터 구성을 변경합니다.

참고

podman 명령을 루트가 아닌 사용자 또는 권한이 없는 사용자로 실행하는 경우 권한 거부 오류로 인해 마운트 경로가 실패할 수 있습니다. podman 명령이 작동하도록 하려면 :Z 를 볼륨 생성에 추가합니다(예: -v $(pwd)/:/kubeconfig:Z ). 이렇게 하면 podman 에서 적절한 SELinux 레이블을 다시 지정할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

절차

  • 단일 노드 OpenShift 클러스터에서 대기 시간 테스트를 실행하려면 다음 명령을 실행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e DISCOVERY_MODE=true -e ROLE_WORKER_CNF=master \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"
    참고

    master가 노드가 속하는 유일한 시스템 풀이므로 ROLE_WORKER_CNF=master 가 필요합니다. 대기 시간 테스트에 필요한 MachineConfigPool 을 설정하는 방법에 대한 자세한 내용은 "지시간 테스트 실행을 위한 전제 조건"을 참조하십시오.

    테스트 모음을 실행한 후에는 모든 무위 리소스가 정리됩니다.

15.8. 연결이 끊긴 클러스터에서 대기 시간 테스트 실행

CNF 테스트 이미지는 연결이 끊긴 클러스터에서 외부 레지스트리에 연결할 수 없는 테스트를 실행할 수 있습니다. 여기에는 두 단계가 필요합니다.

  1. cnf-tests 이미지를 사용자 연결 해제된 레지스트리에 미러링합니다.
  2. 사용자 연결 해제된 레지스트리의 이미지를 사용하도록 테스트에 지시합니다.

클러스터에서 액세스할 수 있는 사용자 정의 레지스트리로 이미지 미러링

이미지에 미러 실행 파일이 제공되어 oc 에서 테스트 이미지를 로컬 레지스트리에 미러링하는 데 필요한 입력을 제공합니다.

  1. 클러스터에 액세스할 수 있는 임시 머신에서 다음 명령을 실행합니다. registry.redhat.io:

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    /usr/bin/mirror -registry <disconnected_registry> | oc image mirror -f -

    다음과 같습니다.

    <disconnected_registry>
    구성한 연결이 끊긴 미러 레지스트리(예: my.local.registry:5000/ )입니다.
  2. cnf-tests 이미지를 연결이 끊긴 레지스트리에 미러링한 경우 테스트를 실행할 때 이미지를 가져오는 데 사용되는 원래 레지스트리를 재정의해야 합니다. 예를 들면 다음과 같습니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e DISCOVERY_MODE=true -e IMAGE_REGISTRY="<disconnected_registry>" \
    -e CNF_TESTS_IMAGE="cnf-tests-rhel8:v4.10" \
    /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

사용자 정의 레지스트리의 이미지를 사용하도록 테스트 구성

CNF_TESTS_IMAGEIMAGE_REGISTRY 변수를 사용하여 사용자 정의 테스트 이미지 및 이미지 레지스트리를 사용하여 대기 시간 테스트를 실행할 수 있습니다.

  • 사용자 정의 테스트 이미지 및 이미지 레지스트리를 사용하도록 대기 시간 테스트를 구성하려면 다음 명령을 실행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e IMAGE_REGISTRY="<custom_image_registry>" \
    -e CNF_TESTS_IMAGE="<custom_cnf-tests_image>" \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 /usr/bin/test-run.sh

    다음과 같습니다.

    <custom_image_registry>
    사용자 정의 이미지 레지스트리(예: custom.registry:5000/ )입니다.
    <custom_cnf-tests_image>
    사용자 지정 cnf-tests 이미지입니다(예: custom-cnf-tests-image:latest ).

클러스터 OpenShift 이미지 레지스트리로 이미지 미러링

OpenShift Container Platform은 클러스터에서 표준 워크로드로 실행되는 내장 컨테이너 이미지 레지스트리를 제공합니다.

절차

  1. 경로를 통해 레지스트리를 공개하여 레지스트리에 대한 외부 액세스 권한을 얻습니다.

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. 다음 명령을 실행하여 레지스트리 끝점을 가져옵니다.

    $ REGISTRY=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
  3. 이미지를 공개하는 데 사용할 네임스페이스를 생성합니다.

    $ oc create ns cnftests
  4. 테스트에 사용되는 모든 네임스페이스에서 이미지 스트림을 사용할 수 있도록 설정합니다. 테스트 네임스페이스가 cnf-tests 이미지 스트림에서 이미지를 가져올 수 있도록 하는 데 필요합니다. 다음 명령을 실행합니다.

    $ oc policy add-role-to-user system:image-puller system:serviceaccount:cnf-features-testing:default --namespace=cnftests
    $ oc policy add-role-to-user system:image-puller system:serviceaccount:performance-addon-operators-testing:default --namespace=cnftests
  5. 다음 명령을 실행하여 Docker 보안 이름 및 인증 토큰을 검색합니다.

    $ SECRET=$(oc -n cnftests get secret | grep builder-docker | awk {'print $1'}
    $ TOKEN=$(oc -n cnftests get secret $SECRET -o jsonpath="{.data['\.dockercfg']}" | base64 --decode | jq '.["image-registry.openshift-image-registry.svc:5000"].auth')
  6. dockerauth.json 파일을 생성합니다. 예를 들면 다음과 같습니다.

    $ echo "{\"auths\": { \"$REGISTRY\": { \"auth\": $TOKEN } }}" > dockerauth.json
  7. 이미지 미러링을 수행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:4.10 \
    /usr/bin/mirror -registry $REGISTRY/cnftests |  oc image mirror --insecure=true \
    -a=$(pwd)/dockerauth.json -f -
  8. 테스트를 실행합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    -e DISCOVERY_MODE=true -e IMAGE_REGISTRY=image-registry.openshift-image-registry.svc:5000/cnftests \
    cnf-tests-local:latest /usr/bin/test-run.sh -ginkgo.focus="\[performance\]\ Latency\ Test"

다른 테스트 이미지 세트 미러링

선택적으로 대기 시간 테스트를 위해 미러링된 기본 업스트림 이미지를 변경할 수 있습니다.

절차

  1. mirror 명령은 기본적으로 업스트림 이미지를 미러링합니다. 다음 형식의 파일을 이미지에 전달하여 재정의할 수 있습니다.

    [
        {
            "registry": "public.registry.io:5000",
            "image": "imageforcnftests:4.10"
        }
    ]
  2. 파일을 mirror 명령에 전달합니다. 예를 들어 images.json 으로 로컬로 저장합니다. 다음 명령을 사용하면 로컬 경로가 컨테이너 내 /kubeconfig에 마운트되어 mirror 명령에 전달될 수 있습니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 /usr/bin/mirror \
    --registry "my.local.registry:5000/" --images "/kubeconfig/images.json" \
    |  oc image mirror -f -

15.9. cnf-tests 컨테이너로 오류 문제 해결

대기 시간 테스트를 실행하려면 cnf-tests 컨테이너 내에서 클러스터에 액세스할 수 있어야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

절차

  • 다음 명령을 실행하여 cnf-tests 컨테이너 내부에서 클러스터에 액세스할 수 있는지 확인합니다.

    $ podman run -v $(pwd)/:/kubeconfig:Z -e KUBECONFIG=/kubeconfig/kubeconfig \
    registry.redhat.io/openshift4/cnf-tests-rhel8:v4.10 \
    oc get nodes

    이 명령이 작동하지 않으면 DNS, MTU 크기 또는 방화벽 액세스와 관련된 오류가 발생할 수 있습니다.

16장. 토폴로지 Aware Lifecycle Manager for 클러스터 업데이트

Topology Aware Lifecycle Manager (TALM)를 사용하여 여러 단일 노드 OpenShift 클러스터의 소프트웨어 라이프사이클을 관리할 수 있습니다. TALM은 RHACM(Red Hat Advanced Cluster Management) 정책을 사용하여 대상 클러스터에서 변경 사항을 수행합니다.

중요

토폴로지 Aware Lifecycle Manager는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

16.1. 토폴로지 Aware Lifecycle Manager 구성 정보

Topology Aware Lifecycle Manager (TALM)는 하나 이상의 OpenShift Container Platform 클러스터에 대한 RHACM(Red Hat Advanced Cluster Management) 정책 배포를 관리합니다. 대규모 클러스터에서 TALM을 사용하면 제한된 일괄 처리로 클러스터에 정책을 단계적으로 롤아웃할 수 있습니다. 이를 통해 업데이트 시 가능한 서비스 중단을 최소화할 수 있습니다. TALM을 사용하면 다음 작업을 제어할 수 있습니다.

  • 업데이트의 시간
  • RHACM 관리 클러스터 수
  • 정책을 적용할 관리 클러스터의 하위 세트
  • 클러스터의 업데이트 순서
  • 클러스터에 수정된 정책 세트
  • 클러스터에 수정된 정책 순서

TALM은 y-streams 및 z-streams에서 OpenShift Container Platform y-stream 및 z-stream 업데이트의 오케스트레이션과 2일차 작업을 지원합니다.

16.2. 토폴로지 Aware Lifecycle Manager와 함께 사용되는 관리형 정책 정보

TALM(토폴로지 라이프사이클 관리자)에서는 클러스터 업데이트에 RHACM 정책을 사용합니다.

TALM은 remediationAction 필드가 알리 도록 설정된 정책 CR의 롤아웃을 관리하는 데 사용할 수 있습니다. 지원되는 사용 사례는 다음과 같습니다.

  • 정책 CR 수동 사용자 생성
  • PolicyGenTemplate CRD(사용자 정의 리소스 정의)에서 자동으로 생성된 정책

수동 승인으로 Operator 서브스크립션을 업데이트하는 정책의 경우 TALM은 업데이트된 Operator 설치를 승인하는 추가 기능을 제공합니다.

관리 정책에 대한 자세한 내용은 RHACM 문서의 정책 개요 를 참조하십시오.

PolicyGenTemplate CRD에 대한 자세한 내용은 "PolicyGenTemplate Resource를 사용하여 관리 클러스터 구성"의 "PolicyGenTemplate CRD 정보" 섹션을 참조하십시오.

16.3. 웹 콘솔을 사용하여 토폴로지 Aware Lifecycle Manager 설치

OpenShift Container Platform 웹 콘솔을 사용하여 토폴로지 Aware Lifecycle Manager를 설치할 수 있습니다.

사전 요구 사항

  • RHACM Operator의 최신 버전을 설치합니다.
  • 연결이 끊긴 regitry로 hub 클러스터를 설정합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. OpenShift Container Platform 웹 콘솔에서 OperatorOperatorHub로 이동합니다.
  2. 사용 가능한 Operator 목록에서 Topology Aware Lifecycle Manager 를 검색한 다음 설치를 클릭합니다.
  3. 기본 설치 모드 ["All namespaces on the cluster (default)"] 및 Installed Namespace ("openshift-operators")를 계속 선택하여 Operator가 올바르게 설치되었는지 확인합니다.
  4. 설치를 클릭합니다.

검증

설치에 성공했는지 확인하려면 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. Operator가 All Namespaces 네임스페이스에 설치되어 있고 해당 상태는 Succeeded 인지 확인합니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

  1. Operator설치된 Operator 페이지로 이동하여 Status 열에 오류 또는 실패가 있는지 점검합니다.
  2. 워크로드Pod 페이지로 이동하여 문제를 보고하는 cluster-group-upgrades-controller-manager Pod의 모든 컨테이너에서 로그를 확인합니다.

16.4. CLI를 사용하여 토폴로지 Aware Lifecycle Manager 설치

OpenShift CLI(oc)를 사용하여 TALM(토폴로지 Aware Lifecycle Manager)을 설치할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • RHACM Operator의 최신 버전을 설치합니다.
  • 연결이 끊긴 레지스트리를 사용하여 hub 클러스터를 설정합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. 서브스크립션 CR을 생성합니다.

    1. Subscription CR을 정의하고 YAML 파일을 저장합니다(예: talm-subscription.yaml ).

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: openshift-topology-aware-lifecycle-manager-subscription
        namespace: openshift-operators
      spec:
        channel: "stable"
        name: topology-aware-lifecycle-manager
        source: redhat-operators
        sourceNamespace: openshift-marketplace
    2. 다음 명령을 실행하여 Subscription CR을 생성합니다.

      $ oc create -f talm-subscription.yaml

검증

  1. CSV 리소스를 검사하여 설치에 성공했는지 확인합니다.

    $ oc get csv -n openshift-operators

    출력 예

    NAME                                                      DISPLAY                            VERSION               REPLACES   PHASE
    topology-aware-lifecycle-manager.4.10.0-202206301927      Topology Aware Lifecycle Manager   4.10.0-202206301927              Succeeded

  2. TALM이 실행 중인지 확인합니다.

    $ oc get deploy -n openshift-operators

    출력 예

    NAMESPACE                                          NAME                                             READY   UP-TO-DATE   AVAILABLE   AGE
    openshift-operators                                cluster-group-upgrades-controller-manager        1/1     1            1           14s

16.5. ClusterGroupUpgrade CR 정보

Topology Aware Lifecycle Manager(TALM)는 클러스터 그룹에 대한 ClusterGroupUpgrade CR에서 수정 계획을 빌드합니다. ClusterGroupUpgrade CR에서 다음 사양을 정의할 수 있습니다.

  • 그룹의 클러스터
  • ClusterGroupUpgrade CR 차단
  • 적용 가능한 정책 목록
  • 동시 업데이트 수
  • 적용 가능한 카나리아 업데이트
  • 업데이트 전과 후에 수행할 작업
  • 업데이트 타이밍

TALM은 지정된 클러스터에 대한 정책 수정을 통해 작동하므로 ClusterGroupUpgrade CR의 상태가 다음과 같습니다.

  • UpgradeNotStarted
  • UpgradeCannotStart
  • UpgradeNotComplete
  • UpgradeTimedOut
  • UpgradeCompleted
  • PrecachingRequired
참고

TALM이 클러스터 업데이트를 완료하면 동일한 ClusterGroupUpgrade CR에서 클러스터에서 다시 업데이트되지 않습니다. 다음과 같은 경우 새 ClusterGroupUpgrade CR을 생성해야 합니다.

  • 클러스터를 다시 업데이트해야 하는 경우
  • 클러스터가 업데이트 후 정보 정책과 일치하지 않는 것으로 변경되는 경우

16.5.1. UpgradeNotStarted 상태

ClusterGroupUpgrade CR의 초기 상태는 UpgradeNotStarted 입니다.

TALM은 다음 필드를 기반으로 수정 계획을 빌드합니다.

  • clusterSelector 필드는 업데이트하려는 클러스터의 레이블을 지정합니다.
  • cluster 필드는 업데이트할 클러스터 목록을 지정합니다.
  • canaries 필드는 카나리아 업데이트의 클러스터를 지정합니다.
  • maxConcurrency 필드는 일괄 처리에서 업데이트할 클러스터 수를 지정합니다.

클러스터clusterSelector 필드를 함께 사용하여 결합된 클러스터 목록을 생성할 수 있습니다.

수정 계획은 canaries 필드에 나열된 클러스터로 시작됩니다. 각 카나리아 클러스터는 단일 클러스터 배치를 형성합니다.

참고

카나리아 클러스터를 업데이트하는 동안 오류가 발생하면 업데이트 프로세스가 중지됩니다.

수정 계획이 성공적으로 생성된 후 및 enable 필드가 true 로 설정된 후 ClusterGroupUpgrade CR이 UpgradeNotCompleted 상태로 전환됩니다. 이 시점에서 TALM은 지정된 관리 정책을 사용하여 비호환 클러스터를 업데이트하기 시작합니다.

참고

ClusterGroupUpgrade CR이 UpgradeNotStarted 또는 UpgradeCannotStart 상태인 경우에만 사양 필드를 변경할 수 있습니다.

UpgradeNotStarted 상태의 샘플 ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-upgrade-complete
  namespace: default
spec:
  clusters: 1
  - spoke1
  enable: false
  managedPolicies: 2
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  remediationStrategy: 3
    canaries: 4
      - spoke1
    maxConcurrency: 1 5
    timeout: 240
status: 6
  conditions:
  - message: The ClusterGroupUpgrade CR is not enabled
    reason: UpgradeNotStarted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  placementBindings:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  placementRules:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  remediationPlan:
  - - spoke1

1
업데이트할 클러스터 목록을 정의합니다.
2
수정할 사용자 정의 정책 세트를 나열합니다.
3
클러스터 업데이트의 세부 사항을 정의합니다.
4
카나리아 업데이트의 클러스터를 정의합니다.
5
일괄 처리의 최대 동시 업데이트 수를 정의합니다. 수정 배치 수는 maxConcurrency 값으로 나눈 카나리아 클러스터 수와 카나리아 클러스터를 제외한 클러스터 수입니다. 모든 관리 정책을 이미 준수하는 클러스터는 수정 계획에서 제외됩니다.
6
업데이트 상태에 대한 정보를 표시합니다.

16.5.2. UpgradeCannotStart 상태

UpgradeCannotStart 상태에서 다음과 같은 이유로 인해 업데이트를 시작할 수 없습니다.

  • 시스템에서 차단 CR이 누락됨
  • CR 차단이 완료되지 않았습니다.

16.5.3. UpgradeNotCompleted 상태

UpgradeNotCompleted 상태에서 TALM은 UpgradeNotStarted 상태에 정의된 수정 계획에 따라 정책을 적용합니다.

후속 배치에 대한 정책을 강제 적용하는 것은 현재 배치의 모든 클러스터가 관리되는 모든 정책을 준수하는 후 즉시 시작됩니다. 일괄 처리가 시간 초과되면 TALM은 다음 일괄 처리로 이동합니다. 일괄 처리의 시간 초과 값은 spec.timeout 필드로, 수정 계획의 배치 수로 나눈 값입니다.

참고

관리형 정책은 ClusterGroupUpgrade CR의 managedPolicies 필드에 나열된 순서에 적용됩니다. 하나의 관리형 정책은 한 번에 지정된 클러스터에 적용됩니다. 지정된 클러스터가 현재 정책을 준수하면 다음 관리 정책이 다음 비준수 클러스터에 적용됩니다.

UpgradeNotCompleted 상태의 샘플 ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-upgrade-complete
  namespace: default
spec:
  clusters:
  - spoke1
  enable: true 1
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status: 2
  conditions:
  - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant
    reason: UpgradeNotCompleted
    status: "False"
    type: Ready
  copiedPolicies:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  placementBindings:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  placementRules:
  - cgu-upgrade-complete-policy1-common-cluster-version-policy
  - cgu-upgrade-complete-policy2-common-pao-sub-policy
  remediationPlan:
  - - spoke1
  status:
    currentBatch: 1
    remediationPlanForBatch: 3
      spoke1: 0

1
spec.enable 필드의 값이 true 인 경우 업데이트가 시작됩니다.
2
업데이트가 시작될 때 상태 필드가 적절하게 변경됩니다.
3
배치의 클러스터와 각 클러스터에 현재 적용되는 정책의 인덱스를 나열합니다. 정책의 인덱스는 0 으로 시작하고 인덱스가 status.managedPoliciesForUpgrade 목록의 순서를 따릅니다.

16.5.4. UpgradeTimedOut 상태

UpgradeTimedOut 상태에서 TALM은 ClusterGroupUpgrade CR에 대한 모든 정책이 호환되는 경우 매시간 확인합니다. ClusterGroupUpgrade CR이 삭제되거나 업데이트가 완료될 때까지 검사가 계속됩니다. 정기적인 검사를 통해 네트워크, CPU 또는 기타 문제로 인해 시간이 길어지는 경우 업데이트가 완료될 수 있습니다.

두 가지 경우 TALM이 UpgradeTimedOut 상태로 전환됩니다.

  • 현재 배치에 카나리아 업데이트가 포함되어 있고 일괄 처리의 클러스터가 일괄 타임아웃 내의 모든 관리 정책을 준수하지 않는 경우
  • 클러스터가 remediationStrategy 필드에 지정된 타임아웃 값 내의 관리 정책을 준수하지 않는 경우

정책이 준수되면 TALM이 UpgradeCompleted 상태로 전환됩니다.

16.5.5. UpgradeCompleted 상태

UpgradeCompleted 상태에서 클러스터 업데이트가 완료됩니다.

UpgradeCompleted 상태의 샘플 ClusterGroupUpgrade CR

apiVersion: ran.openshift.io/v1alpha1
kind: ClusterGroupUpgrade
metadata:
  name: cgu-upgrade-complete
  namespace: default
spec:
  actions:
    afterCompletion:
      deleteObjects: true 1
  clusters:
  - spoke1
  enable: true
  managedPolicies:
  - policy1-common-cluster-version-policy
  - policy2-common-pao-sub-policy
  remediationStrategy:
    maxConcurrency: 1
    timeout: 240
status: 2
  conditions:
  - message: The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies
    reason: UpgradeCompleted
    status: "True"
    type: Ready
  managedPoliciesForUpgrade:
  - name: policy1-common-cluster-version-policy
    namespace: default
  - name: policy2-common-pao-sub-policy
    namespace: default
  remediationPlan:
  - - spoke1
  status:
    remediationPlanForBatch:
      spoke1: -2 3

1
spec.action.afterCompletion.deleteObjects 필드의 값은 기본적으로 true 입니다. 업데이트가 완료되면 TALM은 업데이트 중에 생성된 기본 RHACM 개체를 삭제합니다. 이 옵션은 업데이트 후 RHACM 허브가 지속적으로 컴플라이언스를 확인하지 못하도록 하기 위한 것입니다.
2
status 필드에는 업데이트가 성공적으로 완료되었음이 표시됩니다.
3
모든 정책이 클러스터에 적용되는 것을 표시합니다.
<discreet><title>PrecachingRequired 상태</title>

PrecachingRequired 상태에서 클러스터에 업데이트를 시작하기 전에 이미지가 사전 캐시되어야 합니다. 사전 캐싱에 대한 자세한 내용은 "컨테이너 이미지 사전 캐시 기능 사용" 섹션을 참조하십시오.

</discreet>

16.5.6. ClusterGroupUpgrade CR 차단

여러 ClusterGroupUpgrade CR을 생성하고 애플리케이션 순서를 제어할 수 있습니다.

예를 들어 ClusterGroupUpgrade CR A의 시작을 차단하는 ClusterGroupUpgrade CR C를 생성하는 경우 ClusterGroupUpgrade CR A의 상태가 UpgradeComplete 가 될 때까지 시작할 수 없습니다.

하나의 ClusterGroupUpgrade CR에는 여러 개의 차단 CR이 있을 수 있습니다. 이 경우 현재 CR의 업그레이드가 시작되기 전에 모든 차단 CR을 완료해야 합니다.

사전 요구 사항

  • TALM(토폴로지 라이프사이클 관리자)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

절차

  1. ClusterGroupUpgrade CR의 콘텐츠를 cgu-a.yaml,cgu-b.yaml, cgu-c.yaml 파일에 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-a
      namespace: default
    spec:
      blockingCRs: 1
      - name: cgu-c
        namespace: default
      clusters:
      - spoke1
      - spoke2
      - spoke3
      enable: false
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      remediationStrategy:
        canaries:
        - spoke1
        maxConcurrency: 2
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR is not enabled
        reason: UpgradeNotStarted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      placementBindings:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      placementRules:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      remediationPlan:
      - - spoke1
      - - spoke2
    1
    차단 CR을 정의합니다. cgu-a 업데이트는 cgu-c 가 완료될 때까지 시작할 수 없습니다.
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-b
      namespace: default
    spec:
      blockingCRs: 1
      - name: cgu-a
        namespace: default
      clusters:
      - spoke4
      - spoke5
      enable: false
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR is not enabled
        reason: UpgradeNotStarted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke4
      - - spoke5
      status: {}
    1
    cgu-b 업데이트는 cgu-a 가 완료될 때까지 시작할 수 없습니다.
    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-c
      namespace: default
    spec: 1
      clusters:
      - spoke6
      enable: false
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR is not enabled
        reason: UpgradeNotStarted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      managedPoliciesCompliantBeforeUpgrade:
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke6
      status: {}
    1
    cgu-c 업데이트는 차단 CR이 없습니다. enable 필드가 true 로 설정된 경우 TALM이 cgu-c 업데이트를 시작합니다.
  2. 각 관련 CR에 대해 다음 명령을 실행하여 ClusterGroupUpgrade CR을 생성합니다.

    $ oc apply -f <name>.yaml
  3. 관련 각 CR에 대해 다음 명령을 실행하여 업데이트 프로세스를 시작합니다.

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/<name> \
    --type merge -p '{"spec":{"enable":true}}'

    다음 예제에서는 enable 필드가 true 로 설정된 ClusterGroupUpgrade CR을 보여줍니다.

    cgu-a 차단 CR의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-a
      namespace: default
    spec:
      blockingCRs:
      - name: cgu-c
        namespace: default
      clusters:
      - spoke1
      - spoke2
      - spoke3
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      remediationStrategy:
        canaries:
        - spoke1
        maxConcurrency: 2
        timeout: 240
    status:
      conditions:
      - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
          completed: [cgu-c]' 1
        reason: UpgradeCannotStart
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      placementBindings:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      placementRules:
      - cgu-a-policy1-common-cluster-version-policy
      - cgu-a-policy2-common-pao-sub-policy
      - cgu-a-policy3-common-ptp-sub-policy
      remediationPlan:
      - - spoke1
      - - spoke2
      status: {}

    1
    차단 CR 목록을 표시합니다.

    CR을 차단하는 cgu-b 의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-b
      namespace: default
    spec:
      blockingCRs:
      - name: cgu-a
        namespace: default
      clusters:
      - spoke4
      - spoke5
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: 'The ClusterGroupUpgrade CR is blocked by other CRs that have not yet
          completed: [cgu-a]' 1
        reason: UpgradeCannotStart
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy2-common-pao-sub-policy
        namespace: default
      - name: policy3-common-ptp-sub-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-b-policy1-common-cluster-version-policy
      - cgu-b-policy2-common-pao-sub-policy
      - cgu-b-policy3-common-ptp-sub-policy
      - cgu-b-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke4
      - - spoke5
      status: {}

    1
    차단 CR 목록을 표시합니다.

    CR을 차단하는 cgu-c 의 예

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-c
      namespace: default
    spec:
      clusters:
      - spoke6
      enable: true
      managedPolicies:
      - policy1-common-cluster-version-policy
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      - policy4-common-sriov-sub-policy
      remediationStrategy:
        maxConcurrency: 1
        timeout: 240
    status:
      conditions:
      - message: The ClusterGroupUpgrade CR has upgrade policies that are still non compliant 1
        reason: UpgradeNotCompleted
        status: "False"
        type: Ready
      copiedPolicies:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      managedPoliciesCompliantBeforeUpgrade:
      - policy2-common-pao-sub-policy
      - policy3-common-ptp-sub-policy
      managedPoliciesForUpgrade:
      - name: policy1-common-cluster-version-policy
        namespace: default
      - name: policy4-common-sriov-sub-policy
        namespace: default
      placementBindings:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      placementRules:
      - cgu-c-policy1-common-cluster-version-policy
      - cgu-c-policy4-common-sriov-sub-policy
      remediationPlan:
      - - spoke6
      status:
        currentBatch: 1
        remediationPlanForBatch:
          spoke6: 0

    1
    cgu-c 업데이트는 차단 CR이 없습니다.

16.6. 관리형 클러스터에서 정책 업데이트

TALM(토폴로지 라이프사이클 관리자)은 ClusterGroupUpgrade CR에 지정된 클러스터에 대한 정보 정책을 조정합니다. TALM은 관리되는 RHACM 정책 사본을 시행 하여 정보 정책을 해결합니다. 복사된 각 정책에는 자체 RHACM 배치 규칙과 RHACM 배치 바인딩이 있습니다.

하나씩 TALM은 현재 배치의 각 클러스터를 적용 가능한 관리 정책에 해당하는 배치 규칙에 추가합니다. 클러스터가 이미 정책을 준수하는 경우 TALM은 호환 클러스터에 해당 정책을 적용하는 것을 건너뜁니다. 그런 다음 TALM은 비호환 클러스터에 다음 정책을 적용하기 위해 계속 이동합니다. TALM이 일괄 처리에서 업데이트를 완료하면 복사된 정책과 연결된 배치 규칙에서 모든 클러스터가 제거됩니다. 그런 다음 다음 배치의 업데이트가 시작됩니다.

스포크 클러스터에서 RHACM에 호환 상태를 보고하지 않는 경우 hub 클러스터에 대한 관리 정책에 TALM에 필요한 상태 정보가 누락될 수 있습니다. TALM에서는 다음과 같은 방법으로 이러한 경우를 처리합니다.

  • 정책의 status.compliant 필드가 없는 경우 TALM은 정책을 무시하고 로그 항목을 추가합니다. 그런 다음 TALM은 정책의 status.status 필드를 계속 확인합니다.
  • 정책의 status.status 가 누락된 경우 TALM에서 오류를 생성합니다.
  • 정책의 status.status 필드에 클러스터의 규정 준수 상태가 없는 경우 TALM은 해당 클러스터를 해당 정책과 준수하지 않는 것으로 간주합니다.

RHACM 정책에 대한 자세한 내용은 정책 개요 를 참조하십시오.

추가 리소스

PolicyGenTemplate CRD에 대한 자세한 내용은 PolicyGenTemplate CRD 정보를 참조하십시오.

16.6.1. 관리 클러스터에 업데이트 정책 적용

정책을 적용하여 관리 클러스터를 업데이트할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 라이프사이클 관리자)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • hub 클러스터에 RHACM 정책을 생성합니다.

절차

  1. ClusterGroupUpgrade CR의 콘텐츠를 cgu-1.yaml 파일에 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: cgu-1
      namespace: default
    spec:
      managedPolicies: 1
        - policy1-common-cluster-version-policy
        - policy2-common-pao-sub-policy
        - policy3-common-ptp-sub-policy
        - policy4-common-sriov-sub-policy
      enable: false
      clusters: 2
      - spoke1
      - spoke2
      - spoke5
      - spoke6
      remediationStrategy:
        maxConcurrency: 2 3
        timeout: 240 4
    1
    적용할 정책의 이름입니다.
    2
    업데이트할 클러스터 목록입니다.
    3
    maxConcurrency 필드는 동시에 업데이트되는 클러스터 수를 나타냅니다.
    4
    업데이트 제한 시간(분)입니다.
  2. 다음 명령을 실행하여 ClusterGroupUpgrade CR을 생성합니다.

    $ oc create -f cgu-1.yaml
    1. 다음 명령을 실행하여 hub 클러스터에서 ClusterGroupUpgrade CR이 생성되었는지 확인합니다.

      $ oc get cgu --all-namespaces

      출력 예

      NAMESPACE   NAME      AGE
      default     cgu-1     8m55s

    2. 다음 명령을 실행하여 업데이트 상태를 확인합니다.

      $ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq

      출력 예

      {
        "computedMaxConcurrency": 2,
        "conditions": [
          {
            "lastTransitionTime": "2022-02-25T15:34:07Z",
            "message": "The ClusterGroupUpgrade CR is not enabled", 1
            "reason": "UpgradeNotStarted",
            "status": "False",
            "type": "Ready"
          }
        ],
        "copiedPolicies": [
          "cgu-policy1-common-cluster-version-policy",
          "cgu-policy2-common-pao-sub-policy",
          "cgu-policy3-common-ptp-sub-policy",
          "cgu-policy4-common-sriov-sub-policy"
        ],
        "managedPoliciesContent": {
          "policy1-common-cluster-version-policy": "null",
          "policy2-common-pao-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"performance-addon-operator\",\"namespace\":\"openshift-performance-addon-operator\"}]",
          "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
          "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
        },
        "managedPoliciesForUpgrade": [
          {
            "name": "policy1-common-cluster-version-policy",
            "namespace": "default"
          },
          {
            "name": "policy2-common-pao-sub-policy",
            "namespace": "default"
          },
          {
            "name": "policy3-common-ptp-sub-policy",
            "namespace": "default"
          },
          {
            "name": "policy4-common-sriov-sub-policy",
            "namespace": "default"
          }
        ],
        "managedPoliciesNs": {
          "policy1-common-cluster-version-policy": "default",
          "policy2-common-pao-sub-policy": "default",
          "policy3-common-ptp-sub-policy": "default",
          "policy4-common-sriov-sub-policy": "default"
        },
        "placementBindings": [
          "cgu-policy1-common-cluster-version-policy",
          "cgu-policy2-common-pao-sub-policy",
          "cgu-policy3-common-ptp-sub-policy",
          "cgu-policy4-common-sriov-sub-policy"
        ],
        "placementRules": [
          "cgu-policy1-common-cluster-version-policy",
          "cgu-policy2-common-pao-sub-policy",
          "cgu-policy3-common-ptp-sub-policy",
          "cgu-policy4-common-sriov-sub-policy"
        ],
        "precaching": {
          "spec": {}
        },
        "remediationPlan": [
          [
            "spoke1",
            "spoke2"
          ],
          [
            "spoke5",
            "spoke6"
          ]
        ],
        "status": {}
      }

      1
      ClusterGroupUpgrade CR의 spec.enable 필드가 false 로 설정됩니다.
    3. 다음 명령을 실행하여 정책 상태를 확인합니다.

      $ oc get policies -A

      출력 예

      NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
      default     cgu-policy1-common-cluster-version-policy            enforce                                 17m 1
      default     cgu-policy2-common-pao-sub-policy                    enforce                                 17m
      default     cgu-policy3-common-ptp-sub-policy                    enforce                                 17m
      default     cgu-policy4-common-sriov-sub-policy                  enforce                                 17m
      default     policy1-common-cluster-version-policy                inform               NonCompliant       15h
      default     policy2-common-pao-sub-policy                        inform               NonCompliant       15h
      default     policy3-common-ptp-sub-policy                        inform               NonCompliant       18m
      default     policy4-common-sriov-sub-policy                      inform               NonCompliant       18m

      1
      현재 클러스터에 적용되는 정책의 spec.remediationAction 필드가 적용 되도록 설정되어 있습니다. ClusterGroupUpgrade CR의 정보 정보 모드의 관리형 정책은 업데이트 중에 정보 모드를 유지합니다.
  3. 다음 명령을 실행하여 spec.enable 필드의 값을 true 로 변경합니다.

    $ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-1 \
    --patch '{"spec":{"enable":true}}' --type=merge

검증

  1. 다음 명령을 실행하여 업데이트 상태를 다시 확인합니다.

    $ oc get cgu -n default cgu-1 -ojsonpath='{.status}' | jq

    출력 예

    {
      "computedMaxConcurrency": 2,
      "conditions": [ 1
        {
          "lastTransitionTime": "2022-02-25T15:34:07Z",
          "message": "The ClusterGroupUpgrade CR has upgrade policies that are still non compliant",
          "reason": "UpgradeNotCompleted",
          "status": "False",
          "type": "Ready"
        }
      ],
      "copiedPolicies": [
        "cgu-policy1-common-cluster-version-policy",
        "cgu-policy2-common-pao-sub-policy",
        "cgu-policy3-common-ptp-sub-policy",
        "cgu-policy4-common-sriov-sub-policy"
      ],
      "managedPoliciesContent": {
        "policy1-common-cluster-version-policy": "null",
        "policy2-common-pao-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"performance-addon-operator\",\"namespace\":\"openshift-performance-addon-operator\"}]",
        "policy3-common-ptp-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"ptp-operator-subscription\",\"namespace\":\"openshift-ptp\"}]",
        "policy4-common-sriov-sub-policy": "[{\"kind\":\"Subscription\",\"name\":\"sriov-network-operator-subscription\",\"namespace\":\"openshift-sriov-network-operator\"}]"
      },
      "managedPoliciesForUpgrade": [
        {
          "name": "policy1-common-cluster-version-policy",
          "namespace": "default"
        },
        {
          "name": "policy2-common-pao-sub-policy",
          "namespace": "default"
        },
        {
          "name": "policy3-common-ptp-sub-policy",
          "namespace": "default"
        },
        {
          "name": "policy4-common-sriov-sub-policy",
          "namespace": "default"
        }
      ],
      "managedPoliciesNs": {
        "policy1-common-cluster-version-policy": "default",
        "policy2-common-pao-sub-policy": "default",
        "policy3-common-ptp-sub-policy": "default",
        "policy4-common-sriov-sub-policy": "default"
      },
      "placementBindings": [
        "cgu-policy1-common-cluster-version-policy",
        "cgu-policy2-common-pao-sub-policy",
        "cgu-policy3-common-ptp-sub-policy",
        "cgu-policy4-common-sriov-sub-policy"
      ],
      "placementRules": [
        "cgu-policy1-common-cluster-version-policy",
        "cgu-policy2-common-pao-sub-policy",
        "cgu-policy3-common-ptp-sub-policy",
        "cgu-policy4-common-sriov-sub-policy"
      ],
      "precaching": {
        "spec": {}
      },
      "remediationPlan": [
        [
          "spoke1",
          "spoke2"
        ],
        [
          "spoke5",
          "spoke6"
        ]
      ],
      "status": {
        "currentBatch": 1,
        "currentBatchStartedAt": "2022-02-25T15:54:16Z",
        "remediationPlanForBatch": {
          "spoke1": 0,
          "spoke2": 1
        },
        "startedAt": "2022-02-25T15:54:16Z"
      }
    }

    1
    현재 일괄 처리의 업데이트 진행 상황을 반영합니다. 이 명령을 다시 실행하여 진행 상황에 대한 업데이트된 정보를 받습니다.
  2. 정책에 Operator 서브스크립션이 포함된 경우 단일 노드 클러스터에서 직접 설치 진행 상황을 확인할 수 있습니다.

    1. 다음 명령을 실행하여 설치 진행 상황을 확인할 단일 노드 클러스터의 KUBECONFIG 파일을 내보냅니다.

      $ export KUBECONFIG=<cluster_kubeconfig_absolute_path>
    2. 단일 노드 클러스터에 있는 모든 서브스크립션을 확인하고 다음 명령을 실행하여 ClusterGroupUpgrade CR을 통해 설치하려는 정책에서 해당 서브스크립션을 찾습니다.

      $ oc get subs -A | grep -i <subscription_name>

      cluster-logging 정책의 출력 예

      NAMESPACE                              NAME                         PACKAGE                      SOURCE             CHANNEL
      openshift-logging                      cluster-logging              cluster-logging              redhat-operators   stable

  3. 관리 정책 중 하나에 ClusterVersion CR이 포함된 경우 스포크 클러스터에 대해 다음 명령을 실행하여 현재 배치에서 플랫폼 업데이트의 상태를 확인합니다.

    $ oc get clusterversion

    출력 예

    NAME      VERSION   AVAILABLE   PROGRESSING   SINCE   STATUS
    version   4.9.5     True        True          43s     Working towards 4.9.7: 71 of 735 done (9% complete)

  4. 다음 명령을 실행하여 Operator 서브스크립션을 확인합니다.

    $ oc get subs -n <operator-namespace> <operator-subscription> -ojsonpath="{.status}"
  5. 다음 명령을 실행하여 원하는 서브스크립션과 연결된 단일 노드 클러스터에 설치 계획이 있는지 확인합니다.

    $ oc get installplan -n <subscription_namespace>

    cluster-logging Operator의 출력 예

    NAMESPACE                              NAME            CSV                                 APPROVAL   APPROVED
    openshift-logging                      install-6khtw   cluster-logging.5.3.3-4             Manual     true 1

    1
    설치 계획의 Approval 필드가 Manual 로 설정되고 TALM에서 설치 계획을 승인한 후 승인 필드가 false 에서 true 로 변경됩니다.
    참고

    TALM이 서브스크립션이 포함된 정책을 수정하면 해당 서브스크립션에 연결된 모든 설치 계획을 자동으로 승인합니다. Operator를 최신 알려진 버전으로 가져오기 위해 여러 설치 계획이 필요한 경우 TALM에서 여러 설치 계획을 승인하고 하나 이상의 중간 버전을 통해 업그레이드하여 최종 버전으로 가져올 수 있습니다.

  6. 다음 명령을 실행하여 ClusterGroupUpgrade 가 설치하는 정책의 Operator의 클러스터 서비스 버전이 Succeeded 단계에 도달했는지 확인합니다.

    $ oc get csv -n <operator_namespace>

    OpenShift Logging Operator의 출력 예

    NAME                    DISPLAY                     VERSION   REPLACES   PHASE
    cluster-logging.5.4.2   Red Hat OpenShift Logging   5.4.2                Succeeded

16.7. 컨테이너 이미지 사전 캐시 기능 사용

클러스터는 컨테이너 이미지 레지스트리에 액세스하기 위해 대역폭이 제한될 수 있으므로 업데이트가 완료되기 전에 시간 초과가 발생할 수 있습니다.

참고

업데이트 시간은 TALM에 의해 설정되지 않습니다. 수동 애플리케이션 또는 외부 자동화를 통해 업데이트 시작 시 ClusterGroupUpgrade CR을 적용할 수 있습니다.

ClusterGroupUpgrade CR에서 preCaching 필드가 true 로 설정된 경우 컨테이너 이미지 사전 캐싱이 시작됩니다. 성공적인 사전 캐싱 프로세스를 마친 후 정책 수정을 시작할 수 있습니다. enable 필드가 true 로 설정된 경우 수정 작업이 시작됩니다.

사전 캐싱 프로세스는 다음 상태에 있을 수 있습니다.

PrecacheNotStarted

이는 초기 상태 모든 클러스터는 ClusterGroupUpgrade CR의 첫 번째 조정 전달 시 자동으로 할당됩니다.

이 상태에서 TALM은 이전의 불완전한 업데이트에서 남아 있는 설명된 클러스터의 사전 캐싱 네임스페이스 및 허브 뷰 리소스를 삭제합니다. 그런 다음 TALM은 스포크 사전 캐싱 네임스페이스에 대한 새로운 ManagedClusterView 리소스를 생성하여 PrecachePreparing 상태에서 삭제를 확인합니다.

PrecachePreparing
이전 불완전한 업데이트에서 나머지 리소스를 정리하는 작업이 진행 중입니다.
PrecacheStarting
사전 캐싱 작업 사전 요구 사항 및 작업이 생성됩니다.
PrecacheActive
작업은 "Active" 상태입니다.
PrecacheSucceeded
pre-cache 작업이 성공했습니다.
PrecacheTimeout
아티팩트 사전 캐싱이 부분적으로 완료되었습니다.
PrecacheUnrecoverableError
작업이 0이 아닌 종료 코드로 종료됩니다.

16.7.1. 사전 캐싱을 사용하여 ClusterGroupUpgrade CR 생성

사전 캐시 기능을 사용하면 업데이트가 시작되기 전에 스포크 클러스터에 필요한 컨테이너 이미지를 표시할 수 있습니다.

사전 요구 사항

  • TALM(토폴로지 라이프사이클 관리자)을 설치합니다.
  • 하나 이상의 관리 클러스터를 프로비저닝합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

절차

  1. clustergroupupgrades-group-du.yaml 파일에서 preCaching 필드가 true 로 설정된 상태에서 ClusterGroupUpgrade CR의 콘텐츠를 저장합니다.

    apiVersion: ran.openshift.io/v1alpha1
    kind: ClusterGroupUpgrade
    metadata:
      name: du-upgrade-4918
      namespace: ztp-group-du-sno
    spec:
      preCaching: true 1
      clusters:
      - cnfdb1
      - cnfdb2
      enable: false
      managedPolicies:
      - du-upgrade-platform-upgrade
      remediationStrategy:
        maxConcurrency: 2
        timeout: 240
    1
    preCaching 필드는 업데이트를 시작하기 전에 TALM이 컨테이너 이미지를 가져올 수 있도록 true 로 설정됩니다.
  2. 업데이트를 시작하려면 다음 명령을 실행하여 ClusterGroupUpgrade CR을 적용합니다.

    $ oc apply -f clustergroupupgrades-group-du.yaml

검증

  1. 다음 명령을 실행하여 hub 클러스터에 ClusterGroupUpgrade CR이 있는지 확인합니다.

    $ oc get cgu -A

    출력 예

    NAMESPACE          NAME              AGE
    ztp-group-du-sno   du-upgrade-4918   10s 1

    1
    CR이 생성됩니다.
  2. 다음 명령을 실행하여 사전 캐싱 작업의 상태를 확인합니다.

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    출력 예

    {
      "conditions": [
        {
          "lastTransitionTime": "2022-01-27T19:07:24Z",
          "message": "Precaching is not completed (required)", 1
          "reason": "PrecachingRequired",
          "status": "False",
          "type": "Ready"
        },
        {
          "lastTransitionTime": "2022-01-27T19:07:24Z",
          "message": "Precaching is required and not done",
          "reason": "PrecachingNotDone",
          "status": "False",
          "type": "PrecachingDone"
        },
        {
          "lastTransitionTime": "2022-01-27T19:07:34Z",
          "message": "Pre-caching spec is valid and consistent",
          "reason": "PrecacheSpecIsWellFormed",
          "status": "True",
          "type": "PrecacheSpecValid"
        }
      ],
      "precaching": {
        "clusters": [
          "cnfdb1" 2
        ],
        "spec": {
          "platformImage": "image.example.io"},
        "status": {
          "cnfdb1": "Active"}
        }
    }

    1
    업데이트가 진행 중임을 나타냅니다.
    2
    확인된 클러스터 목록을 표시합니다.
  3. spoke 클러스터에서 다음 명령을 실행하여 사전 캐싱 작업의 상태를 확인합니다.

    $ oc get jobs,pods -n openshift-talm-pre-cache

    출력 예

    NAME                  COMPLETIONS   DURATION   AGE
    job.batch/pre-cache   0/1           3m10s      3m10s
    
    NAME                     READY   STATUS    RESTARTS   AGE
    pod/pre-cache--1-9bmlr   1/1     Running   0          3m10s

  4. 다음 명령을 실행하여 ClusterGroupUpgrade CR의 상태를 확인합니다.

    $ oc get cgu -n ztp-group-du-sno du-upgrade-4918 -o jsonpath='{.status}'

    출력 예

    "conditions": [
        {
          "lastTransitionTime": "2022-01-27T19:30:41Z",
          "message": "The ClusterGroupUpgrade CR has all clusters compliant with all the managed policies",
          "reason": "UpgradeCompleted",
          "status": "True",
          "type": "Ready"
        },
        {
          "lastTransitionTime": "2022-01-27T19:28:57Z",
          "message": "Precaching is completed",
          "reason": "PrecachingCompleted",
          "status": "True",
          "type": "PrecachingDone" 1
        }

    1
    사전 캐시 작업이 완료되었습니다.

16.8. 토폴로지 Aware Lifecycle Manager 문제 해결

TALM(토폴로지 라이프사이클 관리자)은 RHACM 정책을 수정하는 OpenShift Container Platform Operator입니다. 문제가 발생하면 oc adm must-gather 명령을 사용하여 세부 정보 및 로그를 수집하고 문제를 디버깅하는 단계를 수행하십시오.

관련 항목에 대한 자세한 내용은 다음 설명서를 참조하십시오.

16.8.1. 일반 문제 해결

다음 질문을 검토하여 문제의 원인을 확인할 수 있습니다.

ClusterGroupUpgrade 구성이 작동하는지 확인하려면 다음을 수행합니다.

  1. spec.enable 필드를 false 로 설정하여 ClusterGroupUpgrade CR을 생성합니다.
  2. 상태가 업데이트될 때까지 기다린 후 문제 해결 질문을 진행합니다.
  3. 모든 항목이 예상대로 표시되면 ClusterGroupUpgrade CR에서 spec.enable 필드를 true 로 설정합니다.
주의

ClusterUpgradeGroup CR에서 spec.enable 필드를 true 로 설정한 후 업데이트 절차가 시작되고 CR의 spec 필드를 더 이상 편집할 수 없습니다.

16.8.2. ClusterUpgradeGroup CR을 수정할 수 없음

문제
업데이트를 활성화한 후에는 ClusterUpgradeGroup CR을 편집할 수 없습니다.
해결

다음 단계를 수행하여 절차를 다시 시작하십시오.

  1. 다음 명령을 실행하여 이전 ClusterGroupUpgrade CR을 제거합니다.

    $ oc delete cgu -n <ClusterGroupUpgradeCR_namespace> <ClusterGroupUpgradeCR_name>
  2. 관리형 클러스터 및 정책의 기존 문제를 확인하고 수정합니다.

    1. 모든 클러스터가 관리되고 사용 가능한지 확인합니다.
    2. 모든 정책이 존재하고 spec.remediationAction 필드를 inform 로 설정해야 합니다.
  3. 올바른 구성을 사용하여 새 ClusterGroupUpgrade CR을 생성합니다.

    $ oc apply -f <ClusterGroupUpgradeCR_YAML>

16.8.3. 관리형 정책

시스템에서 관리되는 정책 확인

문제
시스템에 올바른 관리 정책이 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.managedPolicies}'

출력 예

["group-du-sno-validator-du-validator-policy", "policy2-common-pao-sub-policy", "policy3-common-ptp-sub-policy"]

수정 모드 확인

문제
관리 정책을 사양에 알리 도록 remediationAction 필드가 설정되어 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get policies --all-namespaces

출력 예

NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     policy1-common-cluster-version-policy                inform               NonCompliant       5d21h
default     policy2-common-pao-sub-policy                        inform               Compliant          5d21h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       5d21h
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       5d21h

정책 준수 상태 확인

문제
정책의 규정 준수 상태를 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get policies --all-namespaces

출력 예

NAMESPACE   NAME                                                 REMEDIATION ACTION   COMPLIANCE STATE   AGE
default     policy1-common-cluster-version-policy                inform               NonCompliant       5d21h
default     policy2-common-pao-sub-policy                        inform               Compliant          5d21h
default     policy3-common-ptp-sub-policy                        inform               NonCompliant       5d21h
default     policy4-common-sriov-sub-policy                      inform               NonCompliant       5d21h

16.8.4. 클러스터

관리형 클러스터가 있는지 확인
문제
ClusterGroupUpgrade CR의 클러스터가 관리 클러스터인지 확인해야 합니다.
해결

다음 명령을 실행합니다.

$ oc get managedclusters

출력 예

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                    JOINED   AVAILABLE   AGE
local-cluster   true           https://api.hub.example.com:6443        True     Unknown     13d
spoke1          true           https://api.spoke1.example.com:6443     True     True        13d
spoke3          true           https://api.spoke3.example.com:6443     True     True        27h

  1. 또는 TALM 관리자 로그를 확인합니다.

    1. 다음 명령을 실행하여 TALM 관리자의 이름을 가져옵니다.

      $ oc get pod -n openshift-operators

      출력 예

      NAME                                                         READY   STATUS    RESTARTS   AGE
      cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp   2/2     Running   0          45m

    2. 다음 명령을 실행하여 TALM 관리자 로그를 확인합니다.

      $ oc logs -n openshift-operators \
      cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

      출력 예

      ERROR	controller-runtime.manager.controller.clustergroupupgrade	Reconciler error	{"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1
      sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

      1
      오류 메시지는 클러스터가 관리 클러스터가 아님을 나타냅니다.
관리형 클러스터를 사용할 수 있는지 확인
문제
ClusterGroupUpgrade CR에 지정된 관리형 클러스터를 사용할 수 있는지 확인해야 합니다.
해결

다음 명령을 실행합니다.

$ oc get managedclusters

출력 예

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                    JOINED   AVAILABLE   AGE
local-cluster   true           https://api.hub.testlab.com:6443        True     Unknown     13d
spoke1          true           https://api.spoke1.testlab.com:6443     True     True        13d 1
spoke3          true           https://api.spoke3.testlab.com:6443     True     True        27h 2

1 2
AVAILABLE 필드의 값은 관리형 클러스터에 대해 True 입니다.
clusterSelector 확인
문제
clusterSelector 필드가 관리형 클러스터 중 하나 이상에서 ClusterGroupUpgrade CR에 지정되어 있는지 확인해야 합니다.
해결

다음 명령을 실행합니다.

$ oc get managedcluster --selector=upgrade=true 1
1
업데이트하려는 클러스터의 레이블은 upgrade:true 입니다.

출력 예

NAME            HUB ACCEPTED   MANAGED CLUSTER URLS                     JOINED    AVAILABLE   AGE
spoke1          true           https://api.spoke1.testlab.com:6443      True     True        13d
spoke3          true           https://api.spoke3.testlab.com:6443      True     True        27h

카나리아 클러스터가 있는지 확인
문제

카나리아 클러스터가 클러스터 목록에 있는지 확인하려고 합니다.

ClusterGroupUpgrade CR의 예

spec:
    clusters:
    - spoke1
    - spoke3
    clusterSelector:
    - upgrade2=true
    remediationStrategy:
        canaries:
        - spoke3
        maxConcurrency: 2
        timeout: 240

해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.clusters}'

출력 예

["spoke1", "spoke3"]

  1. 다음 명령을 실행하여 clusterSelector 라벨과 일치하는 클러스터 목록에 카나리아 클러스터가 있는지 확인합니다.

    $ oc get managedcluster --selector=upgrade=true

    출력 예

    NAME            HUB ACCEPTED   MANAGED CLUSTER URLS   JOINED    AVAILABLE   AGE
    spoke1          true           https://api.spoke1.testlab.com:6443   True     True        13d
    spoke3          true           https://api.spoke3.testlab.com:6443   True     True        27h

참고

클러스터는 spec.clusters 에 존재할 수 있으며 spec.clusterSelecter 레이블과도 일치할 수 있습니다.

스포크 클러스터에서 사전 캐싱 상태 확인
  1. spoke 클러스터에서 다음 명령을 실행하여 사전 캐싱의 상태를 확인합니다.

    $ oc get jobs,pods -n openshift-talo-pre-cache

16.8.5. 수정 전략

ClusterGroupUpgrade CR에 remediationStrategy가 있는지 확인
문제
remediationStrategyClusterGroupUpgrade CR에 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy}'

출력 예

{"maxConcurrency":2, "timeout":240}

ClusterGroupUpgrade CR에 maxConcurrency가 지정되어 있는지 확인
문제
maxConcurrencyClusterGroupUpgrade CR에 지정되어 있는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.spec.remediationStrategy.maxConcurrency}'

출력 예

2

16.8.6. 토폴로지 인식 라이프 사이클 관리자

ClusterGroupUpgrade CR에서 조건 메시지 및 상태 확인
문제
ClusterGroupUpgrade CR에서 status.conditions 필드의 값을 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.status.conditions}'

출력 예

{"lastTransitionTime":"2022-02-17T22:25:28Z", "message":"The ClusterGroupUpgrade CR has managed policies that are missing:[policyThatDoesntExist]", "reason":"UpgradeCannotStart", "status":"False", "type":"Ready"}

해당 복사 정책 확인
문제
status.managedPoliciesForUpgrade 의 모든 정책이 status.copiedPolicies.copiedPolicies에 해당 정책이 있는지 확인하려면 다음을 수행하십시오.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -oyaml

출력 예

status:
  …
  copiedPolicies:
  - lab-upgrade-policy3-common-ptp-sub-policy
  managedPoliciesForUpgrade:
  - name: policy3-common-ptp-sub-policy
    namespace: default

status.remediationPlan이 계산되었는지 확인
문제
status.remediationPlan 이 계산되었는지 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc get cgu lab-upgrade -ojsonpath='{.status.remediationPlan}'

출력 예

[["spoke2", "spoke3"]]

TALM 관리자 컨테이너의 오류
문제
TALM의 manager 컨테이너의 로그를 확인하려고 합니다.
해결

다음 명령을 실행합니다.

$ oc logs -n openshift-operators \
cluster-group-upgrades-controller-manager-75bcc7484d-8k8xp -c manager

출력 예

ERROR	controller-runtime.manager.controller.clustergroupupgrade	Reconciler error	{"reconciler group": "ran.openshift.io", "reconciler kind": "ClusterGroupUpgrade", "name": "lab-upgrade", "namespace": "default", "error": "Cluster spoke5555 is not a ManagedCluster"} 1
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem

1
오류를 표시합니다.

추가 리소스

17장. 성능 프로파일 작성

Performance Profile Creator(PPC)와 이를 사용하여 성능 프로필을 만드는 방법을 설명합니다.

17.1. 성능 프로파일 작성툴 정보

PPC(Performance Profile creator)는 성능 프로필을 생성하는 데 사용되는 Performance Addon Operator와 함께 제공되는 명령행 툴입니다. 이 툴은 클러스터의 must-gather 데이터와 여러 사용자가 제공하는 프로필 인수를 사용합니다. PPC는 하드웨어 및 토폴로지에 적합한 성능 프로필을 생성합니다.

툴은 다음 방법 중 하나로 실행됩니다.

  • podman 호출
  • 래퍼 스크립트 호출

17.1.1. must-gather 명령을 사용하여 클러스터에 대한 데이터 수집

PPC(Performance Profile creator) 툴에는 must-gather 데이터가 필요합니다. 클러스터 관리자는 must-gather 명령을 실행하여 클러스터에 대한 정보를 캡처합니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • Performance Addon Operator 이미지에 액세스합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

절차

  1. 선택 사항: 레이블과 일치하는 머신 구성 풀이 있는지 확인합니다.

    $ oc describe mcp/worker-rt

    출력 예

    Name:         worker-rt
    Namespace:
    Labels:       machineconfiguration.openshift.io/role=worker-rt

  2. 일치하는 라벨이 없는 경우 MCP 이름과 일치하는 MCP(Machine config pool)의 라벨을 추가합니다.

    $ oc label mcp <mcp_name> <mcp_name>=""
  3. must-gather 데이터를 저장하려는 디렉터리로 이동합니다.
  4. 클러스터에서 must-gather를 실행합니다.

    $ oc adm must-gather --image=<PAO_image> --dest-dir=<dir>
    참고

    must-gather 명령은 performance-addon-operator-must-gather 이미지를 사용하여 실행해야 합니다. 출력을 선택적으로 압축할 수 있습니다. Performance Profile Creator 래퍼 스크립트를 실행하는 경우 압축 출력이 필요합니다.

    예제

    $ oc adm must-gather --image=registry.redhat.io/openshift4/performance-addon-operator-must-gather-rhel8:v4.10 --dest-dir=must-gather

  5. must-gather 디렉터리에서 압축 파일을 만듭니다.

    $ tar cvaf must-gather.tar.gz must-gather/

17.1.2. podman을 사용하여 Performance Profile Creator 실행

클러스터 관리자는 podman 및 Performance Profile Creator를 실행하여 성능 프로필을 만들 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 클러스터가 베어 메탈 하드웨어에 설치되어 있어야 합니다.
  • podman 및 OpenShift CLI(oc)가 설치된 노드가 있습니다.

절차

  1. 머신 구성 풀을 확인합니다.

    $ oc get mcp

    출력 예

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
    worker-cnf   rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826   False     True       False      2              1                   1                     0                      22h

  2. Podman을 사용하여 registry.redhat.io 에 인증합니다.

    $ podman login registry.redhat.io
    Username: <username>
    Password: <password>
  3. 선택 사항: PPC 툴에 대한 도움말을 표시합니다.

    $ podman run --entrypoint performance-profile-creator registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 -h

    출력 예

    A tool that automates creation of Performance Profiles
    
    Usage:
      performance-profile-creator [flags]
    
    Flags:
          --disable-ht                        Disable Hyperthreading
      -h, --help                              help for performance-profile-creator
          --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
          --mcp-name string                   MCP name corresponding to the target machines (required)
          --must-gather-dir-path string       Must gather directory path (default "must-gather")
          --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
          --profile-name string               Name of the performance profile to be created (default "performance")
          --reserved-cpu-count int            Number of reserved CPUs (required)
          --rt-kernel                         Enable Real Time Kernel (required)
          --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
          --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
          --user-level-networking             Run with User level Networking(DPDK) enabled

  4. 검색 모드에서 Performance Profile Creator 툴을 실행합니다.

    참고

    검색 모드는 must-gather의 출력을 사용하여 클러스터를 검사합니다. 생성된 출력에는 다음에 대한 정보가 포함됩니다.

    • 할당된 CPU ID로 NUMA 셀 파티셔닝
    • 하이퍼스레딩 활성화 여부

    이 정보를 사용하여 Performance Profile Creator 툴에 제공된 일부 인수에 대해 적절한 값을 설정할 수 있습니다.

    $ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 --info log --must-gather-dir-path /must-gather
    참고

    이 명령은 Performance Profile Creator 툴을 podman의 새 진입점으로 사용합니다. 호스트의 must-gather 데이터를 컨테이너 이미지에 매핑하고 필요한 사용자 제공 프로필 인수를 호출하여 my-performance-profile.yaml 파일을 생성합니다.

    -v 옵션은 다음 중 하나로 설정할 수 있습니다.

    • must-gather 출력 디렉터리
    • must-gather 압축 해제된 tarball이 포함된 기존 디렉터리

    info 옵션에는 출력 형식을 지정하는 값이 필요합니다. 가능한 값은 log 및 JSON입니다. JSON 형식은 디버깅을 위해 예약되어 있습니다.

  5. podman을 실행합니다.

    $ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=false --topology-manager-policy=single-numa-node --must-gather-dir-path /must-gather  --power-consumption-mode=ultra-low-latency > my-performance-profile.yaml
    참고

    Performance Profile Creator 인수는 Performance Profile Creator 인수 테이블에 표시됩니다. 다음 인수가 필요합니다.

    • reserved-cpu-count
    • mcp-name
    • rt-kernel

    이 예제의 mcp-name 인수는 oc get mcp 명령의 출력에 따라 worker-cnf로 설정됩니다. single-node OpenShift의 경우 --mcp-name=master 를 사용합니다.

  6. 생성된 YAML 파일을 검토합니다.

    $ cat my-performance-profile.yaml

    출력 예

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      additionalKernelArgs:
      - nmi_watchdog=0
      - audit=0
      - mce=off
      - processor.max_cstate=1
      - intel_idle.max_cstate=0
      - idle=poll
      cpu:
        isolated: 1,3,5,7,9,11,13,15,17,19-39,41,43,45,47,49,51,53,55,57,59-79
        reserved: 0,2,4,6,8,10,12,14,16,18,40,42,44,46,48,50,52,54,56,58
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numa:
        topologyPolicy: single-numa-node
      realTimeKernel:
        enabled: true

  7. 생성된 프로필을 적용합니다.

    참고

    프로필을 적용하기 전에 Performance Addon Operator를 설치합니다.

    $ oc apply -f my-performance-profile.yaml

17.1.2.1. podman을 실행하여 성능 프로파일을 만드는 방법

다음 예제에서는 podman을 실행하여 NUMA 노드 간에 분할될 예약된 20개의 CPU가 있는 성능 프로필을 생성하는 방법을 보여줍니다.

노드 하드웨어 구성:

  • 80 CPU
  • 하이퍼 스레딩 활성화
  • 두 개의 NUMA 노드
  • 짝수 번호의 CPU는 NUMA 노드 0에서 실행되고 홀수 번호의 CPU는 NUMA 노드 1에서 실행

podman을 실행하여 성능 프로필을 생성합니다.

$ podman run --entrypoint performance-profile-creator -v /must-gather:/must-gather:z registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10 --mcp-name=worker-cnf --reserved-cpu-count=20 --rt-kernel=true --split-reserved-cpus-across-numa=true --must-gather-dir-path /must-gather > my-performance-profile.yaml

생성된 프로필은 다음 YAML에 설명되어 있습니다.

  apiVersion: performance.openshift.io/v2
  kind: PerformanceProfile
  metadata:
    name: performance
  spec:
    cpu:
      isolated: 10-39,50-79
      reserved: 0-9,40-49
    nodeSelector:
      node-role.kubernetes.io/worker-cnf: ""
    numa:
      topologyPolicy: restricted
    realTimeKernel:
      enabled: true
참고

이 경우 NUMA 노드 0에 CPU 10개가 예약되고 NUMA 노드 1에 CPU 10개가 예약됩니다.

17.1.3. Performance Profile Creator 래퍼 스크립트 실행

성능 프로필 래퍼 스크립트는 PPC(Performance Profile Creator) 툴의 실행을 간소화합니다. podman 실행과 관련된 복잡성을 숨기고 매핑 디렉터리를 지정하면 성능 프로필을 만들 수 있습니다.

사전 요구 사항

  • Performance Addon Operator 이미지에 액세스합니다.
  • must-gather tarball에 액세스합니다.

절차

  1. 예를 들어 다음과 같이 run-perf-profile-creator.sh라는 이름의 파일을 로컬 시스템에 생성합니다

    $ vi run-perf-profile-creator.sh
  2. 다음 코드를 파일에 붙여넣습니다.

    #!/bin/bash
    
    readonly CONTAINER_RUNTIME=${CONTAINER_RUNTIME:-podman}
    readonly CURRENT_SCRIPT=$(basename "$0")
    readonly CMD="${CONTAINER_RUNTIME} run --entrypoint performance-profile-creator"
    readonly IMG_EXISTS_CMD="${CONTAINER_RUNTIME} image exists"
    readonly IMG_PULL_CMD="${CONTAINER_RUNTIME} image pull"
    readonly MUST_GATHER_VOL="/must-gather"
    
    PAO_IMG="registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10"
    MG_TARBALL=""
    DATA_DIR=""
    
    usage() {
      print "Wrapper usage:"
      print "  ${CURRENT_SCRIPT} [-h] [-p image][-t path] -- [performance-profile-creator flags]"
      print ""
      print "Options:"
      print "   -h                 help for ${CURRENT_SCRIPT}"
      print "   -p                 Performance Addon Operator image"
      print "   -t                 path to a must-gather tarball"
    
      ${IMG_EXISTS_CMD} "${PAO_IMG}" && ${CMD} "${PAO_IMG}" -h
    }
    
    function cleanup {
      [ -d "${DATA_DIR}" ] && rm -rf "${DATA_DIR}"
    }
    trap cleanup EXIT
    
    exit_error() {
      print "error: $*"
      usage
      exit 1
    }
    
    print() {
      echo  "$*" >&2
    }
    
    check_requirements() {
      ${IMG_EXISTS_CMD} "${PAO_IMG}" || ${IMG_PULL_CMD} "${PAO_IMG}" || \
          exit_error "Performance Addon Operator image not found"
    
      [ -n "${MG_TARBALL}" ] || exit_error "Must-gather tarball file path is mandatory"
      [ -f "${MG_TARBALL}" ] || exit_error "Must-gather tarball file not found"
    
      DATA_DIR=$(mktemp -d -t "${CURRENT_SCRIPT}XXXX") || exit_error "Cannot create the data directory"
      tar -zxf "${MG_TARBALL}" --directory "${DATA_DIR}" || exit_error "Cannot decompress the must-gather tarball"
      chmod a+rx "${DATA_DIR}"
    
      return 0
    }
    
    main() {
      while getopts ':hp:t:' OPT; do
        case "${OPT}" in
          h)
            usage
            exit 0
            ;;
          p)
            PAO_IMG="${OPTARG}"
            ;;
          t)
            MG_TARBALL="${OPTARG}"
            ;;
          ?)
            exit_error "invalid argument: ${OPTARG}"
            ;;
        esac
      done
      shift $((OPTIND - 1))
    
      check_requirements || exit 1
    
      ${CMD} -v "${DATA_DIR}:${MUST_GATHER_VOL}:z" "${PAO_IMG}" "$@" --must-gather-dir-path "${MUST_GATHER_VOL}"
      echo "" 1>&2
    }
    
    main "$@"
  3. 이 스크립트에 모든 사용자에 대한 실행 권한을 추가합니다.

    $ chmod a+x run-perf-profile-creator.sh
  4. 선택 사항: run-perf-profile-creator.sh 명령 사용을 표시합니다.

    $ ./run-perf-profile-creator.sh -h

    예상 출력

    Wrapper usage:
      run-perf-profile-creator.sh [-h] [-p image][-t path] -- [performance-profile-creator flags]
    
    Options:
       -h                 help for run-perf-profile-creator.sh
       -p                 Performance Addon Operator image 1
       -t                 path to a must-gather tarball 2
    
    A tool that automates creation of Performance Profiles
    
       Usage:
         performance-profile-creator [flags]
    
       Flags:
             --disable-ht                        Disable Hyperthreading
         -h, --help                              help for performance-profile-creator
             --info string                       Show cluster information; requires --must-gather-dir-path, ignore the other arguments. [Valid values: log, json] (default "log")
             --mcp-name string                   MCP name corresponding to the target machines (required)
             --must-gather-dir-path string       Must gather directory path (default "must-gather")
             --power-consumption-mode string     The power consumption mode.  [Valid values: default, low-latency, ultra-low-latency] (default "default")
             --profile-name string               Name of the performance profile to be created (default "performance")
             --reserved-cpu-count int            Number of reserved CPUs (required)
             --rt-kernel                         Enable Real Time Kernel (required)
             --split-reserved-cpus-across-numa   Split the Reserved CPUs across NUMA nodes
             --topology-manager-policy string    Kubelet Topology Manager Policy of the performance profile to be created. [Valid values: single-numa-node, best-effort, restricted] (default "restricted")
             --user-level-networking             Run with User level Networking(DPDK) enabled

    참고

    두 가지 유형의 인수가 있습니다.

    • 래퍼 인수 즉 -h,-p-t
    • PPC 인수
    1
    선택 사항: Performance Addon Operator 이미지를 지정합니다. 설정되지 않은 경우 기본 업스트림 이미지가 사용됩니다. registry.redhat.io/openshift4/performance-addon-rhel8-operator:v4.10.
    2
    -t는 필수 래퍼 스크립트 인수이며 must-gather tarball의 경로를 지정합니다.
  5. 검색 모드에서 performance profile creator 툴을 실행합니다.

    참고

    검색 모드는 must-gather의 출력을 사용하여 클러스터를 검사합니다. 생성된 출력에는 다음에 대한 정보가 포함됩니다.

    • 할당된 CPU ID로 NUMA 셀 파티션을 분할
    • 하이퍼스레딩 활성화 여부

    이 정보를 사용하여 Performance Profile Creator 툴에 제공된 일부 인수에 대해 적절한 값을 설정할 수 있습니다.

    $ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --info=log
    참고

    info 옵션에는 출력 형식을 지정하는 값이 필요합니다. 가능한 값은 log 및 JSON입니다. JSON 형식은 디버깅을 위해 예약되어 있습니다.

  6. 머신 구성 풀을 확인합니다.

    $ oc get mcp

    출력 예

    NAME         CONFIG                                                 UPDATED   UPDATING   DEGRADED   MACHINECOUNT   READYMACHINECOUNT   UPDATEDMACHINECOUNT   DEGRADEDMACHINECOUNT   AGE
    master       rendered-master-acd1358917e9f98cbdb599aea622d78b       True      False      False      3              3                   3                     0                      22h
    worker-cnf   rendered-worker-cnf-1d871ac76e1951d32b2fe92369879826   False     True       False      2              1                   1                     0                      22h

  7. 성능 프로파일을 생성합니다.

    $ ./run-perf-profile-creator.sh -t /must-gather/must-gather.tar.gz -- --mcp-name=worker-cnf --reserved-cpu-count=2 --rt-kernel=true > my-performance-profile.yaml
    참고

    Performance Profile Creator 인수는 Performance Profile Creator 인수 테이블에 표시됩니다. 다음 인수가 필요합니다.

    • reserved-cpu-count
    • mcp-name
    • rt-kernel

    이 예제의 mcp-name 인수는 oc get mcp 명령의 출력에 따라 worker-cnf로 설정됩니다. single-node OpenShift의 경우 --mcp-name=master 를 사용합니다.

  8. 생성된 YAML 파일을 검토합니다.

    $ cat my-performance-profile.yaml

    출력 예

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: performance
    spec:
      cpu:
        isolated: 1-39,41-79
        reserved: 0,40
      nodeSelector:
        node-role.kubernetes.io/worker-cnf: ""
      numa:
        topologyPolicy: restricted
      realTimeKernel:
        enabled: false

  9. 생성된 프로필을 적용합니다.

    참고

    프로필을 적용하기 전에 Performance Addon Operator를 설치합니다.

    $ oc apply -f my-performance-profile.yaml

17.1.4. Performance Profile Creator 인수

표 17.1. Performance Profile Creator 인수

인수설명

disable-ht

하이퍼스레딩을 비활성화합니다.

가능한 값: true 또는 false.

기본값: false

주의

이 인수가 true로 설정된 경우 BIOS에서 하이퍼 스레딩을 비활성화해서는 안 됩니다. 하이퍼 스레딩 비활성화는 커널 명령줄 인수를 사용하여 수행됩니다.

info

이는 클러스터 정보를 캡처하며 검색 모드에서만 사용됩니다. 검색 모드에서는 must-gather-dir-path 인수도 필요합니다. 다른 인수가 설정되면 무시됩니다.

가능한 값은 다음과 같습니다.

  • log
  • JSON

    참고

    이러한 옵션은 디버깅을 위해 예약되는 JSON 형식을 사용하여 출력 형식을 정의합니다.

기본값: log.

mcp-name

대상 머신에 해당하는 MCP 이름 (예:worker-cnf)입니다. 이 매개 변수는 필수입니다.

must-gather-dir-path

디렉터리 경로를 수집해야 합니다. 이 매개 변수는 필수입니다.

사용자가 래퍼 스크립트 must-gather로 툴을 실행하는 경우 스크립트 자체에서 제공되고 사용자는 이를 지정해서는 안 됩니다.

power-consumption-mode

전력 소비 모드입니다.

가능한 값은 다음과 같습니다.

  • default
  • low-latency
  • ultra-low-latency

기본값: default.

profile-name

생성할 성능 프로파일의 이름입니다. 기본값: performance.

reserved-cpu-count

예약된 CPU 수입니다. 이 매개 변수는 필수입니다.

참고

이것은 자연수여야 합니다. 0 값은 허용되지 않습니다.

rt-kernel

실시간 커널을 활성화합니다. 이 매개 변수는 필수입니다.

가능한 값: true 또는 false.

split-reserved-cpus-across-numa

NUMA 노드에서 예약된 CPU를 분할합니다.

가능한 값: true 또는 false.

기본값: false

topology-manager-policy

생성할 성능 프로필의 Kubelet Topology Manager 정책입니다.

가능한 값은 다음과 같습니다.

  • single-numa-node
  • best-effort
  • restricted

기본값: restricted.

user-level-networking

DPDK(사용자 수준 네트워킹)가 활성화된 상태에서 실행합니다.

가능한 값: true 또는 false.

기본값: false

17.2. 추가 리소스

18장. 단일 노드 OpenShift에서 워크로드 파티셔닝

단일 노드 OpenShift 배포와 같이 리소스가 제한적인 환경에서는 대부분의 CPU 리소스를 자체 워크로드에 예약하고 OpenShift Container Platform을 구성하여 호스트 내의 고정된 수에서 실행되도록 하는 것이 좋습니다. 이러한 환경에서는 컨트롤 플레인을 포함한 관리 워크로드를 일반 클러스터에서 기본적으로 사용할 수 있는 것보다 적은 리소스를 사용하도록 구성해야 합니다. 예약된 CPU 세트에서 실행할 OpenShift Container Platform 서비스, 클러스터 관리 워크로드 및 인프라 Pod를 분리할 수 있습니다.

워크로드 파티션을 사용하면 OpenShift Container Platform에서 클러스터 관리를 위해 사용하는 CPU 리소스가 단일 노드 클러스터에서 분할된 CPU 리소스 세트로 격리됩니다. 이 파티션은 클러스터 관리 기능을 정의된 수의 CPU로 격리합니다. 모든 클러스터 관리 기능은 해당 cpuset 구성에서만 작동합니다.

단일 노드 클러스터의 관리 파티션에 필요한 최소 예약된 CPU 수는 4개의 CPU Hyper 스레드(HT)입니다. 기본 OpenShift Container Platform 설치와 일반적인 애드온 Operator 세트를 구성하는 Pod 세트에는 관리 워크로드 파티션에 포함하기 위해 주석이 추가됩니다. 이러한 Pod는 최소 크기 cpuset 구성 내에서 정상적으로 작동합니다. 허용되는 관리 Pod 세트 외부에 Operator 또는 워크로드를 포함하려면 추가 CPU HT를 해당 파티션에 추가해야 합니다.

워크로드 파티셔닝은 Kubernetes의 일반 스케줄링 기능을 사용하여 플랫폼 워크로드에서 사용자 워크로드를 분리하여 해당 코어에 배치할 수 있는 Pod 수를 관리하고 클러스터 관리 워크로드와 사용자 워크로드를 혼합하지 않도록 합니다.

워크로드 파티셔닝을 사용하는 경우 Performance Addon Operator를 설치하고 성능 프로필을 적용해야 합니다.

  • 워크로드 파티셔닝은 OpenShift Container Platform 인프라 Pod를 정의된 cpuset 구성에 고정합니다.
  • Performance Addon Operator 성능 프로필은 systemd 서비스를 정의된 cpuset 구성에 고정합니다.
  • cpuset 구성이 일치해야 합니다.

워크로드 분할에는 < workload-type>.workload.openshift.io/cores 가 정의된 각 CPU 풀 또는 workload-type의 새로운 확장 리소스가 도입되었습니다. kubelet은 풀에 할당된 Pod에서 이러한 새 리소스 및 CPU 요청을 알리는 것은 일반적인 cpu 리소스 대신 해당 리소스 내에서 고려됩니다. 워크로드 분할이 활성화되면 < workload-type>.workload.openshift.io/cores 리소스를 사용하면 기본 CPU 풀이 아닌 호스트의 CPU 용량에 액세스할 수 있습니다.

18.1. 워크로드 파티셔닝을 사용하여 CPU 할당 극대화

단일 노드 OpenShift 클러스터 설치 중에 워크로드 파티셔닝을 활성화해야 합니다. 이렇게 하면 플랫폼 서비스를 실행할 수 있는 코어가 제한되어 애플리케이션 페이로드에 대한 CPU 코어를 최대화합니다.

참고

클러스터 설치 중에만 워크로드 파티셔닝을 활성화할 수 있습니다. 설치 후 워크로드 파티셔닝을 비활성화할 수 없습니다. 그러나 성능 프로필에 정의된 cpu 값과 MachineConfig 사용자 정의 리소스(CR)의 관련 cpuset 값에 업데이트하여 워크로드 파티션을 재구성할 수 있습니다.

  • 워크로드 파티셔닝을 가능하게 하는 base64로 인코딩된 CR에는 관리 워크로드가 제한된 CPU 세트가 포함됩니다. crio.confkubelet.conf 의 호스트별 값을 base64로 인코딩합니다. 이 콘텐츠는 클러스터 성능 프로필에 지정된 CPU 세트와 일치하도록 조정해야 하며 클러스터 호스트의 코어 수에 대해 정확해야 합니다.

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 02-master-workload-partitioning
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMSw1Mi01MyIgfQo=
            mode: 420
            overwrite: true
            path: /etc/crio/crio.conf.d/01-workload-partitioning
            user:
              name: root
          - contents:
              source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTEsNTItNTMiCiAgfQp9Cg==
            mode: 420
            overwrite: true
            path: /etc/kubernetes/openshift-workload-pinning
            user:
              name: root
  • 클러스터 호스트에 구성하면 /etc/crio/crio.conf.d/01-workload-partitioning 의 내용은 다음과 같아야 합니다.

    [crio.runtime.workloads.management]
    activation_annotation = "target.workload.openshift.io/management"
    annotation_prefix = "resources.workload.openshift.io"
    [crio.runtime.workloads.management.resources]
    cpushares = 0
    cpuset = "0-1, 52-53" 1
    1
    cpuset 값은 설치에 따라 다릅니다.

    Hyper-Threading이 활성화된 경우 각 코어에 대해 두 스레드를 모두 지정합니다. cpuset 값은 성능 프로필의 spec.cpu.reserved 필드에 정의된 예약된 CPU와 일치해야 합니다.

  • 클러스터에서 구성하면 /etc/kubernetes/openshift-workload-pinning 의 내용은 다음과 같아야 합니다.

    {
      "management": {
        "cpuset": "0-1,52-53" 1
      }
    }
    1
    cpuset/etc/crio/crio.conf.d/01-workload-partitioningcpuset 값과 일치해야 합니다.

19장. 네트워크 엣지의 클러스터

19.1. 네트워크 엣지의 문제

엣지 컴퓨팅은 지리적으로 교체된 위치에서 많은 사이트를 관리할 때 복잡한 문제를 초래합니다. zero touch provisioning (ZTP) 및 GitOps를 사용하여 네트워크의 맨 에지에서 사이트를 프로비저닝하고 관리합니다.

19.1.1. 네트워크 엣지의 문제 해결

현재 서비스 제공업체는 네트워크 엣지에 인프라를 배포하려고 합니다. 여기에는 중요한 문제가 있습니다.

  • 여러 엣지 사이트의 배포를 병렬로 처리하려면 어떻게 해야 합니까?
  • 연결이 끊긴 환경에서 사이트를 배포해야 하는 경우 어떻게 됩니까?
  • 대규모 클러스터의 라이프사이클을 어떻게 관리합니까?

zero touch provisioning (ZTP) 및 GitOps 는 베어 메탈 장치에 대한 선언적 사이트 정의 및 구성으로 규모에 따라 원격 에지 사이트를 프로비저닝할 수 있으므로 이러한 문제를 해결합니다. 템플릿 또는 오버레이 구성은 CNF 워크로드에 필요한 OpenShift Container Platform 기능을 설치합니다. 설치 및 업그레이드의 전체 라이프사이클은 ZTP 파이프라인을 통해 처리됩니다.

ZTP는 인프라 배포에 GitOps를 사용합니다. GitOps에서는 Git 리포지토리에 저장된 선언적 YAML 파일 및 기타 정의된 패턴을 사용합니다. RHACM(Red Hat Advanced Cluster Management)은 Git 리포지토리를 사용하여 인프라 배포를 구동합니다.

GitOps는 추적 기능, RBAC(역할 기반 액세스 제어) 및 각 사이트의 원하는 상태에 대해 단일 정보 소스를 제공합니다. 확장성 문제는 웹 후크를 통해 Git 수행 및 이벤트 기반 작업에 의해 해결됩니다.

ZTP 파이프라인이 에지 노드에 제공하는 선언적 사이트 정의 및 구성 CR(사용자 정의 리소스)을 생성하여 ZTP 워크플로를 시작합니다.

다음 다이어그램은 멀리 있는 에지 프레임워크에서 ZTP가 작동하는 방식을 보여줍니다.

네트워크에서의 ZTP

19.1.2. ZTP를 사용하여 네트워크 에지에서 클러스터 프로비저닝

RHACM(Red Hat Advanced Cluster Management)은 단일 허브 클러스터가 많은 스포크 클러스터를 관리하는 허브 및 스포크 아키텍처의 클러스터를 관리합니다. RHACM 프로비저닝을 실행하는 Hub 클러스터와 RHACM을 설치할 때 배포된 지원 서비스를 사용하여 관리 클러스터를 배포합니다.

지원 서비스는 단일 노드 클러스터, 3 노드 클러스터 또는 베어 메탈에서 실행되는 표준 클러스터에서 OpenShift Container Platform 프로비저닝을 처리합니다.

OpenShift Container Platform에서 베어 메탈 호스트를 프로비저닝하고 유지하기 위해 ZTP를 사용하는 고급 개요는 다음과 같습니다.

  • RHACM을 실행하는 허브 클러스터는 OpenShift Container Platform 릴리스 이미지를 미러링하는 OpenShift 이미지 레지스트리를 관리합니다. RHACM은 OpenShift 이미지 레지스트리를 사용하여 관리 클러스터를 프로비저닝합니다.
  • Git 리포지토리에 버전이 지정된 YAML 형식 인벤토리 파일에서 베어 메탈 호스트를 관리합니다.
  • 호스트를 관리형 클러스터로 프로비저닝할 준비가 되어 있고 RHACM 및 지원 서비스를 사용하여 사이트에 베어 메탈 호스트를 설치할 수 있습니다.

클러스터 설치 및 배포는 초기 설치 단계 및 후속 구성 단계를 포함하는 2단계 프로세스입니다. 다음 다이어그램은 이 워크플로를 보여줍니다.

GitOps 및 ZTP를 사용하여 관리형 클러스터 설치 및 배포

19.1.3. siteConfig 리소스 및 RHACM을 사용하여 관리형 클러스터 설치

GitOps ZTP는 Git 리포지토리에서 siteConfig CR(사용자 정의 리소스)을 사용하여 OpenShift Container Platform 클러스터를 설치하는 프로세스를 관리합니다. site Config CR에는 설치에 필요한 클러스터별 매개변수가 포함되어 있습니다. 사용자 정의 추가 매니페스트를 포함하여 설치 중에 선택한 구성 CR을 적용하는 옵션이 있습니다.

ZTP GitOps 플러그인 은 siteConfig CR을 처리하여 hub 클러스터에서 CR 컬렉션을 생성합니다. 이로 인해 RHACM(Red Hat Advanced Cluster Management)의 지원 서비스가 트리거되어 베어 메탈 호스트에 OpenShift Container Platform을 설치합니다. hub 클러스터의 이러한 CR에서 설치 상태 및 오류 메시지를 확인할 수 있습니다.

ZTP를 사용하여 수동으로 또는 배치로 단일 클러스터를 프로비저닝할 수 있습니다.

단일 클러스터 프로비저닝
클러스터에 대한 단일 SiteConfig CR 및 관련 설치 및 구성 CR을 생성하고 이를 hub 클러스터에 적용하여 클러스터 프로비저닝을 시작합니다. 이는 더 큰 규모에 배포하기 전에 CR을 테스트하는 좋은 방법입니다.
여러 클러스터 프로비저닝
Git 리포지토리에서 site Config 및 관련 CR을 정의 하여 최대 400개로 관리되는 클러스터를 설치합니다. ArgoCD는 site Config CR을 사용하여 사이트를 배포합니다. RHACM 정책 생성기는 매니페스트를 생성하여 hub 클러스터에 적용합니다. 이렇게 하면 클러스터 프로비저닝 프로세스가 시작됩니다.

19.1.4. 정책 및 PolicyGenTemplate 리소스를 사용하여 관리형 클러스터 구성

zero touch provisioning (ZTP)은 Red Hat Advanced Cluster Management (RHACM)를 사용하여 구성 적용에 정책 기반 거버넌스 접근 방식을 사용하여 클러스터를 구성합니다.

정책 생성기 또는 PolicyGen 은 간결한 템플릿에서 RHACM 정책을 생성할 수 있는 GitOps Operator의 플러그인입니다. 이 툴은 여러 CR을 단일 정책으로 결합할 수 있으며, 함대에 있는 클러스터의 다양한 하위 집합에 적용되는 여러 정책을 생성할 수 있습니다.

참고

확장성 및 클러스터 전체에서 구성 관리의 복잡성을 줄이기 위해 가능한 한 공통성으로 구성 CR을 사용하십시오.

  • 가능한 경우 전체 공통 정책을 사용하여 구성 CR을 적용합니다.
  • 다음 기본 설정은 그룹 정책에서 가능한 한 많은 나머지 구성을 관리할 클러스터의 논리 그룹을 생성하는 것입니다.
  • 구성이 개별 사이트에 고유한 경우 hub 클러스터에서 RHACM 템플릿 정보를 사용하여 사이트별 데이터를 공통 또는 그룹 정책에 삽입합니다. 또는 사이트에 개별 사이트 정책을 적용합니다.

다음 다이어그램에서는 클러스터 배포의 구성 단계에서 정책 생성기가 GitOps 및 RHACM과 상호 작용하는 방법을 보여줍니다.

정책 생성기

대규모 클러스터의 경우 일반적으로 클러스터 구성에 높은 수준의 일관성이 있어야 합니다.

다음 권장 정책 구조는 구성 CR을 결합하여 몇 가지 목표를 달성합니다.

  • 공통 구성을 한 번 설명하고 함대에 적용합니다.
  • 유지 관리 및 관리되는 정책의 수를 최소화합니다.
  • 클러스터 변형을 위한 공통 구성의 유연성을 지원합니다.

표 19.1. 권장 PolicyGenTemplate 정책 카테고리

정책 카테고리설명

common

공통 카테고리에 존재하는 정책은 함의 모든 클러스터에 적용됩니다. Common PolicyGenTemplate CR을 사용하여 모든 클러스터 유형에 공통 설치 설정을 적용합니다.

그룹

그룹 카테고리에 존재하는 정책이 함의 클러스터 그룹에 적용됩니다. 그룹 PolicyGenTemplate CR을 사용하여 단일 노드, 3 노드 및 표준 클러스터 설치의 특정 측면을 관리합니다. 클러스터 그룹은 지리적 리전, 하드웨어 변형 등을 따를 수도 있습니다.

사이트

sites 카테고리에 존재하는 정책은 특정 클러스터 사이트에 적용됩니다. 모든 클러스터는 자체 특정 정책을 유지할 수 있습니다.

추가 리소스

  • ztp-site-generate 컨테이너 이미지에서 참조 site ConfigPolicyGenTemplate CR을 추출하는 방법에 대한 자세한 내용은 ZTP Git 리포지토리 준비를 참조하십시오.

19.2. ZTP용 hub 클러스터 준비

연결이 끊긴 환경에서 RHACM을 사용하려면 필요한 Operator 이미지가 포함된 OpenShift Container Platform 릴리스 이미지 및 OLM(Operator Lifecycle Manager) 카탈로그를 미러링하는 미러 레지스트리를 생성합니다. OLM은 Operator와 클러스터의 해당 종속성을 관리, 설치 및 업그레이드합니다. 연결이 끊긴 미러 호스트를 사용하여 베어 메탈 호스트를 프로비저닝하는 데 사용되는 RHCOS ISO 및 RootFS 디스크 이미지를 제공할 수도 있습니다.

19.2.1. telco RAN 4.10 검증 솔루션 소프트웨어 버전

Red Hat Telco radio Access Network (RAN) 버전 4.10 솔루션은 다음 Red Hat 소프트웨어 제품을 사용하여 검증되었습니다.

표 19.2. telco RAN 4.10 검증 솔루션 소프트웨어

제품소프트웨어 버전

Hub 클러스터 OpenShift Container Platform 버전

4.10

GitOps ZTP 플러그인

4.9 또는 4.10

Red Hat Advanced Cluster Management (RHACM)

2.4 또는 2.5

Red Hat OpenShift GitOps

1.4

토폴로지 Aware Lifecycle Manager (TALM)

4.10 (기술 프리뷰)

19.2.2. 연결이 끊긴 환경에서 GitOps ZTP 설치

연결이 끊긴 환경의 허브 클러스터에서 RHACM (RHACM), Red Hat OpenShift GitOps 및 Topology Aware Lifecycle Manager (TALM)를 사용하여 여러 관리 클러스터의 배포를 관리합니다.

사전 요구 사항

  • OpenShift Container Platform CLI(oc)를 설치했습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 클러스터에서 사용할 연결이 끊긴 미러 레지스트리를 구성했습니다.

    참고

    생성한 연결이 끊긴 미러 레지스트리에는 허브 클러스터에서 실행되는 TALM 버전과 일치하는 TALM 백업 버전 및 사전 캐시 이미지가 포함되어야 합니다. 스포크 클러스터는 연결이 끊긴 미러 레지스트리에서 이러한 이미지를 해결할 수 있어야 합니다.

절차

19.2.3. 연결이 끊긴 미러 호스트에 RHCOS ISO 및 RootFS 이미지 추가

RHACM(Red Hat Advanced Cluster Management)을 사용하여 연결이 끊긴 환경에서 클러스터를 설치하기 전에 먼저 사용할 RHCOS(Red Hat Enterprise Linux CoreOS) 이미지를 호스팅해야 합니다. 연결이 끊긴 미러를 사용하여 RHCOS 이미지를 호스팅합니다.

사전 요구 사항

  • HTTP 서버를 배포하고 구성하여 네트워크에서 RHCOS 이미지 리소스를 호스팅합니다. 사용자 컴퓨터에서 HTTP 서버에 액세스할 수 있어야 하며 사용자가 생성한 시스템에서 액세스할 수 있어야 합니다.
중요

RHCOS 이미지는 OpenShift Container Platform 릴리스에 따라 변경되지 않을 수 있습니다. 설치하는 버전과 같거나 그 이하의 버전 중 가장 높은 버전의 이미지를 다운로드해야 합니다. 사용 가능한 경우 OpenShift Container Platform 버전과 일치하는 이미지 버전을 사용합니다. 호스트에 RHCOS를 설치하려면 ISO 및 RootFS 이미지가 필요합니다. 이 설치 유형에서는 RHCOS QCOW2 이미지가 지원되지 않습니다.

절차

  1. 미러 호스트에 로그인합니다.
  2. mirror.openshift.com 에서 RHCOS ISO 및 RootFS 이미지를 가져옵니다. 예를 들면 다음과 같습니다.

    1. 필요한 이미지 이름 및 OpenShift Container Platform 버전을 환경 변수로 내보냅니다.

      $ export ISO_IMAGE_NAME=<iso_image_name> 1
      $ export ROOTFS_IMAGE_NAME=<rootfs_image_name> 1
      $ export OCP_VERSION=<ocp_version> 1
      1
      ISO 이미지 이름(예: rhcos-4.10.1-x86_64-live.x86_64.iso)
      1
      rootfs 이미지 이름(예: rhcos-4.10.1-x86_64-live-rootfs.x86_64.img)
      1
      OpenShift Container Platform verison (예: 4.10.1)
    2. 필요한 이미지를 다운로드합니다.

      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.10/${OCP_VERSION}/${ISO_IMAGE_NAME} -O /var/www/html/${ISO_IMAGE_NAME}
      $ sudo wget https://mirror.openshift.com/pub/openshift-v4/dependencies/rhcos/4.10/${OCP_VERSION}/${ROOTFS_IMAGE_NAME} -O /var/www/html/${ROOTFS_IMAGE_NAME}

검증 단계

  • 다운로드한 이미지가 성공적으로 수행되었으며 연결이 끊긴 미러 호스트에서 제공 중인지 확인합니다. 예를 들면 다음과 같습니다.

    $ wget http://$(hostname)/${ISO_IMAGE_NAME}

    출력 예

    Saving to: rhcos-4.10.1-x86_64-live.x86_64.iso
    rhcos-4.10.1-x86_64-live.x86_64.iso-  11%[====>    ]  10.01M  4.71MB/s

19.2.4. hub 클러스터에서 지원 서비스 활성화 및 AgentServiceConfig 업데이트

RHACM(Red Hat Advanced Cluster Management)은 지원 서비스를 사용하여 OpenShift Container Platform 클러스터를 배포합니다. 지원 서비스는 CIM( Central Infrastructure Management)을 사용하여 MultiClusterHub Operator를 활성화하면 자동으로 배포됩니다. hub 클러스터에서 CIM을 활성화하면 미러 레지스트리 HTTP 서버에서 호스팅되는 ISO 및 RootFS 이미지에 대한 참조로 AgentServiceConfig CR(사용자 정의 리소스)을 업데이트해야 합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • hub 클러스터에서 지원 서비스를 활성화했습니다. 자세한 내용은 CIM 활성화를 참조하십시오.

절차

  1. 다음 명령을 실행하여 AgentServiceConfig CR을 업데이트합니다.

    $ oc edit AgentServiceConfig
  2. CR의 items.spec.osImages 필드에 다음 항목을 추가합니다.

    - cpuArchitecture: x86_64
        openshiftVersion: "4.10"
        rootFSUrl: https://<host>/<path>/rhcos-live-rootfs.x86_64.img
        url: https://<mirror-registry>/<path>/rhcos-live.x86_64.iso

    다음과 같습니다.

    <host>
    대상 미러 레지스트리 HTTP 서버의 FQDN(정규화된 도메인 이름)입니다.
    <path>
    대상 미러 레지스트리의 이미지 경로입니다.

    편집기를 저장하고 종료하여 변경 사항을 적용합니다.

19.2.5. 연결이 끊긴 미러 레지스트리를 사용하도록 hub 클러스터 구성

연결이 끊긴 환경에 연결이 끊긴 미러 레지스트리를 사용하도록 hub 클러스터를 구성할 수 있습니다.

사전 요구 사항

  • RHACM(Red Hat Advanced Cluster Management) 2.4를 사용하여 연결 해제된 허브 클러스터 설치가 있어야 합니다.
  • HTTP 서버에 rootfsiso 이미지를 호스팅했습니다.
주의

HTTP 서버에 대해 TLS를 활성화하는 경우 루트 인증서가 클라이언트가 신뢰하는 기관에서 서명한지 확인하고 OpenShift Container Platform 허브와 관리형 클러스터와 HTTP 서버 간의 신뢰할 수 있는 인증서 체인을 확인해야 합니다. 신뢰할 수 없는 인증서로 구성된 서버를 사용하면 이미지가 이미지 생성 서비스에 다운로드되지 않습니다. 신뢰할 수 없는 HTTPS 서버 사용은 지원되지 않습니다.

절차

  1. 미러 레지스트리 구성이 포함된 ConfigMap 을 생성합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: assisted-installer-mirror-config
      namespace: assisted-installer
      labels:
        app: assisted-service
    data:
      ca-bundle.crt: <certificate> 1
      registries.conf: |  2
        unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]
    
        [[registry]]
          location = <mirror_registry_url>  3
          insecure = false
          mirror-by-digest-only = true
    1
    미러 레지스트리를 생성할 때 사용되는 미러 레지스트리의 인증서입니다.
    2
    미러 레지스트리의 구성입니다.
    3
    미러 레지스트리의 URL입니다.

    이 업데이트는 다음과 같이 AgentServiceConfig 사용자 정의 리소스의 mirrorRegistryRef 를 업데이트합니다.

    출력 예

    apiVersion: agent-install.openshift.io/v1beta1
    kind: AgentServiceConfig
    metadata:
      name: agent
    spec:
      databaseStorage:
        volumeName: <db_pv_name>
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <db_storage_size>
      filesystemStorage:
        volumeName: <fs_pv_name>
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: <fs_storage_size>
      mirrorRegistryRef:
        name: 'assisted-installer-mirror-config'
      osImages:
        - openshiftVersion: <ocp_version>
          rootfs: <rootfs_url> 1
          url: <iso_url> 2

    1 2
    HTTPD 서버의 URL과 일치해야 합니다.
중요

클러스터 설치 중에 유효한 NTP 서버가 필요합니다. 적절한 NTP 서버를 사용할 수 있으며, 연결이 끊긴 네트워크를 통해 설치된 클러스터에서 연결할 수 있는지 확인합니다.

19.2.6. ArgoCD로 hub 클러스터 구성

ZTP(ZTP) GitOps 흐름을 기반으로 각 사이트에 필요한 설치 및 정책 사용자 정의 리소스(CR)를 생성하는 ArgoCD 애플리케이션 세트로 허브 클러스터를 구성할 수 있습니다.

사전 요구 사항

  • RHACM(Red Hat Advanced Cluster Management) 및 Red Hat OpenShift GitOps가 설치된 OpenShift Container Platform 허브 클러스터가 있어야 합니다.
  • " GitOps ZTP 사이트 구성 리포지토리 준비" 섹션에 설명된 대로 ZTP GitOps 플러그인 컨테이너에서 참조 배포를 추출했습니다. 참조 배포를 추출하면 다음 절차에서 참조되는 out/argocd/deployment 디렉터리가 생성됩니다.

절차

  1. ArgoCD 파이프라인 구성을 준비합니다.

    1. 예제 디렉터리와 유사한 디렉터리 구조를 사용하여 Git 리포지토리를 생성합니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
    2. ArgoCD UI를 사용하여 리포지토리에 대한 액세스를 구성합니다. 설정에서 다음을 구성합니다.

      • 리포지토리 - 연결 정보를 추가합니다. URL은 .git (예: https://repo.example.com/repo.git 및 credentials)으로 끝나야 합니다.
      • certificates - 필요한 경우 리포지토리의 공용 인증서를 추가합니다.
    3. Git 리포지토리를 기반으로 두 개의 ArgoCD 애플리케이션 out/argocd/deployment/clusters-app.yamlout/argocd/deployment/policies-app.yaml 을 수정합니다.

      • Git 리포지토리를 가리키도록 URL을 업데이트합니다. URL은 .git 로 끝납니다(예: https://repo.example.com/repo.git).
      • targetRevision 은 모니터링할 Git 리포지토리 분기를 나타냅니다.
      • path 는 각각 site Config 및 PolicyGenTemplate CR의 경로를 지정합니다.
  2. ZTP GitOps 플러그인을 설치하려면 이전에 out/argocd/deployment/ 디렉터리에 추출된 패치 파일을 사용하여 hub 클러스터의 ArgoCD 인스턴스를 패치해야 합니다. 다음 명령을 실행합니다.

    $ oc patch argocd openshift-gitops \
    -n openshift-gitops --type=merge \
    --patch-file out/argocd/deployment/argocd-openshift-gitops-patch.json
  3. 다음 명령을 사용하여 hub 클러스터에 파이프라인 구성을 적용합니다.

    $ oc apply -k out/argocd/deployment

19.2.7. GitOps ZTP 사이트 구성 리포지토리 준비

ZTP GitOps 파이프라인을 사용하려면 먼저 사이트 구성 데이터를 호스팅할 Git 리포지토리를 준비해야 합니다.

사전 요구 사항

  • 필요한 설치 및 정책 CR(사용자 정의 리소스)을 생성하기 위해 hub 클러스터 GitOps 애플리케이션을 구성했습니다.
  • ZTP(zero touch provisioning)를 사용하여 관리형 클러스터를 배포했습니다.

절차

  1. site Config 및 PolicyGenTemplate CR에 대한 별도의 경로를 사용하여 디렉터리 구조를 생성합니다.
  2. 다음 명령을 사용하여 ztp-site-generate 컨테이너 이미지에서 argocd 디렉터리를 내보냅니다.

    $ podman pull registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10
    $ mkdir -p ./out
    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v{product-version} extract /home/ztp --tar | tar x -C ./out
  3. out 디렉터리에 다음 하위 디렉터리가 포함되어 있는지 확인합니다.

    • out/extra-manifest 에는 site Config 가 추가 매니페스트 configMap 을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
    • out/source-crs 에는 PolicyGenTemplate 에서 RHACM(Red Hat Advanced Cluster Management) 정책을 생성하는 데 사용하는 소스 CR 파일이 포함되어 있습니다.
    • out/argocd/deployment 에는 이 절차의 다음 단계에서 사용할 hub 클러스터에 적용할 패치 및 YAML 파일이 포함되어 있습니다.
    • out/argocd/example 에는 권장 구성을 나타내는 site ConfigPolicyGenTemplate 파일의 예제가 포함되어 있습니다.

out/argocd/example 아래의 디렉터리 구조는 Git 리포지토리의 구조와 콘텐츠에 대한 참조 역할을 합니다. 예제에는 단일 노드, 3 노드 및 표준 클러스터에 대한 site ConfigPolicyGenTemplate 참조 CR이 포함되어 있습니다. 사용하지 않는 클러스터 유형에 대한 참조를 제거합니다. 다음 예제에서는 단일 노드 클러스터의 네트워크에 대한 CR 세트를 설명합니다.

example
├── policygentemplates
│   ├── common-ranGen.yaml
│   ├── example-sno-site.yaml
│   ├── group-du-sno-ranGen.yaml
│   ├── group-du-sno-validator-ranGen.yaml
│   ├── kustomization.yaml
│   └── ns.yaml
└── siteconfig
    ├── example-sno.yaml
    ├── KlusterletAddonConfigOverride.yaml
    └── kustomization.yaml

site ConfigPolicyGenTemplate CR을 별도의 디렉터리에 보관합니다. site Config 및 PolicyGenTemplate 디렉터리에 모두 해당 디렉토리에 파일을 명시적으로 포함하는 kustomization.yaml 파일을 포함해야 합니다.

이 디렉터리 구조와 kustomization.yaml 파일을 커밋하고 Git 리포지토리로 내보내야 합니다. Git으로의 초기 내보내기에는 kustomization.yaml 파일이 포함되어야 합니다. site Config (example-sno.yaml) 및 PolicyGenTemplate (common-ranGen.yaml,group-du-sno*.yaml, example-sno-site.yaml) 파일을 생략하고 나중에 사이트를 배포할 때 필요에 따라 푸시할 수 있습니다.

KlusterletAddonConfigOverride.yaml 파일은 해당 파일에 대한 참조가 커밋되어 Git에 푸시되는 하나 이상의 site Config CR에서만 필요합니다. 이 사용 방법에 대한 예는 example-sno.yaml 을 참조하십시오.

19.3. RHACM 및 siteConfig 리소스를 사용하여 관리형 클러스터 설치

지원 서비스 및 core-reduction 기술이 활성화된 GitOps 플러그인 정책 생성기를 사용하여 RHACM(Red Hat Advanced Cluster Management)을 사용하여 OpenShift Container Platform 클러스터를 스케일링하여 프로비저닝할 수 있습니다. zero touch priovisioning (ZTP) 파이프라인은 클러스터 설치를 수행합니다. ZTP는 연결이 끊긴 환경에서 사용할 수 있습니다.

19.3.1. GitOps ZTP 및 토폴로지 Aware Lifecycle Manager

GitOps zero touch provisioning(ZTP)은 Git에 저장된 매니페스트에서 설치 및 구성 CR을 생성합니다. 이러한 아티팩트는 RHACM(Red Hat Advanced Cluster Management), 지원 서비스 및 TALM( Topology Aware Lifecycle Manager)이 CR을 사용하여 관리되는 클러스터를 설치 및 구성하는 중앙 집중식 허브 클러스터에 적용됩니다. ZTP 파이프라인의 구성 단계에서는 TALM을 사용하여 구성 CR의 애플리케이션을 클러스터로 오케스트레이션합니다. GitOps ZTP와 TALM 사이에 몇 가지 주요 통합 지점이 있습니다.

정책 정보
기본적으로 GitOps ZTP는 정보 수정 작업으로 모든 정책을 생성합니다. 이러한 정책을 통해 RHACM은 정책과 관련된 클러스터의 컴플라이언스 상태를 보고하지만 원하는 구성은 적용하지 않습니다. ZTP 프로세스 중에 OpenShift를 설치한 후 TALM은 생성된 정보 보호 정책을 단계별로 진행하여 대상 관리 클러스터에서 이를 적용합니다. 이는 관리 클러스터에 구성을 적용합니다. 클러스터 라이프사이클의 ZTP 단계 외부에서는 영향을 받는 관리형 클러스터로 변경 사항을 즉시 롤아웃할 위험 없이 정책을 변경할 수 있습니다. TALM을 사용하여 시간 및 수정된 클러스터 세트를 제어할 수 있습니다.
ClusterGroupUpgrade CR 자동 생성

새로 배포된 클러스터의 초기 구성을 자동화하기 위해 TALM은 hub 클러스터에서 모든 ManagedCluster CR의 상태를 모니터링합니다. 새로 생성된 ManagedCluster CR을 포함하여 ztp-done 레이블이 적용되지 않은 ManagedCluster CR을 사용하면 TALM이 다음과 같은 특성을 가진 ClusterGroupUpgrade CR을 자동으로 생성합니다.

  • ClusterGroupUpgrade CR이 ztp-install 네임스페이스에서 생성되고 활성화됩니다.
  • ClusterGroupUpgrade CR은 ManagedCluster CR과 이름이 동일합니다.
  • 클러스터 선택기에는 해당 ManagedCluster CR과 연결된 클러스터만 포함됩니다.
  • 관리형 정책 세트에는 ClusterGroupUpgrade 를 생성할 때 RHACM이 클러스터에 바인딩한 모든 정책이 포함됩니다.
  • 사전 캐싱이 비활성화되어 있습니다.
  • 타임아웃은 4시간(240분)으로 설정합니다.

활성화된 ClusterGroupUpgrade 를 자동으로 생성하면 사용자 개입 없이 클러스터의 초기 제로트 배포가 진행됩니다. 또한 ztp-done 레이블이 없는 모든 ManagedCluster 에 대해 ClusterGroupUpgrade CR 자동 생성을 사용하면 클러스터의 ClusterGroupUpgrade CR을 간단히 삭제하여 실패한 ZTP 설치를 다시 시작할 수 있습니다.

disappears

PolicyGenTemplate CR에서 생성된 각 정책에는 ztp-deploy-ECDHE 주석이 포함되어 있습니다. 이 주석은 해당 정책에 포함된 각 CR의 동일한 주석을 기반으로 합니다. 분리 주석은 자동 생성된 ClusterGroupUpgrade CR에서 정책을 정렬하는 데 사용됩니다. parse 주석은 자동 생성된 ClusterGroupUpgrade CR 이외의 용도로 사용되지 않습니다.

참고

동일한 정책에 있는 모든 CR은 ztp-deploy- ECDHE 주석에 대해 동일한 설정을 가져야 합니다. 각 CR에 대한 이 주석의 기본값은 PolicyGenTemplate 에서 재정의할 수 있습니다. 소스 CR의 parse 주석은 정책 파도 주석을 결정하고 설정하는 데 사용됩니다. 이 주석은 런타임 시 생성된 정책에 포함된 빌드 CR마다 제거됩니다.

TALM은 파기 주석에 의해 지정된 순서대로 구성 정책을 적용합니다. TALM은 다음 정책으로 이동하기 전에 각 정책을 준수할 때까지 기다립니다. 각 CR에 대한 파도 주석이 클러스터에 적용되는 CR의 사전 요구 사항을 고려해야 합니다. 예를 들어 Operator의 구성을 사용하여 Operator 앞에 설치하거나 동시에 설치해야 합니다. 마찬가지로 Operator의 CatalogSource 를 Operator 서브스크립션 앞에 또는 동시에 설치해야 합니다. 각 CR의 기본 전달 값은 이러한 사전 요구 사항을 고려합니다.

여러 CR과 정책이 동일한 중단 번호를 공유할 수 있습니다. 정책을 줄이면 배포 속도가 빨라지고 CPU 사용량이 줄어들 수 있습니다. 많은 CR을 상대적으로 소수의 파도로 그룹화하는 것이 가장 좋습니다.

각 소스 CR의 기본 중단 값을 확인하려면 ztp-site-generate 컨테이너 이미지에서 추출된 out/source-crs 디렉터리에 대해 다음 명령을 실행합니다.

$ grep -r "ztp-deploy-wave" out/source-crs
단계 라벨

ClusterGroupUpgrade CR은 자동으로 생성되며 ZTP 프로세스 시작 및 종료 시 라벨에 ManagedCluster CR에 주석을 달 수 있는 지시문이 포함되어 있습니다.

설치 후 ZTP 구성이 시작되면 ManagedClusterztp-running 레이블이 적용됩니다. 모든 정책이 클러스터에 수정되고 완전히 호환되면 TALM이 ztp-running 레이블을 제거하고 ztp-done 라벨을 적용합니다.

informDuValidator 정책을 사용하는 배포의 경우 클러스터가 애플리케이션 배포를 완전히 준비할 때 ztp-done 레이블이 적용됩니다. 여기에는 ZTP 적용된 구성 CR의 모든 조정 및 결과 효과가 포함됩니다. ztp-done 레이블은 TALM의 자동 ClusterGroupUpgrade CR 생성에 영향을 미칩니다. 클러스터의 초기 ZTP 설치 후 이 라벨을 조작하지 마십시오.

연결된 CR
자동으로 생성된 ClusterGroupUpgrade CR에는 소유자 참조가 파생된 ManagedCluster 로 설정됩니다. 이 참조를 통해 ManagedCluster CR을 삭제하면 지원되는 리소스와 함께 ClusterGroupUpgrade 인스턴스가 삭제됩니다.

19.3.2. ZTP를 사용하여 관리형 클러스터 배포 개요

RHACM(Red Hat Advanced Cluster Management)은 zero touch provisioning(ZTP)을 사용하여 단일 노드 OpenShift Container Platform 클러스터, 3노드 클러스터 및 표준 클러스터를 배포합니다. Git 리포지토리에서 사이트 구성 데이터를 OpenShift Container Platform CR(사용자 정의 리소스)으로 관리합니다. ZTP는 선언적 GitOps 접근 방식을 사용하여 한 번 개발하여 관리 클러스터를 배포합니다.

클러스터 배포에는 다음이 포함됩니다.

  • 빈 서버에 호스트 운영 체제(RHCOS) 설치
  • OpenShift Container Platform 배포
  • 클러스터 정책 및 사이트 서브스크립션 생성
  • 서버 운영 체제에 필요한 네트워크 구성
  • 프로필 Operator 배포 및 성능 프로필, PTP 및 SR-IOV와 같은 필요한 소프트웨어 관련 구성 수행
관리되는 사이트 설치 프로세스 개요

hub 클러스터에서 관리 사이트 CR(사용자 정의 리소스)을 적용하면 다음 작업이 자동으로 수행됩니다.

  1. 검색 이미지 ISO 파일이 생성되어 대상 호스트에서 부팅됩니다.
  2. ISO 파일이 대상 호스트에서 성공적으로 부팅되면 호스트 하드웨어 정보를 RHACM에 보고합니다.
  3. 모든 호스트가 발견되면 OpenShift Container Platform이 설치됩니다.
  4. OpenShift Container Platform 설치가 완료되면 허브가 대상 클러스터에 klusterlet 서비스를 설치합니다.
  5. 요청된 애드온 서비스가 대상 클러스터에 설치되어 있습니다.

hub 클러스터에서 관리 클러스터의 에이전트 CR이 생성되면 검색 이미지 ISO 프로세스가 완료됩니다.

중요

대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대한 권장 단일 노드 OpenShift 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.

19.3.3. 관리형 베어 메탈 호스트 시크릿 생성

관리 베어 메탈 호스트에 필요한 Secret CR(사용자 정의 리소스)을 hub 클러스터에 추가합니다. 레지스트리에서 클러스터 설치 이미지를 가져오기 위해 BMC(Baseboard Management Controller) 및 지원 설치 서비스 시크릿에 액세스하려면 ZTP 파이프라인의 시크릿이 필요합니다.

참고

보안은 이름으로 site Config CR 에서 참조됩니다. 네임스페이스는 SiteConfig 네임스페이스와 일치해야 합니다.

절차

  1. OpenShift 및 모든 애드온 클러스터 Operator를 설치하는 데 필요한 BMC(Host Baseboard Management Controller) 및 풀 시크릿(pull secret)의 인증 정보가 포함된 YAML 시크릿 파일을 생성합니다.

    1. 다음 YAML을 example-sno-secret.yaml 파일로 저장합니다.

      apiVersion: v1
      kind: Secret
      metadata:
        name: example-sno-bmc-secret
        namespace: example-sno 1
      data: 2
        password: <base64_password>
        username: <base64_username>
      type: Opaque
      ---
      apiVersion: v1
      kind: Secret
      metadata:
        name: pull-secret
        namespace: example-sno  3
      data:
        .dockerconfigjson: <pull_secret> 4
      type: kubernetes.io/dockerconfigjson
      1
      관련 site Config CR에 구성된 네임스페이스와 일치해야 합니다.
      2
      암호사용자이름에 대한 base64로 인코딩된 값
      3
      관련 site Config CR에 구성된 네임스페이스와 일치해야 합니다.
      4
      base64로 인코딩된 풀 시크릿
  2. 클러스터를 설치하는 데 사용하는 kustomization.yaml 파일에 상대 경로를 example-sno-secret.yaml 에 추가합니다.

19.3.4. siteConfig 및 ZTP를 사용하여 관리형 클러스터 배포

다음 절차에 따라 site Config CR(사용자 정의 리소스) 및 관련 파일을 생성하고 zero touch provisioning (ZTP) 클러스터 배포를 시작합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 필요한 설치 및 정책 CR을 생성하기 위해 hub 클러스터를 구성했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 ArgoCD 애플리케이션의 소스 리포지토리로 구성해야 합니다. 자세한 내용은 "GITOP ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.

    참고

    소스 리포지토리를 생성할 때 ztp-site-generate 컨테이너에서 추출한 argocd/deployment/argocd-openshift-gitops-patch.json patch-file을 사용하여 ArgoCD 애플리케이션을 패치해야 합니다. " ArgoCD를 사용하여 hub 클러스터 구성"을 참조하십시오.

  • 관리 클러스터를 프로비저닝할 준비를 하려면 각 베어 메탈 호스트에 대해 다음이 필요합니다.

    네트워크 연결
    네트워크에는 DNS가 필요합니다. hub 클러스터에서 관리 클러스터 호스트에 연결할 수 있어야 합니다. hub 클러스터와 관리 클러스터 호스트 간에 계층 3 연결이 있는지 확인합니다.
    BMC(Baseboard Management Controller) 세부 정보
    ZTP는 BMC 사용자 이름과 암호 세부 정보를 사용하여 클러스터 설치 중에 BMC에 연결합니다. GitOps ZTP 플러그인은 사이트 Git 리포지토리의 site Config CR을 기반으로 hub 클러스터에서 ManagedCluster CR을 관리합니다. 각 호스트에 대해 개별 BMCSecret CR을 수동으로 생성합니다.

    절차

    1. hub 클러스터에서 필요한 관리 클러스터 시크릿을 생성합니다. 이러한 리소스는 클러스터 이름과 일치하는 이름이 있는 네임스페이스에 있어야 합니다. 예를 들어 out/argocd/example/siteconfig/example-sno.yaml 에서 클러스터 이름과 네임스페이스는 example-sno 입니다.

      1. 다음 명령을 실행하여 클러스터 네임스페이스를 내보냅니다.

        $ export CLUSTERNS=example-sno
      2. 네임스페이스를 생성합니다.

        $ oc create namespace $CLUSTERNS
    2. 관리형 클러스터의 pull secret 및 BMC Secret CR을 생성합니다. 풀 시크릿에는 OpenShift Container Platform 및 모든 필수 Operator를 설치하는 데 필요한 모든 인증 정보가 포함되어야 합니다. 자세한 내용은 "관리된 베어 메탈 호스트 시크릿 생성"을 참조하십시오.

      참고

      보안은 이름별로 SiteConfig CR(사용자 정의 리소스)에서 참조합니다. 네임스페이스는 SiteConfig 네임스페이스와 일치해야 합니다.

    3. Git 리포지토리의 로컬 복제본에 클러스터용 site Config CR을 생성합니다.

      1. out/argocd/example/siteconfig/ 폴더에 있는 CR에 대한 적절한 예를 선택합니다. 폴더에는 단일 노드, 3 노드 및 표준 클러스터의 예제 파일이 포함되어 있습니다.

        • example-sno.yaml
        • example-3node.yaml
        • example-standard.yaml
      2. 원하는 클러스터 유형과 일치하도록 예제 파일의 클러스터 및 호스트 세부 정보를 변경합니다. 예를 들면 다음과 같습니다.

        단일 노드 OpenShift 클러스터 siteConfig CR의 예

        apiVersion: ran.openshift.io/v1
        kind: SiteConfig
        metadata:
          name: "<site_name>"
          namespace: "<site_name>"
        spec:
          baseDomain: "example.com"
          pullSecretRef:
            name: "assisted-deployment-pull-secret" 1
          clusterImageSetNameRef: "openshift-4.10" 2
          sshPublicKey: "ssh-rsa AAAA..." 3
          clusters:
          - clusterName: "<site_name>"
            networkType: "OVNKubernetes"
            clusterLabels: 4
              common: true
              group-du-sno: ""
              sites : "<site_name>"
            clusterNetwork:
              - cidr: 1001:1::/48
                hostPrefix: 64
            machineNetwork:
              - cidr: 1111:2222:3333:4444::/64
            serviceNetwork:
              - 1001:2::/112
            additionalNTPSources:
              - 1111:2222:3333:4444::2
            #crTemplates:
            #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
            nodes:
              - hostName: "example-node.example.com" 6
                role: "master"
                #biosConfigRef:
                #  filePath: "example-hw.profile" 7
                bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8
                bmcCredentialsName:
                  name: "bmh-secret" 9
                bootMACAddress: "AA:BB:CC:DD:EE:11"
                bootMode: "UEFI" 10
                rootDeviceHints:
                  wwn: "0x11111000000asd123"
                cpuset: "0-1,52-53"
                nodeNetwork: 11
                  interfaces:
                    - name: eno1
                      macAddress: "AA:BB:CC:DD:EE:11"
                  config:
                    interfaces:
                      - name: eno1
                        type: ethernet
                        state: up
                        ipv4:
                          enabled: false
                        ipv6: 12
                          enabled: true
                          address:
                          - 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

        1
        site Config CR과 동일한 네임스페이스를 사용하여 assisted-deployment-pull-secret CR 을 생성합니다.
        2
        clusterImageSetNameRef 는 hub 클러스터에서 사용 가능한 이미지 세트를 정의합니다. hub 클러스터에서 지원되는 버전 목록을 보려면 oc get clusterimagesets 를 실행합니다.
        3
        클러스터에 액세스하는 데 사용되는 SSH 공개 키를 구성합니다.
        4
        클러스터 레이블은 사용자가 정의한 PolicyGenTemplate CR의 bindingRules 필드에 대응해야 합니다. 예를 들어 policygentemplates/common-ranGen.yamlcommon: true set, policygentemplates/group-du-sno-ranGen.yamlgroup-du-sno: "" 가 설정된 모든 클러스터에 적용됩니다.
        5
        선택사항입니다. KlusterletAddonConfig 아래에 있는 CR 사양을 사용하여 클러스터에 대해 생성된 기본 KlusterletAddonConfig 를 덮어씁니다.
        6
        단일 노드 배포의 경우 단일 호스트를 정의합니다. 3-노드 배포의 경우 3개의 호스트를 정의합니다. 표준 배포의 경우 master와 role 으로 정의된 두 개 이상의 호스트인 worker 를 사용하여 세 개의 호스트를 정의합니다.
        7
        선택사항입니다. Bare sConfigRef 를 사용하여 호스트에 필요한 펌웨어를 구성합니다.
        8
        모든 클러스터 유형에 적용됩니다. BMC 주소를 지정합니다.
        9
        BMC 인증 정보를 지정하는 bmh-secret CR을 생성합니다. site Config CR과 동일한 네임스페이스 를 사용합니다.
        10
        UEFISecureBoot 를 사용하여 호스트에서 보안 부팅을 활성화합니다.
        11
        노드의 네트워크 설정을 지정합니다.
        12
        호스트의 IPv6 주소를 구성합니다. 고정 IP 주소가 있는 단일 노드 OpenShift 클러스터의 경우 노드별 API 및 Ingress IP가 동일해야 합니다.
        참고

        BMC 주소 지정에 대한 자세한 내용은 "ECDHE 리소스" 섹션을 참조하십시오.

      3. out/argocd/extra-manifest 에서 기본 extra-manifest MachineConfig CR 세트를 검사할 수 있습니다. 설치 시 클러스터에 자동으로 적용됩니다.
      4. 선택 사항: 프로비저닝된 클러스터에 추가 설치 시간 매니페스트를 프로비저닝하려면 Git 리포지토리에 디렉터리를 생성합니다(예: sno-extra-manifest/ ), 사용자 정의 매니페스트 CR을 이 디렉터리에 추가합니다. site Config.yamlextraManifestPath 필드의 이 디렉터리를 참조하는 경우 이 참조 디렉터리의 모든 CR이 기본 추가 매니페스트 세트에 추가됩니다.
    4. out/argocd/example/siteconfig/ kustomization.yaml 에 표시된 예제와 유사하게 generators 섹션의 kustomization.yaml 파일에 site Config CR을 추가합니다.
    5. Git 리포지토리 에서 siteConfig CR 및 관련 kustomization.yaml 변경 사항을 커밋하고 변경 사항을 내보냅니다.

      ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다.

19.3.5. 관리형 클러스터 설치 진행 상황 모니터링

ArgoCD 파이프라인은 siteConfig CR을 사용하여 클러스터 구성 CR을 생성하고 hub 클러스터와 동기화합니다. ArgoCD 대시보드에서 동기화 진행 상황을 모니터링할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

절차

동기화가 완료되면 일반적으로 설치는 다음과 같이 진행됩니다.

  1. Assisted Service Operator는 클러스터에 OpenShift Container Platform을 설치합니다. RHACM 대시보드 또는 명령줄에서 다음 명령을 실행하여 클러스터 설치 진행 상황을 모니터링할 수 있습니다.

    1. 클러스터 이름을 내보냅니다.

      $ export CLUSTER=<clusterName>
    2. 관리 클러스터의 AgentClusterInstall CR을 쿼리합니다.

      $ oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Completed")]}' | jq
    3. 클러스터의 설치 이벤트를 가져옵니다.

      $ curl -sk $(oc get agentclusterinstall -n $CLUSTER $CLUSTER -o jsonpath='{.status.debugInfo.eventsURL}')  | jq '.[-2,-1]'

19.3.6. 설치 CR을 검증하여 GitOps ZTP 문제 해결

ArgoCD 파이프라인은 site ConfigPolicyGenTemplate 사용자 정의 리소스(CR)를 사용하여 클러스터 구성 CR 및 RHACM(Red Hat Advanced Cluster Management) 정책을 생성합니다. 다음 단계를 사용하여 이 프로세스 중에 발생할 수 있는 문제를 해결합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

절차

  1. 다음 명령을 사용하여 설치 CR이 생성되었는지 확인합니다.

    $ oc get AgentClusterInstall -n <cluster_name>

    반환된 오브젝트가 없는 경우 다음 단계를 사용하여 site Config 파일에서 설치 CR로의 ArgoCD 파이프라인 흐름 문제를 해결합니다.

  2. hub 클러스터에서 site Config CR을 사용하여 ManagedCluster CR이 생성되었는지 확인합니다.

    $ oc get managedcluster
  3. ManagedCluster 가 누락된 경우 클러스터 애플리케이션이 Git 리포지토리에서 hub 클러스터와 파일을 동기화하지 못하는지 확인합니다.

    $ oc describe -n openshift-gitops application clusters
    1. Status.Conditions 필드가 있는지 확인하여 관리형 클러스터의 오류 로그를 확인합니다. 예를 들어, site Config CR에서 extraManifestPath: 에 유효하지 않은 값을 설정하면 다음 오류가 발생합니다.

      Status:
        Conditions:
          Last Transition Time:  2021-11-26T17:21:39Z
          Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/siteconfigs/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not create extra-manifest ranSite1.extra-manifest3 stat extra-manifest3: no such file or directory 2021/11/26 17:21:40 Error: could not build the entire SiteConfig defined by /tmp/kust-plugin-config-913473579: stat extra-manifest3: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-913473579; exit status 1: exit status 1
          Type:  ComparisonError
    2. Status.Sync 필드를 확인합니다. 로그 오류가 있는 경우 Status.Sync 필드에 Unknown 오류가 표시될 수 있습니다.

      Status:
        Sync:
          Compared To:
            Destination:
              Namespace:  clusters-sub
              Server:     https://kubernetes.default.svc
            Source:
              Path:             sites-config
              Repo URL:         https://git.com/ran-sites/siteconfigs/.git
              Target Revision:  master
          Status:               Unknown

19.3.7. ZTP 파이프라인에서 관리형 클러스터 사이트 제거

ZTP 파이프라인에서 관리되는 사이트 및 관련 설치 및 구성 정책 CR을 제거할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

precedure

  1. kustomization.yaml 파일에서 관련 site Config 및 PolicyGenTemplate 파일을 제거하여 사이트 및 관련 CR을 제거합니다.

    ZTP 파이프라인을 다시 실행하면 생성된 CR이 제거됩니다.

  2. 선택 사항: 사이트를 영구적으로 제거하려면 Git 리포지토리에서 site Config 및 사이트별 PolicyGenTemplate 파일도 제거해야 합니다.
  3. 선택 사항: 사이트를 임시로 제거하려면 예를 들어 사이트를 재배포할 때 사이트별 PolicyGenTemplate CR을 Git 리포지토리에 남겨 둘 수 있습니다.
참고

Git 리포지토리에서 site Config 파일을 제거한 후 해당 클러스터가 분리 프로세스에 있는 경우 hub 클러스터에서 RHACM(Red Hat Advanced Cluster Management)을 확인하고 분리된 클러스터를 정리하는 방법에 대한 정보를 확인합니다.

추가 리소스

19.3.8. ZTP 파이프라인에서 더 이상 사용되지 않는 콘텐츠 제거

PolicyGenTemplate 구성을 변경하면 정책과 같이 더 이상 사용되지 않는 정책이 생성되는 경우 다음 절차를 사용하여 더 이상 사용되지 않는 정책을 제거합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

절차

  1. Git 리포지토리에서 영향을 받는 PolicyGenTemplate 파일을 제거하고 원격 리포지토리로 커밋하고 내보냅니다.
  2. 변경 사항이 애플리케이션을 통해 동기화되고 영향을 받는 정책이 hub 클러스터에서 제거될 때까지 기다립니다.
  3. 업데이트된 PolicyGenTemplate 파일을 Git 리포지토리에 다시 추가한 다음, 원격 리포지토리를 커밋하고 내보냅니다.

    참고

    Git 리포지토리에서 zero touch provisioning(ZTP) 정책을 제거하면 hub 클러스터에서도 해당 정책을 제거하면 관리 클러스터 구성에 영향을 미치지 않습니다. 해당 정책에서 관리하는 정책 및 CR은 관리형 클러스터에서 유지됩니다.

  4. 선택 사항: 더 이상 사용되지 않는 정책을 생성하는 PolicyGenTemplate CR을 변경한 후 허브 클러스터에서 이러한 정책을 수동으로 제거할 수 있습니다. Governance 탭을 사용하거나 다음 명령을 실행하여 RHACM 콘솔에서 정책을 삭제할 수 있습니다.

    $ oc delete policy -n <namespace> <policy_name>

19.3.9. ZTP 파이프라인 제거

ArgoCD 파이프라인 및 생성된 모든 ZTP 아티팩트를 제거할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

절차

  1. hub 클러스터의 RHACM(Red Hat Advanced Cluster Management)에서 모든 클러스터를 분리합니다.
  2. 다음 명령을 사용하여 배포 디렉터리에서 kustomization.yaml 파일을 삭제합니다.

    $ oc delete -k out/argocd/deployment
  3. 변경 사항을 커밋하고 사이트 리포지토리로 내보냅니다.

19.4. 정책 및 PolicyGenTemplate 리소스를 사용하여 관리형 클러스터 구성

적용된 정책 CR(사용자 정의 리소스)은 프로비저닝하는 관리형 클러스터를 구성합니다. RHACM(Red Hat Advanced Cluster Management)에서 PolicyGenTemplate CR을 사용하여 적용된 정책 CR을 생성하는 방법을 사용자 지정할 수 있습니다.

19.4.1. PolicyGenTemplate CRD 정보

PolicyGenTemplate CRD(사용자 정의 리소스 정의)는 PolicyGen 정책 생성기에 클러스터 구성에 포함할 CR(사용자 정의 리소스), CR을 생성된 정책에 결합하는 방법, 오버레이 콘텐츠를 사용하여 업데이트해야 하는 항목을 지시합니다.

다음 예제에서는 ztp-site-generate 참조 컨테이너에서 추출된 PolicyGenTemplate CR(common-du-ranGen.yaml)을 보여줍니다. common-du-ranGen.yaml 파일은 RHACM(Red Hat Advanced Cluster Management) 정책을 정의합니다. 정책은 CR에서 policyName 의 각 고유한 값에 대해 구성 CR 컬렉션을 관리합니다. common-du-ranGen.yaml 은 단일 배치 바인딩과 바인딩 규칙을 생성하여 bindingRules 섹션에 나열된 레이블을 기반으로 정책을 클러스터에 바인딩합니다.

PolicyGenTemplate CR - common-du-ranGen.yaml

---
apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "common"
  namespace: "ztp-common"
spec:
  bindingRules:
    common: "true" 1
  sourceFiles: 2
    - fileName: SriovSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: SriovOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: PtpOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogNS.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: ClusterLogOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageNS.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: StorageOperatorStatus.yaml
      policyName: "subscriptions-policy"
    - fileName: ReduceMonitoringFootprint.yaml
      policyName: "config-policy"
    - fileName: OperatorHub.yaml 3
      policyName: "config-policy"
    - fileName: DefaultCatsrc.yaml 4
      policyName: "config-policy" 5
      metadata:
        name: redhat-operators
      spec:
        displayName: disconnected-redhat-operators
        image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9
    - fileName: DisconnectedICSP.yaml
      policyName: "config-policy"
      spec:
        repositoryDigestMirrors:
        - mirrors:
          - registry.example.com:5000
          source: registry.redhat.io

1
Common: "true" 는 이 레이블이 있는 모든 클러스터에 정책을 적용합니다.
2
sourceFiles 에 나열된 파일은 설치된 클러스터에 대한 Operator 정책을 생성합니다.
3
OperatorHub.yaml 은 연결이 끊긴 레지스트리에 대한 OperatorHub를 구성합니다.
4
DefaultCatsrc.yaml 은 연결이 끊긴 레지스트리의 카탈로그 소스를 구성합니다.
5
PolicyName: "config-policy" 는 Operator 서브스크립션을 구성합니다. OperatorHub CR은 기본값을 비활성화하고 이 CR은 redhat-operators 를 연결이 끊긴 레지스트리를 가리키는 CatalogSource CR로 대체합니다.

PolicyGenTemplate CR은 포함된 여러 CR로 구성할 수 있습니다. hub 클러스터에 다음 예제 CR을 적용하여 단일 CR을 포함하는 정책을 생성합니다.

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "group-du-sno"
  namespace: "ztp-group"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  sourceFiles:
    - fileName: PtpConfigSlave.yaml
      policyName: "config-policy"
      metadata:
        name: "du-ptp-slave"
      spec:
        profile:
        - name: "slave"
          interface: "ens5f0"
          ptp4lOpts: "-2 -s --summary_interval -4"
          phc2sysOpts: "-a -r -n 24"

소스 파일 PtpConfigSlave.yaml 을 예로 사용하여 파일은 PtpConfig CR을 정의합니다. PtpConfigSlave 예제에 대해 생성된 정책의 이름은 group-du-sno-config-policy 입니다. 생성된 group-du-sno-config-policy 에 정의된 PtpConfig CR의 이름은 du-ptp-slave 입니다. PtpConfigSlave.yaml 에 정의된 사양 은 소스 파일에 정의된 다른 사양 항목과 함께 du-ptp-slave 아래에 배치됩니다.

다음 예제에서는 group-du-sno-config-policy CR을 보여줍니다.

apiVersion: policy.open-cluster-management.io/v1
kind: Policy
metadata:
  name: group-du-ptp-config-policy
  namespace: groups-sub
  annotations:
    policy.open-cluster-management.io/categories: CM Configuration Management
    policy.open-cluster-management.io/controls: CM-2 Baseline Configuration
    policy.open-cluster-management.io/standards: NIST SP 800-53
spec:
    remediationAction: inform
    disabled: false
    policy-templates:
        - objectDefinition:
            apiVersion: policy.open-cluster-management.io/v1
            kind: ConfigurationPolicy
            metadata:
                name: group-du-ptp-config-policy-config
            spec:
                remediationAction: inform
                severity: low
                namespaceselector:
                    exclude:
                        - kube-*
                    include:
                        - '*'
                object-templates:
                    - complianceType: musthave
                      objectDefinition:
                        apiVersion: ptp.openshift.io/v1
                        kind: PtpConfig
                        metadata:
                            name: du-ptp-slave
                            namespace: openshift-ptp
                        spec:
                            recommend:
                                - match:
                                - nodeLabel: node-role.kubernetes.io/worker-du
                                  priority: 4
                                  profile: slave
                            profile:
                                - interface: ens5f0
                                  name: slave
                                  phc2sysOpts: -a -r -n 24
                                  ptp4lConf: |
                                    [global]
                                    #
                                    # Default Data Set
                                    #
                                    twoStepFlag 1
                                    slaveOnly 0
                                    priority1 128
                                    priority2 128
                                    domainNumber 24
                                    .....

19.4.2. PolicyGenTemplate CR을 사용자 정의할 때 권장 사항

사이트 구성 PolicyGenTemplate 사용자 정의 리소스(CR)를 사용자 정의할 때 다음 모범 사례를 고려하십시오.

  • 필요한 경우 몇 가지 정책을 사용하십시오. 정책을 더 적게 사용하려면 리소스를 줄일 수 있습니다. 각 추가 정책은 hub 클러스터 및 배포된 관리형 클러스터에 대한 오버헤드를 생성합니다. CR은 PolicyGenTemplate CR의 policyName 필드를 기반으로 정책과 결합됩니다. policyName 에 대해 동일한 값을 가진 동일한 PolicyGenTemplate 의 CR은 단일 정책에서 관리됩니다.
  • 연결이 끊긴 환경에서는 모든 Operator가 포함된 단일 인덱스로 레지스트리를 구성하여 모든 Operator에 대해 단일 카탈로그 소스를 사용합니다. 관리 클러스터의 추가 CatalogSource CR마다 CPU 사용량이 증가합니다.
  • MachineConfig CR은 설치 중에 적용되도록 site Config CRextraManifests 로 포함되어야 합니다. 이렇게 하면 클러스터가 애플리케이션을 배포할 준비가 될 때까지 전반적인 시간이 단축될 수 있습니다.
  • PolicyGenTemplates 는 channel 필드를 재정의하여 원하는 버전을 명시적으로 식별해야 합니다. 이렇게 하면 업그레이드 중에 소스 CR이 변경되면 생성된 서브스크립션이 업데이트되지 않습니다.

추가 리소스

  • RHACM을 사용하여 클러스터 스케일링에 대한 권장 사항은 성능 및 확장성을 참조하십시오.
참고

hub 클러스터에서 많은 수의 통화 클러스터를 관리할 때 리소스 사용량을 줄이기 위한 정책 수를 최소화합니다.

여러 구성 CR을 단일 또는 제한된 정책으로 그룹화하는 것이 hub 클러스터에 대한 전체 정책 수를 줄이는 한 가지 방법입니다. 사이트 구성 관리 정책의 공통, 그룹 및 사이트 계층을 사용하는 경우 사이트별 구성을 단일 정책으로 결합하는 것이 특히 중요합니다.

19.4.3. RAN 배포를 위한 PolicyGenTemplate CR

PGT( PolicyGenTemplate ) 사용자 정의 리소스(CR)를 사용하여 GitOps zero touch provisioning(ZTP) 파이프라인을 사용하여 클러스터에 적용된 구성을 사용자 지정합니다. PGT CR을 사용하면 클러스터에서 구성 CR 세트를 관리하기 위해 하나 이상의 정책을 생성할 수 있습니다. PGT는 관리형 CR 세트를 식별하고, 이를 정책으로 번들하고, 해당 CR을 기반으로 정책을 빌드하며, 라벨 바인딩 규칙을 사용하여 정책을 클러스터와 연결합니다.

GitOps ZTP 컨테이너에서 얻은 참조 구성은 클러스터가 RAN(Radio Access Network) 분산 장치(DU) 애플리케이션의 일반적인 성능 및 리소스 사용률 제약 조건을 지원할 수 있도록 중요한 기능 및 노드 튜닝 설정 세트를 제공하도록 설계되었습니다. 기본 구성의 변경 또는 누락은 기능 가용성, 성능 및 리소스 사용률에 영향을 미칠 수 있습니다. 참조 PolicyGenTemplate CR을 기반으로 사용하여 특정 사이트 요구 사항에 맞게 구성 파일의 계층을 생성합니다.

RAN DU 클러스터 구성에 대해 정의된 기준의 PolicyGenTemplate CR은 GitOps ZTP ztp-site-generate 컨테이너에서 추출할 수 있습니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.

PolicyGenTemplate CR은 ./out/argocd/example/policygentemplates 폴더에 있습니다. 참조 아키텍처에는 공통, 그룹 및 사이트별 구성 CR이 있습니다. 각 PolicyGenTemplate CR은 ./out/source-crs 폴더에 있는 다른 CR을 나타냅니다.

아래에는 RAN 클러스터 구성과 관련된 PolicyGenTemplate CR에 대해 설명합니다. 변형은 단일 노드, 3 노드 컴팩트 및 표준 클러스터 구성의 차이를 설명하기 위해 PolicyGenTemplate CR 그룹에 제공됩니다. 마찬가지로 단일 노드 클러스터 및 다중 노드(영향 또는 표준) 클러스터에 사이트별 구성 변형이 제공됩니다. 배포와 관련된 그룹 및 사이트별 구성 변형을 사용합니다.

표 19.3. RAN 배포를 위한 PolicyGenTemplate CR

PolicyGenTemplate CR설명

example-multinode-site.yaml

다중 노드 클러스터에 적용할 CR 세트가 포함되어 있습니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다.

example-sno-site.yaml

단일 노드 OpenShift 클러스터에 적용되는 CR 세트가 포함되어 있습니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다.

common-ranGen.yaml

모든 클러스터에 적용되는 공통 RAN CR 세트를 포함합니다. 이러한 CR은 RAN 및 기본 클러스터 튜닝에 일반적인 클러스터 기능을 제공하는 일련의 Operator를 구독합니다.

group-du-3node-ranGen.yaml

3-노드 클러스터에 대한 RAN 정책만 포함합니다.

group-du-sno-ranGen.yaml

단일 노드 클러스터에 대한 RAN 정책만 포함합니다.

group-du-standard-ranGen.yaml

표준 세 개의 컨트롤 플레인 클러스터에 대한 RAN 정책을 포함합니다.

group-du-3node-validator-ranGen.yaml

3-노드 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 PolicyGenTemplate CR

group-du-standard-validator-ranGen.yaml

PolicyGenTemplate CR은 표준 클러스터에 필요한 다양한 정책을 생성하는 데 사용됩니다.

group-du-sno-validator-ranGen.yaml

PolicyGenTemplate CR은 단일 노드 OpenShift 클러스터에 필요한 다양한 정책을 생성하는 데 사용됩니다.

19.4.4. PolicyGenTemplate CR을 사용하여 관리형 클러스터 사용자 정의

다음 절차에 따라 zero touch provisioning(ZTP) 파이프라인을 사용하여 프로비저닝하는 관리형 클러스터에 적용되는 정책을 사용자 지정합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 필요한 설치 및 정책 CR을 생성하기 위해 hub 클러스터를 구성했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

절차

  1. 사이트별 구성 CR에 대한 PolicyGenTemplate CR을 생성합니다.

    1. out/argocd/example/policygentemplates 폴더(예: example-sno-site.yaml 또는 example-multinode-site.yaml )에서 CR에 대한 적절한 예를 선택합니다.
    2. 예제 파일의 바인딩Rules 필드를 site Config CR에 포함된 사이트별 레이블과 일치하도록 변경합니다. 예제 site Config 파일에서 사이트 별 레이블은 sites: example-sno 입니다.

      참고

      PolicyGenTemplate bindingRules 필드에 정의된 레이블이 관련 관리 클러스터 site Config CR에 정의된 라벨과 일치하는지 확인합니다.

    3. 예제 파일의 내용을 원하는 구성과 일치하도록 변경합니다.
  2. 선택 사항: 전체 클러스터에 적용되는 공통 구성 CR에 대해 PolicyGenTemplate CR을 생성합니다.

    1. out/argocd/example/policygentemplates 폴더에 있는 CR에 대한 적절한 예를 선택합니다(예: common-ranGen.yaml ).
    2. 예제 파일의 내용을 원하는 구성과 일치하도록 변경합니다.
  3. 선택 사항: 플롯의 특정 클러스터 그룹에 적용되는 모든 그룹 구성 CR에 대해 PolicyGenTemplate CR을 생성합니다.

    overlaid 사양 파일의 콘텐츠가 원하는 최종 상태와 일치하는지 확인합니다. out/source-crs 디렉터리에는 PolicyGenTemplate 템플릿에서 포함 및 덮어쓸 수 있는 source-crs의 전체 목록이 포함되어 있습니다.

    참고

    클러스터의 특정 요구 사항에 따라 클러스터 유형당 단일 그룹 정책이 필요할 수 있습니다. 특히 예제 그룹 정책에는 동일한 하드웨어 구성으로 구성된 클러스터 세트에서만 공유할 수 있는 단일 PerformancePolicy.yaml 파일이 있습니다.

    1. out/argocd/example/policygentemplates 폴더(예: group-du-sno-ranGen.yaml )에서 CR에 대한 적절한 예를 선택합니다.
    2. 예제 파일의 내용을 원하는 구성과 일치하도록 변경합니다.
  4. 선택사항입니다. 검증기를 생성하여 배포된 클러스터의 ZTP 설치 및 구성이 완료될 때 알리도록 정책 PolicyGenTemplate CR에 알릴 수 있습니다. 자세한 내용은 "Create a validator inform policy"를 참조하십시오.
  5. 예제 out/argocd/example/policygentemplates/ns.yaml 파일과 유사한 YAML 파일에 모든 정책 네임스페이스를 정의합니다.

    중요

    PolicyGenTemplate CR을 사용하여 동일한 파일에 Namespace CR을 포함하지 마십시오.

  6. out/argocd/example/policygentemplates/ kustomization.yaml 에 표시된 예제와 유사한 generators 섹션의 kustomization.yaml 파일에 PolicyGenTemplate CR 및 Namespace CR을 추가합니다.
  7. Git 리포지토리에 PolicyGenTemplate CR, 네임 스페이스 CR 및 관련 kustomization.yaml 파일을 커밋하고 변경 사항을 내보냅니다.

    ArgoCD 파이프라인은 변경 사항을 감지하고 관리형 클러스터 배포를 시작합니다. 변경 사항을 site Config CR 및 PolicyGenTemplate CR에 동시에 푸시할 수 있습니다.

19.4.5. 관리형 클러스터 정책 배포 진행 상황 모니터링

ArgoCD 파이프라인은 Git에서 PolicyGenTemplate CR을 사용하여 RHACM 정책을 생성한 다음 hub 클러스터에 동기화합니다. 지원 서비스가 관리형 클러스터에 OpenShift Container Platform을 설치한 후 관리형 클러스터 정책 동기화의 진행 상황을 모니터링할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

절차

  1. TALM(토폴로지 라이프사이클 관리자)은 클러스터에 바인딩된 구성 정책을 적용합니다.

    클러스터 설치가 완료되고 클러스터가 Ready 상태가 되면 이 클러스터에 해당하는 ClusterGroupUpgrade CR이 되며, ran.openshift.io/ztp-deploy-ECDHE 주석에 의해 정의된 정렬된 정책 목록이 TALM에 의해 자동으로 생성됩니다. 클러스터 정책은 ClusterGroupUpgrade CR에 나열된 순서대로 적용됩니다.

    다음 명령을 사용하여 구성 정책 조정의 상위 수준 진행 상황을 모니터링할 수 있습니다.

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq

    출력 예

    {
      "lastTransitionTime": "2022-11-09T07:28:09Z",
      "message": "The ClusterGroupUpgrade CR has upgrade policies that are still non compliant",
      "reason": "UpgradeNotCompleted",
      "status": "False",
      "type": "Ready"
    }

  2. RHACM 대시보드 또는 명령줄을 사용하여 자세한 클러스터 정책 준수 상태를 모니터링할 수 있습니다.

    1. oc 를 사용하여 정책 준수를 확인하려면 다음 명령을 실행합니다.

      $ oc get policies -n $CLUSTER

      출력 예

      NAME                                                     REMEDIATION ACTION   COMPLIANCE STATE   AGE
      ztp-common.common-config-policy                          inform               Compliant          3h42m
      ztp-common.common-subscriptions-policy                   inform               NonCompliant       3h42m
      ztp-group.group-du-sno-config-policy                     inform               NonCompliant       3h42m
      ztp-group.group-du-sno-validator-du-policy               inform               NonCompliant       3h42m
      ztp-install.example1-common-config-policy-pjz9s          enforce              Compliant          167m
      ztp-install.example1-common-subscriptions-policy-zzd9k   enforce              NonCompliant       164m
      ztp-site.example1-config-policy                          inform               NonCompliant       3h42m
      ztp-site.example1-perf-policy                            inform               NonCompliant       3h42m

    2. RHACM 웹 콘솔에서 정책 상태를 확인하려면 다음 작업을 수행합니다.

      1. 관리정책 찾기를 클릭합니다.
      2. 클러스터 정책을 클릭하여 상태를 확인합니다.

모든 클러스터 정책이 호환되면 클러스터의 ZTP 설치 및 구성이 완료됩니다. ztp-done 레이블이 클러스터에 추가되었습니다.

참조 구성에서 준수되는 최종 정책은 *-du-validator-policy 정책에 정의된 정책입니다. 이 정책은 클러스터를 준수할 때 모든 클러스터 구성, Operator 설치 및 Operator 설정이 완료되었는지 확인합니다.

19.4.6. 구성 정책 CR 생성 검증

정책 사용자 정의 리소스(CR)는 이들이 생성되는 PolicyGenTemplate 과 동일한 네임스페이스에 생성됩니다. 다음 명령을 사용하여 표시된 대로 동일한 문제 해결 흐름은 ztp-common,ztp-group 또는 ztp-site 기반 여부에 관계없이 PolicyGenTemplate 에서 생성된 모든 정책 CR에 적용됩니다.

$ export NS=<namespace>
$ oc get policy -n $NS

예상되는 정책 래핑된 CR 세트가 표시되어야 합니다.

정책이 동기화에 실패한 경우 다음 문제 해결 단계를 사용하십시오.

절차

  1. 정책에 대한 자세한 정보를 표시하려면 다음 명령을 실행합니다.

    $ oc describe -n openshift-gitops application policies
  2. 오류 로그를 표시하려면 Status: Conditions: 를 확인합니다. 예를 들어 잘못된 sourceFileECDHEfileName을 설정하면 아래와 같은 오류가 생성됩니다.

    Status:
      Conditions:
        Last Transition Time:  2021-11-26T17:21:39Z
        Message:               rpc error: code = Unknown desc = `kustomize build /tmp/https___git.com/ran-sites/policies/ --enable-alpha-plugins` failed exit status 1: 2021/11/26 17:21:40 Error could not find test.yaml under source-crs/: no such file or directory Error: failure in plugin configured via /tmp/kust-plugin-config-52463179; exit status 1: exit status 1
        Type:  ComparisonError
  3. Status: Sync:. Status: Conditions: 에 로그 오류가 있는 경우 Status: Sync: show Unknown 또는 Error:를 표시합니다.

    Status:
      Sync:
        Compared To:
          Destination:
            Namespace:  policies-sub
            Server:     https://kubernetes.default.svc
          Source:
            Path:             policies
            Repo URL:         https://git.com/ran-sites/policies/.git
            Target Revision:  master
        Status:               Error
  4. RHACM(Red Hat Advanced Cluster Management)에서 정책이 ManagedCluster 오브젝트에 적용되는 것을 인식하면 정책 CR 오브젝트가 클러스터 네임스페이스에 적용됩니다. 정책이 클러스터 네임스페이스에 복사되었는지 확인합니다.

    $ oc get policy -n $CLUSTER

    출력 예:

    NAME                                         REMEDIATION ACTION   COMPLIANCE STATE   AGE
    ztp-common.common-config-policy              inform               Compliant          13d
    ztp-common.common-subscriptions-policy       inform               Compliant          13d
    ztp-group.group-du-sno-config-policy         inform               Compliant          13d
    Ztp-group.group-du-sno-validator-du-policy   inform               Compliant          13d
    ztp-site.example-sno-config-policy           inform               Compliant          13d

    RHACM은 적용 가능한 모든 정책을 클러스터 네임스페이스에 복사합니다. 복사된 정책 이름에는 <policy GenTemplate.Namespace>.<policyGenTemplate.Name>-<policyName > 포멧이 있습니다.

  5. 클러스터 네임스페이스에 복사되지 않은 정책의 배치 규칙을 확인합니다. 해당 정책에 대한 PlacementRulematchSelectorManagedCluster 오브젝트의 라벨과 일치해야 합니다.

    $ oc get placementrule -n $NS
  6. 다음 명령을 사용하여 누락된 정책, 공통, 그룹 또는 사이트에 적합한 PlacementRule 이름을 기록해 둡니다.

    $ oc get placementrule -n $NS <placementRuleName> -o yaml
    • status-decisions에는 클러스터 이름이 포함되어야 합니다.
    • 사양에 있는 matchSelector 의 키-값 쌍은 관리 클러스터의 라벨과 일치해야 합니다.
  7. 다음 명령을 사용하여 ManagedCluster 오브젝트의 라벨을 확인합니다.

    $ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
  8. 다음 명령을 사용하여 호환되는 정책을 확인하십시오.

    $ oc get policy -n $CLUSTER

    Namespace,OperatorGroup, Subscription 정책이 준수하지만 Operator 구성 정책이 일치하지 않으면 Operator가 관리 클러스터에 설치되지 않은 것입니다. 이로 인해 CRD가 아직 스포크에 적용되지 않기 때문에 Operator 구성 정책이 적용되지 않습니다.

19.4.7. 정책 조정 다시 시작

예를 들어 ClusterGroupUpgrade CR(사용자 정의 리소스)이 시간 초과된 경우 예기치 않은 규정 준수 문제가 발생하면 정책 조정을 다시 시작할 수 있습니다.

절차

  1. 관리형 클러스터가 Ready 가 되면 Topology Aware Lifecycle Manager의 ztp-install 네임스페이스에 ClusterGroupUpgrade CR이 생성됩니다.

    $ export CLUSTER=<clusterName>
    $ oc get clustergroupupgrades -n ztp-install $CLUSTER
  2. 예기치 않은 문제가 있고 정책이 구성된 시간 내에 불만이 발생하지 않는 경우 (기본값은 4 시간) ClusterGroupUpgrade CR의 상태에 UpgradeTimedOut 이 표시됩니다.

    $ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
  3. UpgradeTimedOut 상태의 ClusterGroupUpgrade CR은 매시간마다 정책 조정을 자동으로 다시 시작합니다. 정책을 변경한 경우 기존 ClusterGroupUpgrade CR을 삭제하여 즉시 재시도를 시작할 수 있습니다. 이렇게 하면 정책을 즉시 조정하기 시작하는 새 ClusterGroupUpgrade CR의 자동 생성이 트리거됩니다.

    $ oc delete clustergroupupgrades -n ztp-install $CLUSTER

ClusterGroupUpgrade CR이 UpgradeCompleted 상태로 완료되고 관리 클러스터에 ztp-done 레이블이 적용된 경우 PolicyGenTemplate 을 사용하여 추가 구성을 변경할 수 있습니다. 기존 ClusterGroupUpgrade CR을 삭제하면 TALM이 새 CR이 생성되지 않습니다.

이 시점에서 ZTP는 클러스터와의 상호 작용을 완료했으며 추가 상호 작용을 업데이트로 처리하고 정책 수정을 위해 생성된 새로운 ClusterGroupUpgrade CR을 처리해야 합니다.

추가 리소스

19.4.8. ZTP 설치에 대한 표시

zero touch provisioning (ZTP)은 클러스터에 대한 ZTP 설치 상태를 확인하는 프로세스를 단순화합니다. ZTP 상태는 클러스터 설치, 클러스터 구성 및 ZTP 완료의 세 단계로 이동합니다.

클러스터 설치 단계
클러스터 설치 단계는 ManagedCluster CR의 ManagedCluster joinManagedClusterAvailable 조건에 의해 표시됩니다. ManagedCluster CR에 이러한 조건이 없거나 조건이 False 로 설정된 경우 클러스터는 여전히 설치 단계에 있습니다. 설치에 대한 자세한 내용은 AgentClusterInstallClusterDeployment CR에서 확인할 수 있습니다. 자세한 내용은 "Troubleshooting GitOps ZTP"를 참조하십시오.
클러스터 구성 단계
클러스터 구성 단계는 ztp-running 라벨에 클러스터의 ManagedCluster CR을 적용한 것으로 표시됩니다.
ZTP 완료

ZTP 완료 단계에서 클러스터 설치 및 구성이 완료됩니다. 이는 ztp-running 레이블을 제거하고 ManagedCluster CR에 ztp-done 레이블을 추가하여 표시됩니다. ztp-done 레이블은 구성이 적용되고 기본 DU 구성이 클러스터 튜닝을 완료했음을 보여줍니다.

ZTP done 상태로 전환하는 것은 RHACM(Red Hat Advanced Cluster Management) 유효성 검사기의 준수 상태에 대한 조건입니다. 이 정책은 완료된 설치에 대한 기존 기준을 캡처하고 관리 클러스터의 ZTP 프로비저닝이 완료된 경우에만 규정 준수 상태로 이동하는지 검증합니다.

유효성 검사기 알림 정책은 클러스터의 구성이 완전히 적용되고 Operator가 초기화를 완료했는지 확인합니다. 정책은 다음을 검증합니다.

  • 대상 MachineConfigPool 에는 예상 항목이 포함되어 있으며 업데이트가 완료되었습니다. 모든 노드를 사용할 수 있으며 성능이 저하되지 않습니다.
  • SR-IOV Operator는 syncStatus: Succeeded 와 함께 하나 이상의 SriovNetworkNodeState 에 표시된 대로 초기화를 완료했습니다.
  • PTP Operator 데몬 세트가 있습니다.

19.5. ZTP로 단일 노드 OpenShift 클러스터 수동 설치

RHACM(Red Hat Advanced Cluster Management) 및 지원 서비스를 사용하여 관리형 단일 노드 OpenShift 클러스터를 배포할 수 있습니다.

참고

여러 개의 관리형 클러스터를 생성하는 경우 ZTP와 함께 far edge 사이트 배포에 설명된 site Config 방법을 사용합니다.

중요

대상 베어 메탈 호스트는 vDU 애플리케이션 워크로드에 대한 권장 클러스터 구성에 나열된 네트워킹, 펌웨어 및 하드웨어 요구 사항을 충족해야 합니다.

19.5.1. 수동으로 ZTP 설치 및 구성 CR 생성

ztp-site-generate 컨테이너의 생성기 진입점을 사용하여 site ConfigPolicyGenTemplate CR을 기반으로 클러스터의 사이트 설치 및 구성 CR(사용자 정의 리소스)을 생성합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.

절차

  1. 다음 명령을 실행하여 출력 폴더를 생성합니다.

    $ mkdir -p ./out
  2. ztp-site-generate 컨테이너 이미지에서 argocd 디렉터리를 내보냅니다.

    $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.10 extract /home/ztp --tar | tar x -C ./out

    ./out 디렉터리에는 out/argocd/example/ 폴더에 참조 PolicyGenTemplateSiteConfig CR이 있습니다.

    출력 예

    out
     └── argocd
          └── example
               ├── policygentemplates
               │     ├── common-ranGen.yaml
               │     ├── example-sno-site.yaml
               │     ├── group-du-sno-ranGen.yaml
               │     ├── group-du-sno-validator-ranGen.yaml
               │     ├── kustomization.yaml
               │     └── ns.yaml
               └── siteconfig
                      ├── example-sno.yaml
                      ├── KlusterletAddonConfigOverride.yaml
                      └── kustomization.yaml

  3. 사이트 설치 CR의 출력 폴더를 생성합니다.

    $ mkdir -p ./site-install
  4. 설치하려는 클러스터 유형의 SiteConfig CR 예제를 수정합니다. example-sno.yamlsite-1-sno.yaml 에 복사하고 CR을 수정하여 설치하려는 사이트 및 베어 메탈 호스트의 세부 정보와 일치하도록 수정합니다.

    단일 노드 OpenShift 클러스터 siteConfig CR의 예

    apiVersion: ran.openshift.io/v1
    kind: SiteConfig
    metadata:
      name: "<site_name>"
      namespace: "<site_name>"
    spec:
      baseDomain: "example.com"
      pullSecretRef:
        name: "assisted-deployment-pull-secret" 1
      clusterImageSetNameRef: "openshift-4.10" 2
      sshPublicKey: "ssh-rsa AAAA..." 3
      clusters:
      - clusterName: "<site_name>"
        networkType: "OVNKubernetes"
        clusterLabels: 4
          common: true
          group-du-sno: ""
          sites : "<site_name>"
        clusterNetwork:
          - cidr: 1001:1::/48
            hostPrefix: 64
        machineNetwork:
          - cidr: 1111:2222:3333:4444::/64
        serviceNetwork:
          - 1001:2::/112
        additionalNTPSources:
          - 1111:2222:3333:4444::2
        #crTemplates:
        #  KlusterletAddonConfig: "KlusterletAddonConfigOverride.yaml" 5
        nodes:
          - hostName: "example-node.example.com" 6
            role: "master"
            #biosConfigRef:
            #  filePath: "example-hw.profile" 7
            bmcAddress: idrac-virtualmedia://<out_of_band_ip>/<system_id>/ 8
            bmcCredentialsName:
              name: "bmh-secret" 9
            bootMACAddress: "AA:BB:CC:DD:EE:11"
            bootMode: "UEFI" 10
            rootDeviceHints:
              wwn: "0x11111000000asd123"
            cpuset: "0-1,52-53"
            nodeNetwork: 11
              interfaces:
                - name: eno1
                  macAddress: "AA:BB:CC:DD:EE:11"
              config:
                interfaces:
                  - name: eno1
                    type: ethernet
                    state: up
                    ipv4:
                      enabled: false
                    ipv6: 12
                      enabled: true
                      address:
                      - i