17.9. PolicyGenTemplate 리소스를 사용한 고급 관리형 클러스터 구성

PolicyGenTemplate CR을 사용하여 관리 클러스터에 사용자 정의 기능을 배포할 수 있습니다.

17.9.1. 클러스터에 추가 변경 사항 배포

기본 GitOps ZTP 파이프라인 구성 외부에서 클러스터 구성을 변경해야 하는 경우 다음 세 가지 옵션이 있습니다.

ZTP 파이프라인이 완료된 후 추가 설정 적용
GitOps ZTP 파이프라인 배포가 완료되면 배포된 클러스터는 애플리케이션 워크로드에 사용할 수 있습니다. 이 시점에서 추가 Operator를 설치하고 요구 사항에 맞는 구성을 적용할 수 있습니다. 추가 구성이 플랫폼 성능 또는 할당된 CPU 예산에 부정적인 영향을 미치지 않도록 합니다.
ZTP 라이브러리에 콘텐츠 추가
GitOps ZTP 파이프라인을 사용하여 배포하는 기본 소스 CR(사용자 정의 리소스)은 필요에 따라 사용자 정의 콘텐츠로 보강될 수 있습니다.
클러스터 설치에 대한 추가 매니페스트 생성
추가 매니페스트는 설치 중에 적용되며 설치 프로세스를 보다 효율적으로 수행할 수 있습니다.
중요

추가 소스 CR을 제공하거나 기존 소스 CR을 수정하면 OpenShift Container Platform의 성능 또는 CPU 프로파일에 심각한 영향을 미칠 수 있습니다.

추가 리소스

17.9.2. PolicyGenTemplate CR을 사용하여 소스 CR 콘텐츠 재정의

PolicyGenTemplate 사용자 정의 리소스(CR)를 사용하면 ztp-site-generate 컨테이너에서 GitOps 플러그인과 함께 제공되는 기본 소스 CR 상단에 추가 구성 세부 정보를 오버레이할 수 있습니다. PolicyGenTemplate CR을 기본 CR에 대한 논리 병합 또는 패치로 간주할 수 있습니다. PolicyGenTemplate CR을 사용하여 기본 CR의 단일 필드를 업데이트하거나 기본 CR의 전체 콘텐츠를 오버레이합니다. 기본 CR에 없는 값 및 삽입 필드를 업데이트할 수 있습니다.

다음 예제 절차에서는 group-du-sno-ranGen.yaml 파일의 PolicyGenTemplate CR을 기반으로 참조 구성에 대해 생성된 PerformanceProfile CR의 필드를 업데이트하는 방법을 설명합니다. 이 절차는 요구 사항에 따라 PolicyGenTemplate 의 다른 부분을 수정하기 위한 기초로 사용하십시오.

사전 요구 사항

  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD의 소스 리포지토리로 정의해야 합니다.

절차

  1. 기존 콘텐츠의 기준 소스 CR을 검토합니다. 제로 대화 프로비저닝 (ZTP) 컨테이너에서 추출하여 참조 PolicyGenTemplate CR에 나열된 소스 CR을 검토할 수 있습니다.

    1. /out 폴더를 생성합니다.

      $ mkdir -p ./out
    2. 소스 CR을 추출합니다.

      $ podman run --log-driver=none --rm registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12.1 extract /home/ztp --tar | tar x -C ./out
  2. ./out/source-crs/ PerformanceProfile.yaml 에서 기준 PerformanceProfile CR을 검토합니다.

    apiVersion: performance.openshift.io/v2
    kind: PerformanceProfile
    metadata:
      name: $name
      annotations:
        ran.openshift.io/ztp-deploy-wave: "10"
    spec:
      additionalKernelArgs:
      - "idle=poll"
      - "rcupdate.rcu_normal_after_boot=0"
      cpu:
        isolated: $isolated
        reserved: $reserved
      hugepages:
        defaultHugepagesSize: $defaultHugepagesSize
        pages:
          - size: $size
            count: $count
            node: $node
      machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/$mcp: ""
      net:
        userLevelNetworking: true
      nodeSelector:
        node-role.kubernetes.io/$mcp: ''
      numa:
        topologyPolicy: "restricted"
      realTimeKernel:
        enabled: true
    참고

    $…​ 가 포함된 소스 CR의 필드는 PolicyGenTemplate CR에 제공되지 않는 경우 생성된 CR에서 제거됩니다.

  3. group-du-sno-ranGen.yaml 참조 파일에서 PerformanceProfilePolicyGenTemplate 항목을 업데이트합니다. 다음 예제 PolicyGenTemplate CR 스탠자는 적절한 CPU 사양을 제공하고, hugepages 구성을 설정하고, globallyDisableIrqLoadBalancing 을 false로 설정하는 새 필드를 추가합니다.

    - fileName: PerformanceProfile.yaml
      policyName: "config-policy"
      metadata:
        name: openshift-node-performance-profile
      spec:
        cpu:
          # These must be tailored for the specific hardware platform
          isolated: "2-19,22-39"
          reserved: "0-1,20-21"
        hugepages:
          defaultHugepagesSize: 1G
          pages:
            - size: 1G
              count: 10
        globallyDisableIrqLoadBalancing: false
  4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP argo CD 애플리케이션에서 모니터링 중인 Git 리포지토리로 내보냅니다.

출력 예

ZTP 애플리케이션은 생성된 PerformanceProfile CR을 포함하는 RHACM 정책을 생성합니다. PolicyGenTemplatePerformanceProfile 항목의 metadataspec 콘텐츠를 소스 CR에 병합하여 해당 CR의 콘텐츠를 파생시킵니다. 결과 CR에는 다음 내용이 있습니다.

---
apiVersion: performance.openshift.io/v2
kind: PerformanceProfile
metadata:
    name: openshift-node-performance-profile
spec:
    additionalKernelArgs:
        - idle=poll
        - rcupdate.rcu_normal_after_boot=0
    cpu:
        isolated: 2-19,22-39
        reserved: 0-1,20-21
    globallyDisableIrqLoadBalancing: false
    hugepages:
        defaultHugepagesSize: 1G
        pages:
            - count: 10
              size: 1G
    machineConfigPoolSelector:
        pools.operator.machineconfiguration.openshift.io/master: ""
    net:
        userLevelNetworking: true
    nodeSelector:
        node-role.kubernetes.io/master: ""
    numa:
        topologyPolicy: restricted
    realTimeKernel:
        enabled: true
참고

ztp-site-generate 컨테이너에서 추출한 /source-crs 폴더의 경우 구문에 따라 템플릿 대체에 $ 구문이 사용되지 않습니다. 대신 policyGen 툴이 문자열에 대한 $ 접두사를 확인하고 관련 PolicyGenTemplate CR에서 해당 필드에 대한 값을 지정하지 않으면 해당 필드가 출력 CR에서 완전히 생략됩니다.

이 예외는 PolicyGenTemplate CR에서 mcp 에 지정된 값으로 대체되는 /source-crs YAML 파일의 $mcp 변수입니다. 예를 들어 example/policygentemplates/group-du-standard-ranGen.yaml 에서 mcpworker 입니다.

spec:
  bindingRules:
    group-du-standard: ""
  mcp: "worker"

policyGen 툴은 출력 CR에서 $mcp 의 인스턴스를 worker 로 바꿉니다.

17.9.3. GitOps ZTP 파이프라인에 새 콘텐츠 추가

GitOps ZTP 사이트 생성기 컨테이너의 소스 CR에서는 RAN Distributed Unit (DU) 애플리케이션에 대한 일련의 중요한 기능 및 노드 튜닝 설정을 제공합니다. 이는 ZTP로 배포하는 클러스터에 적용됩니다. ztp-site-generate 컨테이너에서 기존 소스 CR을 추가하거나 수정하려면 ztp-site-generate 컨테이너를 다시 빌드하고 hub 클러스터에서 (일반적으로 hub 클러스터와 연결된 연결 해제된 레지스트리에서 사용할 수 있도록 합니다. 유효한 OpenShift Container Platform CR을 추가할 수 있습니다.

다음 절차에 따라 ZTP 파이프라인에 새 콘텐츠를 추가합니다.

절차

  1. 업데이트된 ztp-site-generate 컨테이너에 포함할 Containerfile 및 소스 CR YAML 파일이 포함된 디렉터리를 생성합니다. 예를 들면 다음과 같습니다.

    ztp-update/
    ├── example-cr1.yaml
    ├── example-cr2.yaml
    └── ztp-update.in
  2. ztp-update.in Containerfile에 다음 내용을 추가합니다.

    FROM registry.redhat.io/openshift4/ztp-site-generate-rhel8:v4.12
    
    ADD example-cr2.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
    ADD example-cr1.yaml /kustomize/plugin/ran.openshift.io/v1/policygentemplate/source-crs/
  3. ztp-update/ 디렉터리에서 터미널을 열고 컨테이너를 다시 빌드합니다.

    $ podman build -t ztp-site-generate-rhel8-custom:v4.12-custom-1
  4. 빌드된 컨테이너 이미지를 연결이 끊긴 레지스트리로 푸시합니다. 예를 들면 다음과 같습니다.

    $ podman push localhost/ztp-site-generate-rhel8-custom:v4.12-custom-1 registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.12-custom-1
  5. hub 클러스터에서 Argo CD 인스턴스를 패치하여 새로 빌드된 컨테이너 이미지를 가리킵니다.

    $ oc patch -n openshift-gitops argocd openshift-gitops --type=json -p '[{"op": "replace", "path":"/spec/repo/initContainers/0/image", "value": "registry.example.com:5000/ztp-site-generate-rhel8-custom:v4.12-custom-1"} ]'

    Argo CD 인스턴스가 패치되면 openshift-gitops-repo-server Pod가 자동으로 다시 시작됩니다.

검증

  1. openshift-gitops-repo-server Pod가 초기화를 완료하고 이전 리포지토리 Pod가 종료되었는지 확인합니다.

    $ oc get pods -n openshift-gitops | grep openshift-gitops-repo-server

    출력 예

    openshift-gitops-server-7df86f9774-db682          1/1     Running   	     1          28s

    새로 추가된 컨테이너 이미지 콘텐츠를 사용할 수 있기 전에 새 openshift-gitops-repo-server Pod가 초기화를 완료하고 이전 Pod가 종료될 때까지 기다려야 합니다.

추가 리소스

  • 또는 패치 파일을 적용하기 전에 업데이트된 initContainer 이미지로 argocd-openshift-gitops-patch.json 을 수정하여 ArgoCD를 사용하여 hub 클러스터 구성에 설명된 대로 ArgoCD 인스턴스를 패치할 수 있습니다.

17.9.4. PolicyGenTemplate CR에 대한 정책 준수 평가 타임아웃 구성

관리 클러스터가 적용된 정책을 준수하는지 여부를 모니터링 및 보고하려면 hub 클러스터에 설치된 RHACM(Red Hat Advanced Cluster Management)을 사용합니다. RHACM은 정책 템플릿을 사용하여 사전 정의된 정책 컨트롤러 및 정책을 적용합니다. 정책 컨트롤러는 Kubernetes CRD(사용자 정의 리소스 정의) 인스턴스입니다.

기본 정책 평가 간격은 PolicyGenTemplate CR(사용자 정의 리소스)으로 덮어쓸 수 있습니다. RHACM이 적용된 클러스터 정책을 다시 평가하기 전에 ConfigurationPolicy CR의 상태가 정책 준수 또는 비준수 상태에 있는 기간을 정의하는 기간 설정을 구성합니다.

zero touch provisioning (ZTP) 정책 생성기는 사전 정의된 정책 평가 간격을 사용하여 ConfigurationPolicy CR 정책을 생성합니다. 비호환 상태의 기본값은 10초입니다. 준수 상태의 기본값은 10분입니다. 평가 간격을 비활성화하려면 값을 never 로 설정합니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

절차

  1. PolicyGenTemplate CR에서 모든 정책에 대한 평가 간격을 구성하려면 spec 필드에 evaluationInterval 을 추가한 다음 적절한 준수비준수 값을 설정합니다. 예를 들면 다음과 같습니다.

    spec:
      evaluationInterval:
        compliant: 30m
        noncompliant: 20s
  2. PolicyGenTemplate CR에서 spec.sourceFiles 오브젝트에 대한 평가 간격을 구성하려면 evaluationIntervalsourceFiles 필드에 추가합니다. 예를 들면 다음과 같습니다.

    spec:
      sourceFiles:
       - fileName: SriovSubscription.yaml
         policyName: "sriov-sub-policy"
         evaluationInterval:
           compliant: never
           noncompliant: 10s
  3. Git 리포지토리에서 PolicyGenTemplate CR 파일을 커밋하고 변경 사항을 내보냅니다.

검증

관리형 스포크 클러스터 정책이 예상 간격으로 모니터링되는지 확인합니다.

  1. 관리형 클러스터에서 cluster-admin 권한이 있는 사용자로 로그인합니다.
  2. open-cluster-management-agent-addon 네임스페이스에서 실행 중인 pod를 가져옵니다. 다음 명령을 실행합니다.

    $ oc get pods -n open-cluster-management-agent-addon

    출력 예

    NAME                                         READY   STATUS    RESTARTS        AGE
    config-policy-controller-858b894c68-v4xdb    1/1     Running   22 (5d8h ago)   10d

  3. config-policy-controller Pod에 대한 로그의 예상 간격으로 적용된 정책이 평가되고 있는지 확인합니다.

    $ oc logs -n open-cluster-management-agent-addon config-policy-controller-858b894c68-v4xdb

    출력 예

    2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-config-policy-config"}
    2022-05-10T15:10:25.280Z       info   configuration-policy-controller controllers/configurationpolicy_controller.go:166      Skipping the policy evaluation due to the policy not reaching the evaluation interval  {"policy": "compute-1-common-compute-1-catalog-policy-config"}

17.9.5. 검증기를 사용하여 ZTP 클러스터 배포가 완료되었음을 알릴 수 있습니다.

유효성 검사기를 생성하면 배포된 클러스터의 설치 및 구성이 완료될 때 null touch 프로비저닝(ZTP)이 완료되면 신호를 알리는 정책을 알릴 수 있습니다. 이 정책은 단일 노드 OpenShift 클러스터, 3 노드 클러스터 및 표준 클러스터의 배포에 사용할 수 있습니다.

절차

  1. 소스 파일 validatorCRs/informDuValidator.yaml 을 포함하는 독립 실행형 PolicyGenTemplate 사용자 정의 리소스(CR)를 생성합니다. 각 클러스터 유형에 대해 하나의 독립 실행형 PolicyGenTemplate CR만 있으면 됩니다. 예를 들어, 이 CR은 단일 노드 OpenShift 클러스터에 대한 검증기를 적용합니다.

    예제 single-node 클러스터 검증기에서는 정책 CR을 알립니다 (group-du-sno-validator-ranGen.yaml).

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "group-du-sno-validator" 1
      namespace: "ztp-group" 2
    spec:
      bindingRules:
        group-du-sno: "" 3
      bindingExcludedRules:
        ztp-done: "" 4
      mcp: "master" 5
      sourceFiles:
        - fileName: validatorCRs/informDuValidator.yaml
          remediationAction: inform 6
          policyName: "du-policy" 7

    1
    PolicyGenTemplates 개체의 이름입니다. 이 이름은 요청된 네임스페이스에서 생성된 placementBinding,placementRule정책 의 일부로 사용됩니다.
    2
    이 값은 PolicyGenTemplates 그룹에 사용된 네임스페이스 와 일치해야 합니다.
    3
    bindingRules 에 정의된 group-du-* 레이블은 SiteConfig 파일에 있어야 합니다.
    4
    bindingExcludedRules 에 정의된 레이블은 'ztp-done:'이어야 합니다. ztp-done 레이블은 토폴로지 Aware Lifecycle Manager와 조정하는 데 사용됩니다.
    5
    MCP 는 소스 파일 validatorCRs/informDuValidator.yaml 에 사용되는 MachineConfigPool 오브젝트를 정의합니다. 단일 노드 및 표준 클러스터 배포의 경우 3노드 클러스터 배포 및 작업자마스터 여야 합니다.
    6
    선택 사항: 기본값은 inform 입니다.
    7
    이 값은 생성된 RHACM 정책의 이름으로 사용됩니다. 단일 노드 예제에 대해 생성된 검증기 정책은 group-du-sno-validator-du-policy 입니다.
  2. Git 리포지토리에서 PolicyGenTemplate CR 파일을 커밋하고 변경 사항을 내보냅니다.

추가 리소스

17.9.6. PolicyGenTemplate CR을 사용하여 PTP 빠른 이벤트 구성

GitOps Zero touch Provisioning(ZTP) 파이프라인을 사용하여 배포된 vRAN 클러스터에 대한 PTP 빠른 이벤트를 구성할 수 있습니다. PolicyGenTemplate 사용자 정의 리소스(CR)를 기반으로 사용하여 특정 사이트 요구 사항에 맞게 구성 파일의 계층 구조를 생성합니다.

사전 요구 사항

  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다.

절차

  1. common-ranGen.yaml 파일의 .spec.sourceFiles 에 다음 YAML을 추가하여 AMQP Operator를 구성합니다.

    #AMQ interconnect operator for fast events
    - fileName: AmqSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscription.yaml
      policyName: "subscriptions-policy"
  2. 요구 사항에 따라 group-du-3node-ranGen.yaml,group-du-sno-ranGen.yaml 또는 group-du-standard-ranGen.yaml 파일에 다음 Policy Gen 변경 사항을 적용합니다.

    1. .sourceFiles.sourceFiles에서 AMQ 전송 호스트를 config-policy 로 구성하는 PtpOperatorConfig CR 파일을 추가합니다.

      - fileName: PtpOperatorConfigForEvent.yaml
        policyName: "config-policy"
    2. PTP 클럭 유형 및 인터페이스에 linuxptpphc2sys 를 구성합니다. 예를 들어 .sourceFiles 에 다음 스탠자를 추가합니다.

      - fileName: PtpConfigSlave.yaml 1
        policyName: "config-policy"
        metadata:
          name: "du-ptp-slave"
        spec:
          profile:
          - name: "slave"
            interface: "ens5f1" 2
            ptp4lOpts: "-2 -s --summary_interval -4" 3
            phc2sysOpts: "-a -r -m -n 24 -N 8 -R 16" 4
          ptpClockThreshold: 5
            holdOverTimeout: 30 #secs
            maxOffsetThreshold: 100  #nano secs
            minOffsetThreshold: -100 #nano secs
      1
      요구 사항에 따라 PtpConfigMaster.yaml,PtpConfigSlave.yaml 또는 PtpConfigSlaveCvl.yaml 하나가 될 수 있습니다. PtpConfigSlaveCvl.yaml 은 Intel E810 Columbiaville NIC에 대해 linuxptp 서비스를 구성합니다. group-du-sno-ranGen.yaml 또는 group-du-3node-ranGen.yaml 을 기반으로 하는 구성의 경우 PtpConfigSlave.yaml 을 사용합니다.
      2
      장치별 인터페이스 이름입니다.
      3
      PTP 빠른 이벤트를 활성화하려면 .spec.sourceFiles.spec.profile--summary_interval -4 값을 ptp4lOpts 에 추가해야 합니다.
      4
      필수 phc2sysOpts 값. -mstdout 에 메시지를 출력합니다. linuxptp-daemon DaemonSet 은 로그를 구문 분석하고 Prometheus 지표를 생성합니다.
      5
      선택 사항: ptpClockThreshold 가 없으면 기본값이 ptpClockThreshold 필드에 사용됩니다. 스탠자는 기본 ptpClockThreshold 값을 표시합니다. ptpClockThreshold 값은 PTP 이벤트가 트리거되기 전에 PTP 마스터 클럭이 연결 해제된 후의 기간을 구성합니다. holdOverTimeout 은 PTP 마스터 클럭의 연결이 끊어지면 PTP 클럭 이벤트 상태가 FREERUN 로 변경되기 전 시간(초)입니다. maxOffsetThresholdminOffsetThreshold 설정은 CLOCK_REALTIME (phc2sys) 또는 마스터 오프셋(ptp4l)의 값과 비교되는 나노초에 오프셋 값을 구성합니다. ptp4l 또는 phc2sys 오프셋 값이 이 범위를 벗어나는 경우 PTP 클럭 상태가 FREERUN 로 설정됩니다. 오프셋 값이 이 범위 내에 있으면 PTP 클럭 상태가 LOCKED 로 설정됩니다.
  3. 특정 사이트 YAML 파일에 다음 PolicyGenTemplate 변경 사항을 적용합니다(예: example-sno-site.yaml ).

    1. .sourceFiles.sourceFiles에서 AMQ 라우터를 config-policy 에 구성하는 Interconnect CR 파일을 추가합니다.

      - fileName: AmqInstance.yaml
        policyName: "config-policy"
  4. 다른 필요한 변경 사항 및 파일을 사용자 지정 사이트 리포지토리와 병합합니다.
  5. 사이트 구성 리포지토리의 변경 사항을 내보내 GitOps ZTP를 사용하여 PTP 빠른 이벤트를 새 사이트에 배포합니다.

추가 리소스

17.9.7. 이미지 로컬 캐싱을 위해 이미지 레지스트리 Operator 구성

OpenShift Container Platform은 로컬 레지스트리를 사용하여 이미지 캐싱을 관리합니다. 엣지 컴퓨팅 사용 사례에서 클러스터는 종종 중앙 집중식 이미지 레지스트리와 통신할 때 대역폭 제한의 영향을 받으며 이로 인해 이미지 다운로드 시간이 길어질 수 있습니다.

초기 배포 중에 긴 다운로드 시간은 피할 수 없습니다. 시간이 지남에 따라 CRI-O가 예기치 않은 종료의 경우 /var/lib/containers/storage 디렉터리를 해제할 위험이 있습니다. 긴 이미지 다운로드 시간을 해결하기 위해 GitOps ZTP를 사용하여 원격 관리 클러스터에 로컬 이미지 레지스트리를 생성할 수 있습니다. 이는 클러스터가 네트워크의 맨 에지에 배포되는 에지 컴퓨팅 시나리오에서 유용합니다.

GitOps ZTP를 사용하여 로컬 이미지 레지스트리를 설정하려면 먼저 원격 관리 클러스터를 설치하는 데 사용하는 site Config CR에 디스크 파티셔닝을 구성해야 합니다. 설치한 후 PolicyGenTemplate CR을 사용하여 로컬 이미지 레지스트리를 구성합니다. 그런 다음 ZTP 파이프라인에서 영구 볼륨(PV) 및 PVC(영구 볼륨 클레임) CR을 생성하고 imageregistry 구성을 패치합니다.

참고

로컬 이미지 레지스트리는 사용자 애플리케이션 이미지에만 사용할 수 있으며 OpenShift Container Platform 또는 Operator Lifecycle Manager Operator 이미지에는 사용할 수 없습니다.

추가 리소스

17.9.8. PolicyGenTemplate CR을 사용하여 베어 메탈 이벤트 구성

17.9.8.1. siteConfig를 사용하여 디스크 파티션 구성

site Config CR 및 GitOps ZTP를 사용하여 관리형 클러스터에 대한 디스크 파티션을 구성합니다. site Config CR의 디스크 파티션 세부 정보가 기본 디스크와 일치해야 합니다.

참고

/dev/sda/dev/sdb 와 같은 장치 이름이 재부팅될 때마다 전환되지 않도록 장치에 영구 이름을 사용합니다. rootDeviceHints 를 사용하여 부팅 가능한 장치를 선택한 다음 추가 파티셔닝에 동일한 장치를 사용할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • GitOps ZeroECDHE Provisioning(ZTP)과 함께 사용할 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

절차

  1. 관리 클러스터를 설치하는 데 사용하는 site Config CR에 호스트 디스크 파티셔닝을 설명하는 다음 YAML을 추가합니다.

    nodes:
        rootDeviceHints:
          wwn: "0x62cea7f05c98c2002708a0a22ff480ea"
        diskPartition:
          - device: /dev/disk/by-id/wwn-0x62cea7f05c98c2002708a0a22ff480ea 1
            partitions:
              - mount_point: /var/imageregistry
                size: 102500 2
                start: 344844 3
    1
    이 설정은 하드웨어에 따라 다릅니다. 설정은 일련 번호 또는 장치 이름일 수 있습니다. 값은 rootDeviceHints 에 설정된 값과 일치해야 합니다.
    2
    size 의 최소 값은 102500MiB입니다.
    3
    start 의 최소 값은 25000MiB입니다. sizestart 의 총 값이 디스크 크기를 초과하지 않아야 합니다. 그러지 않으면 설치에 실패합니다.
  2. site Config CR을 저장하고 사이트 구성 리포지토리에 내보냅니다.

ZTP 파이프라인은 site Config CR을 사용하여 클러스터를 프로비저닝하고 디스크 파티션을 구성합니다.

17.9.8.2. PolicyGenTemplate CR을 사용하여 이미지 레지스트리 구성

PolicyGenTemplate (PGT) CR을 사용하여 이미지 레지스트리를 구성하고 imageregistry 구성을 패치하는 데 필요한 CR을 적용합니다.

사전 요구 사항

  • 관리 클러스터에서 디스크 파티션을 구성했습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • GitOps ZeroECDHE Provisioning(ZTP)과 함께 사용할 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다.

절차

  1. 적절한 PolicyGenTemplate CR에서 스토리지 클래스, 영구 볼륨 클레임, 영구 볼륨 및 이미지 레지스트리 구성을 구성합니다. 예를 들어 개별 사이트를 구성하려면 다음 YAML을 example-sno-site.yaml 파일에 추가합니다.

    sourceFiles:
      # storage class
      - fileName: StorageClass.yaml
        policyName: "sc-for-image-registry"
        metadata:
          name: image-registry-sc
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100" 1
      # persistent volume claim
      - fileName: StoragePVC.yaml
        policyName: "pvc-for-image-registry"
        metadata:
          name: image-registry-pvc
          namespace: openshift-image-registry
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
        spec:
          accessModes:
            - ReadWriteMany
          resources:
            requests:
              storage: 100Gi
          storageClassName: image-registry-sc
          volumeMode: Filesystem
      # persistent volume
      - fileName: ImageRegistryPV.yaml 2
        policyName: "pv-for-image-registry"
        metadata:
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
      - fileName: ImageRegistryConfig.yaml
        policyName: "config-for-image-registry"
        complianceType: musthave
        metadata:
          annotations:
            ran.openshift.io/ztp-deploy-wave: "100"
        spec:
          storage:
            pvc:
              claim: "image-registry-pvc"
    1
    사이트, 공통 또는 그룹 수준에서 이미지 레지스트리를 구성하는지 여부에 따라 ztp-deploy- ECDHE에 적절한 값을 설정합니다. ZTP-deploy-ECDHE: "100" 은 참조된 소스 파일을 함께 그룹화할 수 있기 때문에 개발 또는 테스트에 적합합니다.
    2
    ImageRegistryPV.yaml 에서 spec.local.path 필드가 site Config CR의 mount_point 필드에 설정된 값과 일치하도록 spec.local.path 필드가 /var/imageregistry 로 설정되어 있는지 확인합니다.
    중요

    - fileName: ImageRegistryConfig.yaml 구성에 complianceType: mustonlyhave 를 설정하지 마십시오. 이로 인해 레지스트리 Pod 배포가 실패할 수 있습니다.

  2. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 GitOps ZTP ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

검증

다음 단계를 사용하여 관리 클러스터의 로컬 이미지 레지스트리의 오류 문제를 해결합니다.

  • 관리형 클러스터에 로그인하는 동안 레지스트리에 성공적으로 로그인했는지 확인합니다. 다음 명령을 실행합니다.

    1. 관리형 클러스터 이름을 내보냅니다.

      $ cluster=<managed_cluster_name>
    2. 관리형 클러스터 kubeconfig 세부 정보를 가져옵니다.

      $ oc get secret -n $cluster $cluster-admin-password -o jsonpath='{.data.password}' | base64 -d > kubeadmin-password-$cluster
    3. 클러스터 kubeconfig 를 다운로드하여 내보냅니다.

      $ oc get secret -n $cluster $cluster-admin-kubeconfig -o jsonpath='{.data.kubeconfig}' | base64 -d > kubeconfig-$cluster && export KUBECONFIG=./kubeconfig-$cluster
    4. 관리 클러스터에서 이미지 레지스트리에 대한 액세스를 확인합니다. " registry 액세스"를 참조하십시오.
  • imageregistry.operator.openshift.io 그룹의 Config CRD에서 오류를 보고하지 않는지 확인합니다. 관리형 클러스터에 로그인하는 동안 다음 명령을 실행합니다.

    $ oc get image.config.openshift.io cluster -o yaml

    출력 예

    apiVersion: config.openshift.io/v1
    kind: Image
    metadata:
      annotations:
        include.release.openshift.io/ibm-cloud-managed: "true"
        include.release.openshift.io/self-managed-high-availability: "true"
        include.release.openshift.io/single-node-developer: "true"
        release.openshift.io/create-only: "true"
      creationTimestamp: "2021-10-08T19:02:39Z"
      generation: 5
      name: cluster
      resourceVersion: "688678648"
      uid: 0406521b-39c0-4cda-ba75-873697da75a4
    spec:
      additionalTrustedCA:
        name: acm-ice

  • 관리형 클러스터의 PersistentVolumeClaim 이 데이터로 채워졌는지 확인합니다. 관리형 클러스터에 로그인하는 동안 다음 명령을 실행합니다.

    $ oc get pv image-registry-sc
  • registry* pod가 실행 중이며 openshift-image-registry 네임스페이스에 있는지 확인합니다.

    $ oc get pods -n openshift-image-registry | grep registry*

    출력 예

    cluster-image-registry-operator-68f5c9c589-42cfg   1/1     Running     0          8d
    image-registry-5f8987879-6nx6h                     1/1     Running     0          8d

  • 관리 클러스터의 디스크 파티션이 올바른지 확인합니다.

    1. 관리형 클러스터에 대한 디버그 쉘을 엽니다.

      $ oc debug node/sno-1.example.com
    2. lsblk 를 실행하여 호스트 디스크 파티션을 확인합니다.

      sh-4.4# lsblk
      NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
      sda      8:0    0 446.6G  0 disk
        |-sda1   8:1    0     1M  0 part
        |-sda2   8:2    0   127M  0 part
        |-sda3   8:3    0   384M  0 part /boot
        |-sda4   8:4    0 336.3G  0 part /sysroot
        `-sda5   8:5    0 100.1G  0 part /var/imageregistry 1
      sdb      8:16   0 446.6G  0 disk
      sr0     11:0    1   104M  0 rom
      1
      /var/imageregistry 는 디스크가 올바르게 분할되었음을 나타냅니다.

추가 리소스

17.9.9. PolicyGenTemplate CR을 사용하여 베어 메탈 이벤트 모니터링 구성

GitOps Zero touch Provisioning(ZTP) 파이프라인을 사용하여 배포된 vRAN 클러스터에 대해 베어 메탈 하드웨어 이벤트를 구성할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.
  • 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성합니다.

절차

  1. AMQ Interconnect Operator 및 Bare Metal Event Relay Operator를 구성하려면 common-ranGen.yaml 파일의 spec.sourceFiles 에 다음 YAML을 추가합니다.

    # AMQ interconnect operator for fast events
    - fileName: AmqSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: AmqSubscription.yaml
      policyName: "subscriptions-policy"
    # Bare Metal Event Rely operator
    - fileName: BareMetalEventRelaySubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: BareMetalEventRelaySubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: BareMetalEventRelaySubscription.yaml
      policyName: "subscriptions-policy"
  2. 사이트 구성 파일의 .spec.sourceFilesInterconnect CR을 추가합니다(예: example-sno-site.yaml 파일).

    - fileName: AmqInstance.yaml
      policyName: "config-policy"
  3. 특정 그룹 구성 파일의 spec.sourceFiles (예: group-du-sno-ranGen.yaml 파일에서 spec.sourceFiles)에 HardwareEvent CR을 추가합니다.

    - fileName: HardwareEvent.yaml
      policyName: "config-policy"
      spec:
        nodeSelector: {}
        transportHost: "amqp://<amq_interconnect_name>.<amq_interconnect_namespace>.svc.cluster.local" 1
        logLevel: "info"
    1
    transportHost URL은 기존 AMQ Interconnect CR 이름과 네임스페이스 로 구성됩니다. 예를 들어 transportHost: "amqp://amq-router.amq-router.svc.cluster.local" 에서 AMQ Interconnect 이름은 둘 다 amq-router 로 설정됩니다.
    참고

    각 BMC(Baseboard Management Controller)에는 단일 HardwareEvent 리소스만 필요합니다.

  4. Git에서 PolicyGenTemplate 변경 사항을 커밋한 다음 사이트 구성 리포지토리로 변경 사항을 내보내 GitOps ZTP를 사용하여 베어 메탈 이벤트 모니터링을 새 사이트에 배포합니다.
  5. 다음 명령을 실행하여 Redfish 보안을 생성합니다.

    $ oc -n openshift-bare-metal-events create secret generic redfish-basic-auth \
    --from-literal=username=<bmc_username> --from-literal=password=<bmc_password> \
    --from-literal=hostaddr="<bmc_host_ip_addr>"

추가 리소스

추가 리소스

17.9.10. PolicyGenTemplate CR에서 hub 템플릿 사용

토폴로지 Aware Lifecycle Manager는 GitOps ZTP와 함께 사용되는 구성 정책에서 RHACM(Red Hat Advanced Cluster Management) 허브 클러스터 템플릿 기능을 지원합니다.

Hub-side 클러스터 템플릿을 사용하면 대상 클러스터에 동적으로 사용자 지정할 수 있는 구성 정책을 정의할 수 있습니다. 이렇게 하면 similiar 구성이 있지만 값이 다른 많은 클러스터에 대해 별도의 정책을 생성할 필요가 없습니다.

중요

정책 템플릿은 정책이 정의된 네임스페이스와 동일한 네임스페이스로 제한됩니다. 즉, 정책이 생성된 동일한 네임스페이스에서 hub 템플릿에서 참조되는 오브젝트를 생성해야 합니다.

다음 지원되는 hub 템플릿 기능은 TALM과 함께 GitOps ZTP에서 사용할 수 있습니다.

GitOps ZTP와 함께 다양한 오픈 소스 커뮤니티 기능 도 사용할 수 있습니다.

17.9.10.1. hub 템플릿 예

다음 코드 예제는 유효한 hub 템플릿입니다. 이러한 각 템플릿은 기본 네임스페이스에 이름이 test-configConfigMap CR에서 값을 반환합니다.

  • common-key 키를 사용하여 값을 반환합니다.

    {{hub fromConfigMap "default" "test-config" "common-key" hub}}
  • .ManagedClusterName 필드 및 문자열 -name 을 사용하여 문자열을 반환합니다.

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) hub}}
  • .ManagedClusterName 필드의 연결된 값 및 문자열 -name 에서 부울 값을 캐스팅하고 반환합니다.

    {{hub fromConfigMap "default" "test-config" (printf "%s-name" .ManagedClusterName) | toBool hub}}
  • .ManagedClusterName 필드의 연결된 값 및 문자열 -name 에서 정수 값을 캐스팅하고 반환합니다.

    {{hub (printf "%s-name" .ManagedClusterName) | fromConfigMap "default" "test-config" | toInt hub}}

17.9.10.2. hub 클러스터 템플릿을 사용하여 site PolicyGenTemplate CR에서 호스트 NIC 지정

단일 ConfigMap CR에서 호스트 NIC를 관리하고 hub 클러스터 템플릿을 사용하여 클러스터 호스트에 적용되는 생성된 정책의 사용자 정의 NIC 값을 채울 수 있습니다. PGT(Site PolicyGenTemplate ) CR에 hub 클러스터 템플릿을 사용하면 각 사이트에 대해 여러 개의 단일 사이트 PGT CR을 생성할 필요가 없습니다.

다음 예제에서는 단일 ConfigMap CR을 사용하여 클러스터 호스트 NIC를 관리하고 단일 PolicyGenTemplate 사이트 CR을 사용하여 클러스터에 정책으로 적용하는 방법을 보여줍니다.

참고

fromConfigmap 함수를 사용하는 경우 printf 변수는 템플릿 리소스 데이터 키 필드에만 사용할 수 있습니다. namenamespace 필드와 함께 사용할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 GitOps ZTP ArgoCD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

절차

  1. 호스트 그룹의 NIC를 설명하는 ConfigMap 리소스를 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: sriovdata
      namespace: ztp-site
      annotations:
        argocd.argoproj.io/sync-options: Replace=true 1
    data:
      example-sno-du_fh-numVfs: "8"
      example-sno-du_fh-pf: ens1f0
      example-sno-du_fh-priority: "10"
      example-sno-du_fh-vlan: "140"
      example-sno-du_mh-numVfs: "8"
      example-sno-du_mh-pf: ens3f0
      example-sno-du_mh-priority: "10"
      example-sno-du_mh-vlan: "150"
    1
    ConfigMap 크기가 1MiB보다 큰 경우에만 argocd.argoproj.io/sync-options 주석이 필요합니다.
    참고

    ConfigMap 은 hub 템플릿 대체가 있는 정책과 동일한 네임스페이스에 있어야 합니다.

  2. Git에서 ConfigMap CR을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  3. 템플릿을 사용하여 ConfigMap 오브젝트에서 필요한 데이터를 가져오는 사이트 PGT CR을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: ran.openshift.io/v1
    kind: PolicyGenTemplate
    metadata:
      name: "site"
      namespace: "ztp-site"
    spec:
      remediationAction: inform
      bindingRules:
        group-du-sno: ""
      mcp: "master"
      sourceFiles:
        - fileName: SriovNetwork.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nw-du-fh"
          spec:
            resourceName: du_fh
            vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-vlan" .ManagedClusterName) | toInt hub}}'
        - fileName: SriovNetworkNodePolicy.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nnp-du-fh"
          spec:
            deviceType: netdevice
            isRdma: true
            nicSelector:
              pfNames:
              - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-pf" .ManagedClusterName) | autoindent hub}}'
            numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-numVfs" .ManagedClusterName) | toInt hub}}'
            priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_fh-priority" .ManagedClusterName) | toInt hub}}'
            resourceName: du_fh
        - fileName: SriovNetwork.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nw-du-mh"
          spec:
            resourceName: du_mh
            vlan: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-vlan" .ManagedClusterName) | toInt hub}}'
        - fileName: SriovNetworkNodePolicy.yaml
          policyName: "config-policy"
          metadata:
            name: "sriov-nnp-du-mh"
          spec:
            deviceType: vfio-pci
            isRdma: false
            nicSelector:
              pfNames:
              - '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-pf" .ManagedClusterName)  hub}}'
            numVfs: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-numVfs" .ManagedClusterName) | toInt hub}}'
            priority: '{{hub fromConfigMap "ztp-site" "sriovdata" (printf "%s-du_mh-priority" .ManagedClusterName) | toInt hub}}'
            resourceName: du_mh
  4. Git에서 사이트 PolicyGenTemplate CR을 커밋하고 ArgoCD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

    참고

    참조된 ConfigMap CR에 대한 후속 변경 사항은 적용된 정책과 자동으로 동기화되지 않습니다. 새 ConfigMap 변경 사항을 수동으로 동기화하여 기존 PolicyGenTemplate CR을 업데이트해야 합니다. "Syncing new ConfigMap changes to existing PolicyGenTemplate CRs"를 참조하십시오.

17.9.10.3. hub 클러스터 템플릿을 사용하여 그룹 PolicyGenTemplate CR에서 VLAN ID 지정

단일 ConfigMap CR에서 관리 클러스터의 VLAN ID를 관리하고 hub 클러스터 템플릿을 사용하여 클러스터에 적용되는 생성된 정책의 VLAN ID를 채울 수 있습니다.

다음 예제에서는 단일 ConfigMap CR에서 VLAN ID를 관리하고 단일 PolicyGenTemplate 그룹 CR을 사용하여 개별 클러스터 정책에서 해당 ID를 적용하는 방법을 보여줍니다.

참고

fromConfigmap 함수를 사용하는 경우 printf 변수는 템플릿 리소스 데이터 키 필드에만 사용할 수 있습니다. namenamespace 필드와 함께 사용할 수 없습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • 사용자 정의 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성했습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.

절차

  1. 클러스터 호스트 그룹의 VLAN ID를 설명하는 ConfigMap CR을 생성합니다. 예를 들면 다음과 같습니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: site-data
      namespace: ztp-group
      annotations:
        argocd.argoproj.io/sync-options: Replace=true 1
    data:
      site-1-vlan: "101"
      site-2-vlan: "234"
    1
    ConfigMap 크기가 1MiB보다 큰 경우에만 argocd.argoproj.io/sync-options 주석이 필요합니다.
    참고

    ConfigMap 은 hub 템플릿 대체가 있는 정책과 동일한 네임스페이스에 있어야 합니다.

  2. Git에서 ConfigMap CR을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.
  3. hub 템플릿을 사용하여 ConfigMap 오브젝트에서 필요한 VLAN ID를 가져오는 그룹 PGT CR을 생성합니다. 예를 들어 PGT CR 그룹에 다음 YAML 조각을 추가합니다.

    - fileName: SriovNetwork.yaml
        policyName: "config-policy"
        metadata:
          name: "sriov-nw-du-mh"
          annotations:
            ran.openshift.io/ztp-deploy-wave: "10"
        spec:
          resourceName: du_mh
          vlan: '{{hub fromConfigMap "" "site-data" (printf "%s-vlan" .ManagedClusterName) | toInt hub}}'
  4. Git에서 PolicyGenTemplate CR 그룹을 커밋한 다음 Argo CD 애플리케이션에서 모니터링하는 Git 리포지토리로 내보냅니다.

    참고

    참조된 ConfigMap CR에 대한 후속 변경 사항은 적용된 정책과 자동으로 동기화되지 않습니다. 새 ConfigMap 변경 사항을 수동으로 동기화하여 기존 PolicyGenTemplate CR을 업데이트해야 합니다. "Syncing new ConfigMap changes to existing PolicyGenTemplate CRs"를 참조하십시오.

17.9.10.4. 기존 PolicyGenTemplate CR에 새 ConfigMap 변경 사항 동기화

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
  • hub 클러스터 템플릿을 사용하여 ConfigMap CR에서 정보를 가져오는 PolicyGenTemplate CR을 생성했습니다.

절차

  1. ConfigMap CR의 콘텐츠를 업데이트하고 hub 클러스터의 변경 사항을 적용합니다.
  2. 업데이트된 ConfigMap CR의 콘텐츠를 배포된 정책에 동기화하려면 다음 중 하나를 수행합니다.

    1. 옵션 1: 기존 정책을 삭제합니다. ArgoCD는 PolicyGenTemplate CR을 사용하여 삭제된 정책을 즉시 다시 생성합니다. 예를 들어 다음 명령을 실행합니다.

      $ oc delete policy <policy_name> -n <policy_namespace>
    2. 옵션 2: ConfigMap 을 업데이트할 때마다 다른 값을 가진 정책에 특수 주석 policy.open-cluster-management.io/trigger-update 를 적용합니다. 예를 들면 다음과 같습니다.

      $ oc annotate policy <policy_name> -n <policy_namespace> policy.open-cluster-management.io/trigger-update="1"
      참고

      변경 사항을 적용하려면 업데이트된 정책을 적용해야 합니다. 자세한 내용은 reprocessing 에 대한 특수 주석을 참조하십시오.

  3. 선택 사항: 정책이 있는 경우 정책이 포함된 ClusterGroupUpdate CR을 삭제합니다. 예를 들면 다음과 같습니다.

    $ oc delete clustergroupupgrade <cgu_name> -n <cgu_namespace>
    1. 업데이트된 ConfigMap 변경과 함께 적용할 정책이 포함된 새 ClusterGroupUpdate CR을 생성합니다. 예를 들어 cgr-example.yaml 파일에 다음 YAML을 추가합니다.

      apiVersion: ran.openshift.io/v1alpha1
      kind: ClusterGroupUpgrade
      metadata:
        name: <cgr_name>
        namespace: <policy_namespace>
      spec:
        managedPolicies:
          - <managed_policy>
        enable: true
        clusters:
        - <managed_cluster_1>
        - <managed_cluster_2>
        remediationStrategy:
          maxConcurrency: 2
          timeout: 240
    2. 업데이트된 정책을 적용합니다.

      $ oc apply -f cgr-example.yaml