9장. PolicyGenerator 리소스를 사용하여 클러스터 정책 관리
9.1. PolicyGenerator 리소스를 사용하여 관리되는 클러스터 정책 구성
적용된 정책
CR(사용자 정의 리소스)은 사용자가 프로비저닝하는 관리 클러스터를 구성합니다. RHACM(Red Hat Advanced Cluster Management)에서
CR을 사용하여 적용된 정책 CR을 생성하는 방법을 사용자 지정할 수 있습니다.
Policy
Generator
GitOps ZTP를 사용하여 PolicyGenerator 리소스를 사용하는 것은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
PolicyGenerator
리소스에 대한 자세한 내용은 RHACM 정책 생성기 설명서를 참조하십시오.
9.1.1. RHACM PolicyGenerator 및 PolicyGenTemplate 리소스 패치 비교
PolicyGenerator
CR(사용자 정의 리소스) 및 PolicyGenTemplate
CR을 GitOps ZTP에서 사용하여 관리 클러스터에 대한 RHACM 정책을 생성할 수 있습니다.
GitOps ZTP를 사용하여 OpenShift Container Platform 리소스의 패치 적용과 관련하여 PolicyGenTemplate
CR을 통해 PolicyGenerator
CR을 사용하면 이점이 있습니다. RHACM PolicyGenerator
API를 사용하면 PolicyGenTemplate
리소스에서 사용할 수 없는 일반적인 패치 적용 방법을 제공합니다.
PolicyGenerator
API는 Open Cluster Management 표준의 일부이지만 PolicyGenTemplate
API는 그렇지 않습니다. PolicyGenerator
및 PolicyGenTemplate
리소스 패치 및 배치 전략 비교는 다음 표에 설명되어 있습니다.
PolicyGenTemplate
CR을 사용하여 관리형 클러스터에 대한 정책 관리 및 배포는 향후 OpenShift Container Platform 릴리스에서 더 이상 사용되지 않습니다. RHACM(Advanced Cluster Management) 및 PolicyGenerator
CR을 사용하여 동일하고 개선된 기능을 사용할 수 있습니다.
PolicyGenerator
리소스에 대한 자세한 내용은 RHACM 정책 생성기 설명서를 참조하십시오.
PolicyGenerator 패치 | PolicyGenTemplate 패치 |
---|---|
리소스 병합을 위해 Kustomize 전략적 병합을 사용합니다. 자세한 내용은 Kustomize를 사용하는 Kubernetes 오브젝트의 선언적 관리를 참조하십시오. | 패치에 정의된 대로 변수를 값으로 교체하여 작동합니다. 이는 Kustomize 병합 전략보다 유연합니다. |
|
|
패치에만 의존하여 포함된 변수 대체가 필요하지 않습니다. | 패치에 정의된 변수 값을 덮어씁니다. |
병합 패치에서는 목록 병합을 지원하지 않습니다. 병합 패치에서 목록을 교체할 수 있습니다. | 목록 병합 및 교체는 제한된 방식으로 지원됩니다. 목록에서 하나의 오브젝트만 병합할 수 있습니다. |
현재 리소스 패치에 대한 OpenAPI 사양 을 지원하지 않습니다. 즉, 스키마를 따르지 않는 콘텐츠를 병합하기 위해 패치에 추가 지시문이 필요합니다(예: | 필드 및 값을 패치에 정의된 값으로 교체하여 작동합니다. |
스키마를 따르지 않는 콘텐츠를 병합하려면 추가 지시문(예: |
소스 CR에 정의된 필드 및 값을 패치에 정의된 값으로 대체합니다(예: |
참조 소스 CR에 정의된 |
참조 소스 CR에 정의된 |
9.1.2. PolicyGenerator CRD 정보
PolicyGenerator
CRD(사용자 정의 리소스 정의)는 PolicyGen
정책 생성기에 클러스터 구성에 포함할 사용자 정의 리소스(CR), CR을 생성된 정책에 결합하는 방법, 해당 CR의 어떤 항목을 오버레이 콘텐츠로 업데이트해야 하는지 알려줍니다.
다음 예제에서는 ztp-site
)을 보여줍니다. -generate
참조 컨테이너에서 추출된 PolicyGenerator
CR(cm-common-du-ranGen.yamlacm-common-du-ranGen.yaml
파일은 두 개의 RHACM(Red Hat Advanced Cluster Management) 정책을 정의합니다. 경찰은 CR에서 policyName
의 각 고유 값에 대해 하나씩 구성 CR 컬렉션을 관리합니다. ACM -common-du-ranGen.yaml
은 policyDefaults.placement.labelSelector
섹션에 나열된 레이블을 기반으로 클러스터에 정책을 바인딩하는 단일 배치 바인딩 및 배치 규칙을 생성합니다.
PolicyGenerator CR 예 - acm-common-ranGen.yaml
apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: common-latest placementBindingDefaults: name: common-latest-placement-binding 1 policyDefaults: namespace: ztp-common placement: labelSelector: matchExpressions: - key: common operator: In values: - "true" - key: du-profile operator: In values: - latest remediationAction: inform severity: low namespaceSelector: exclude: - kube-* include: - '*' evaluationInterval: compliant: 10m noncompliant: 10s policies: - name: common-latest-config-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "1" manifests: - path: source-crs/ReduceMonitoringFootprint.yaml - path: source-crs/DefaultCatsrc.yaml 2 patches: - metadata: name: redhat-operators-disconnected spec: displayName: disconnected-redhat-operators image: registry.example.com:5000/disconnected-redhat-operators/disconnected-redhat-operator-index:v4.9 - path: source-crs/DisconnectedICSP.yaml patches: - spec: repositoryDigestMirrors: - mirrors: - registry.example.com:5000 source: registry.redhat.io - name: common-latest-subscriptions-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "2" manifests: 3 - path: source-crs/SriovSubscriptionNS.yaml - path: source-crs/SriovSubscriptionOperGroup.yaml - path: source-crs/SriovSubscription.yaml - path: source-crs/SriovOperatorStatus.yaml - path: source-crs/PtpSubscriptionNS.yaml - path: source-crs/PtpSubscriptionOperGroup.yaml - path: source-crs/PtpSubscription.yaml - path: source-crs/PtpOperatorStatus.yaml - path: source-crs/ClusterLogNS.yaml - path: source-crs/ClusterLogOperGroup.yaml - path: source-crs/ClusterLogSubscription.yaml - path: source-crs/ClusterLogOperatorStatus.yaml - path: source-crs/StorageNS.yaml - path: source-crs/StorageOperGroup.yaml - path: source-crs/StorageSubscription.yaml - path: source-crs/StorageOperatorStatus.yaml
PolicyGenerator
CR은 포함된 CR 수를 사용하여 구성할 수 있습니다. hub 클러스터에 다음 예제 CR을 적용하여 단일 CR을 포함하는 정책을 생성합니다.
apiVersion: policy.open-cluster-management.io/v1 kind: PolicyGenerator metadata: name: group-du-sno placementBindingDefaults: name: group-du-sno-placement-binding policyDefaults: namespace: ztp-group placement: labelSelector: matchExpressions: - key: group-du-sno operator: Exists remediationAction: inform severity: low namespaceSelector: exclude: - kube-* include: - '*' evaluationInterval: compliant: 10m noncompliant: 10s policies: - name: group-du-sno-config-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: '10' manifests: - path: source-crs/PtpConfigSlave-MCP-master.yaml patches: - metadata: null name: du-ptp-slave namespace: openshift-ptp annotations: ran.openshift.io/ztp-deploy-wave: '10' spec: profile: - name: slave interface: $interface ptp4lOpts: '-2 -s' phc2sysOpts: '-a -r -n 24' ptpSchedulingPolicy: SCHED_FIFO ptpSchedulingPriority: 10 ptpSettings: logReduce: 'true' ptp4lConf: | [global] # # Default Data Set # twoStepFlag 1 slaveOnly 1 priority1 128 priority2 128 domainNumber 24 #utc_offset 37 clockClass 255 clockAccuracy 0xFE offsetScaledLogVariance 0xFFFF free_running 0 freq_est_interval 1 dscp_event 0 dscp_general 0 dataset_comparison G.8275.x G.8275.defaultDS.localPriority 128 # # Port Data Set # logAnnounceInterval -3 logSyncInterval -4 logMinDelayReqInterval -4 logMinPdelayReqInterval -4 announceReceiptTimeout 3 syncReceiptTimeout 0 delayAsymmetry 0 fault_reset_interval -4 neighborPropDelayThresh 20000000 masterOnly 0 G.8275.portDS.localPriority 128 # # Run time options # assume_two_step 0 logging_level 6 path_trace_enabled 0 follow_up_info 0 hybrid_e2e 0 inhibit_multicast_service 0 net_sync_monitor 0 tc_spanning_tree 0 tx_timestamp_timeout 50 unicast_listen 0 unicast_master_table 0 unicast_req_duration 3600 use_syslog 1 verbose 0 summary_interval 0 kernel_leap 1 check_fup_sync 0 clock_class_threshold 7 # # Servo Options # pi_proportional_const 0.0 pi_integral_const 0.0 pi_proportional_scale 0.0 pi_proportional_exponent -0.3 pi_proportional_norm_max 0.7 pi_integral_scale 0.0 pi_integral_exponent 0.4 pi_integral_norm_max 0.3 step_threshold 2.0 first_step_threshold 0.00002 max_frequency 900000000 clock_servo pi sanity_freq_limit 200000000 ntpshm_segment 0 # # Transport options # transportSpecific 0x0 ptp_dst_mac 01:1B:19:00:00:00 p2p_dst_mac 01:80:C2:00:00:0E udp_ttl 1 udp6_scope 0x0E uds_address /var/run/ptp4l # # Default interface options # clock_type OC network_transport L2 delay_mechanism E2E time_stamping hardware tsproc_mode filter delay_filter moving_median delay_filter_length 10 egressLatency 0 ingressLatency 0 boundary_clock_jbod 0 # # Clock description # productDescription ;; revisionData ;; manufacturerIdentity 00:00:00 userDescription ; timeSource 0xA0 recommend: - profile: slave priority: 4 match: - nodeLabel: node-role.kubernetes.io/master
소스 파일 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: PolicyGenerator metadata: name: du-upgrade placementBindingDefaults: name: du-upgrade-placement-binding policyDefaults: namespace: ztp-group-du-sno placement: labelSelector: matchExpressions: - key: group-du-sno operator: Exists remediationAction: inform severity: low namespaceSelector: exclude: - kube-* include: - '*' evaluationInterval: compliant: 10m noncompliant: 10s policies: - name: du-upgrade-operator-catsrc-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "1" manifests: - path: source-crs/DefaultCatsrc.yaml patches: - metadata: name: redhat-operators spec: displayName: Red Hat Operators Catalog image: registry.example.com:5000/olm/redhat-operators:v4.14 updateStrategy: registryPoll: interval: 1h status: connectionState: lastObservedState: READY
9.1.3. PolicyGenerator CR을 사용자 정의할 때 권장 사항
사이트 구성 PolicyGenerator
CR(사용자 정의 리소스)을 사용자 정의할 때 다음과 같은 모범 사례를 고려하십시오.
-
필요한 만큼의 정책을 사용하십시오. 정책을 더 적게 사용하려면 더 적은 리소스가 필요합니다. 각 추가 정책은 허브 클러스터 및 배포된 관리 클러스터에 대한 CPU 로드가 증가합니다. CR은
PolicyGenerator
CR의policyName
필드를 기반으로 정책에 결합됩니다.policyName
에 동일한 값이 있는 동일한PolicyGenerator
의 CR은 단일 정책으로 관리됩니다. -
연결이 끊긴 환경에서는 모든 Operator가 포함된 단일 인덱스로 레지스트리를 구성하여 모든 Operator에 대해 단일 카탈로그 소스를 사용합니다. 관리 클러스터의 각 추가
CatalogSource
CR은 CPU 사용량을 늘립니다. -
MachineConfig
CR은 설치 중에 적용되도록SiteConfig
CR에서extraManifests
로 포함되어야 합니다. 이를 통해 클러스터가 애플리케이션을 배포할 준비가 될 때까지 걸리는 전체 시간을 줄일 수 있습니다. -
PolicyGenerator
CR은 원하는 버전을 명시적으로 식별하기 위해 channel 필드를 재정의해야 합니다. 이렇게 하면 업그레이드 중에 소스 CR의 변경이 생성된 서브스크립션을 업데이트하지 않습니다.
추가 리소스
- RHACM을 사용한 클러스터 스케일링에 대한 권장 사항은 성능 및 확장성을 참조하십시오.
허브 클러스터에서 많은 수의 음성 클러스터를 관리할 때 정책 수를 최소화하여 리소스 소비를 줄입니다.
여러 구성 CR을 단일 또는 제한된 정책으로 그룹화하는 것이 허브 클러스터의 전체 정책 수를 줄이는 한 가지 방법입니다. 사이트 구성을 관리하기 위한 공통, 그룹 및 사이트 계층 구조를 사용하는 경우 사이트별 구성을 단일 정책으로 결합하는 것이 특히 중요합니다.
9.1.4. RAN 배포를 위한 PolicyGenerator CR
ZTP(ZTP) 파이프라인을 사용하여 클러스터에 적용되는 구성을 사용자 지정하려면 PolicyGenerator
CR(사용자 정의 리소스)을 사용합니다. PolicyGenerator
CR을 사용하면 클러스터의 구성 CR 세트를 관리하는 하나 이상의 정책을 생성할 수 있습니다. PolicyGenerator
CR은 관리되는 CR 세트를 식별하고, 정책에 번들하고, 해당 CR을 래핑하는 정책을 빌드하며, 라벨 바인딩 규칙을 사용하여 정책을 클러스터와 연결합니다.
GitOps ZTP 컨테이너에서 얻은 참조 구성은 클러스터가 RAN(Radio Access Network) 분산 단위(DU) 애플리케이션의 엄격한 성능 및 리소스 사용률 제약 조건을 지원할 수 있도록 중요한 기능 및 노드 튜닝 설정 세트를 제공하도록 설계되었습니다. 기준 구성의 변경 사항 또는 누락은 기능 가용성, 성능 및 리소스 사용률에 영향을 미칠 수 있습니다. 참조 PolicyGenerator
CR을 기준으로 사용하여 특정 사이트 요구 사항에 맞는 구성 파일의 계층을 생성합니다.
RAN DU 클러스터 구성에 정의된 기본 PolicyGenerator
CR은 GitOps ZTP ztp-site-generate
컨테이너에서 추출할 수 있습니다. 자세한 내용은 " GitOps ZTP 사이트 구성 리포지토리 준비"를 참조하십시오.
PolicyGenerator
CR은 ./out/argocd/example/acmpolicygenerator/
폴더에 있습니다. 참조 아키텍처에는 공통, 그룹 및 사이트별 구성 CR이 있습니다. 각 PolicyGenerator
CR은 ./out/source-crs
폴더에 있는 다른 CR을 나타냅니다.
RAN 클러스터 구성과 관련된 PolicyGenerator
CR은 다음과 같습니다. 그룹 PolicyGenerator
CR에는 단일 노드, 3-노드 컴팩트 및 표준 클러스터 구성의 차이점을 고려해야 하는 변형이 제공됩니다. 마찬가지로 단일 노드 클러스터 및 다중 노드(콤팩트 또는 표준) 클러스터에 대해 사이트별 구성 변형이 제공됩니다. 배포와 관련된 그룹 및 사이트별 구성 변형을 사용합니다.
PolicyGenerator CR | 설명 |
---|---|
| 다중 노드 클러스터에 적용되는 CR 세트를 포함합니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다. |
| 단일 노드 OpenShift 클러스터에 적용되는 CR 세트를 포함합니다. 이러한 CR은 RAN 설치에 일반적인 SR-IOV 기능을 구성합니다. |
| 다중 노드 클러스터에 적용할 수 있는 일반적인 RAN 정책 구성 세트가 포함되어 있습니다. |
| 모든 클러스터에 적용되는 공통 RAN CR 세트를 포함합니다. 이러한 CR은 RAN 및 기본 클러스터 튜닝에 일반적인 클러스터 기능을 제공하는 Operator 세트에 서브스크립션합니다. |
| 3-노드 클러스터에 대한 RAN 정책만 포함합니다. |
| 단일 노드 클러스터에 대한 RAN 정책만 포함합니다. |
| 표준 세 개의 컨트롤 플레인 클러스터에 대한 RAN 정책을 포함합니다. |
|
3-노드 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 |
|
표준 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 |
|
단일 노드 OpenShift 클러스터에 필요한 다양한 정책을 생성하는 데 사용되는 |
추가 리소스
9.1.5. PolicyGenerator CR을 사용하여 관리 클러스터 사용자 정의
다음 절차에 따라 ZTP(ZTP) 파이프라인을 사용하여 프로비저닝하는 관리 클러스터에 적용할 수 있는 정책을 사용자 지정할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - 필요한 설치 및 정책 CR을 생성하도록 허브 클러스터를 구성했습니다.
- 사용자 지정 사이트 구성 데이터를 관리하는 Git 리포지토리를 생성하셨습니다. 리포지토리는 hub 클러스터에서 액세스할 수 있어야 하며 Argo CD 애플리케이션의 소스 리포지토리로 정의해야 합니다.
프로세스
사이트별 구성 CR에 대한
PolicyGenerator
CR을 생성합니다.-
out/argocd/example/acmpolicygenerator/
폴더에서 CR에 대한 적절한 예를 선택합니다(예:acm-example-sno-site.yaml
또는acm-example-multinode-site.yaml
). 예제 파일의
policyDefaults.placement.labelSelector
필드를SiteConfig
CR에 포함된 사이트별 레이블과 일치하도록 변경합니다. 예제SiteConfig
파일에서 사이트별 레이블은sites: example-sno
입니다.참고PolicyGenerator
policyDefaults.placement.labelSelector
필드에 정의된 라벨이 관련 관리 클러스터 siteConfig
CR에 정의된 라벨에 해당하는지 확인합니다.- 예제 파일의 콘텐츠를 원하는 구성과 일치하도록 변경합니다.
-
선택 사항: 전체 클러스터에 적용되는 일반적인 구성 CR에 대한
PolicyGenerator
CR을 생성합니다.-
out/argocd/example/acmpolicygenerator/
폴더에서 CR에 대한 적절한 예를 선택합니다(예:acm-common-ranGen.yaml
). - 필요한 구성과 일치하도록 예제 파일의 콘텐츠를 변경합니다.
-
선택 사항: 플릿의 특정 클러스터 그룹에 적용되는 모든 그룹 구성 CR에 대해
PolicyGenerator
CR을 생성합니다.overlaid 사양 파일의 콘텐츠가 필요한 최종 상태와 일치하는지 확인합니다. 참조로
out/source-crs
디렉터리에는 PolicyGenerator 템플릿에서 포함할 수 있는 source-crs의 전체 목록이 포함되어 있습니다.참고클러스터의 특정 요구 사항에 따라 클러스터 유형당 단일 그룹 정책이 필요할 수 있습니다. 특히 예제 그룹 정책에는 각각 동일한 하드웨어 구성으로 구성된 클러스터 집합에서만 공유할 수 있는 단일
PerformancePolicy.yaml
파일이 있습니다.-
out/argocd/example/acmpolicygenerator/
폴더에서 CR에 대한 적절한 예를 선택합니다(예:acm-group-du-sno-ranGen.yaml
). - 필요한 구성과 일치하도록 예제 파일의 콘텐츠를 변경합니다.
-
-
선택 사항입니다. 배포된 클러스터의 GitOps ZTP 설치 및 구성이 완료되면 정책
PolicyGenerator
CR을 생성하여 신호합니다. 자세한 내용은 "검토 확인 정보 정책 생성"을 참조하십시오. example
out/argocd/example/acmpolicygenerator/ns.yaml
파일과 유사한 YAML 파일에서 모든 정책 네임스페이스를 정의합니다.중요PolicyGenerator
CR과 동일한 파일에Namespace
CR을 포함하지 마십시오.-
out/argocd/example/acmpolicygenerator/
과 유사하게kustomization.yaml
PolicyGenerator
CR 및Namespace
CR을 generators 섹션의 kustomization.yaml 파일에 추가합니다. Git 리포지토리에서
PolicyGenerator
CR,Namespace
CR 및 관련kustomization.yaml
파일을 커밋하고 변경 사항을 내보냅니다.ArgoCD 파이프라인은 변경 사항을 감지하고 관리 클러스터 배포를 시작합니다. 변경 사항을
SiteConfig
CR 및PolicyGenerator
CR로 동시에 푸시할 수 있습니다.
9.1.6. 관리형 클러스터 정책 배포 진행 상황 모니터링
ArgoCD 파이프라인은 Git의 PolicyGenerator
CR을 사용하여 RHACM 정책을 생성한 다음 hub 클러스터에 동기화합니다. 지원 서비스가 관리형 클러스터에 OpenShift Container Platform을 설치한 후 관리 클러스터 정책 동기화의 진행 상황을 모니터링할 수 있습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다.
프로세스
Topology Aware Lifecycle Manager(TALM)는 클러스터에 바인딩된 구성 정책을 적용합니다.
클러스터 설치가 완료되고 클러스터가
Ready
가 되면ran.openshift.io/ztp-deploy-ECDHE 주석에
의해 정의된 정렬된 정책 목록과 함께 이 클러스터에 해당하는ClusterGroupUpgrade
CR이 TALM에 의해 자동으로 생성됩니다. 클러스터의 정책은ClusterGroupUpgrade
CR에 나열된 순서대로 적용됩니다.다음 명령을 사용하여 구성 정책 조정의 고급 진행 상황을 모니터링할 수 있습니다.
$ export CLUSTER=<clusterName>
$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[-1:]}' | jq
출력 예
{ "lastTransitionTime": "2022-11-09T07:28:09Z", "message": "Remediating non-compliant policies", "reason": "InProgress", "status": "True", "type": "Progressing" }
RHACM 대시보드 또는 명령줄을 사용하여 자세한 클러스터 정책 규정 준수 상태를 모니터링할 수 있습니다.
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
RHACM 웹 콘솔에서 정책 상태를 확인하려면 다음 작업을 수행합니다.
-
Governance
policies 찾기를 클릭합니다. - 클러스터 정책을 클릭하여 상태를 확인합니다.
-
Governance
모든 클러스터 정책이 준수되면 클러스터의 GitOps ZTP 설치 및 구성이 완료됩니다. ztp-done
레이블이 클러스터에 추가되었습니다.
참조 구성에서 준수되는 최종 정책은 *-du-validator-policy
정책에 정의된 정책입니다. 클러스터 준수 시 이 정책은 모든 클러스터 구성, Operator 설치 및 Operator 구성이 완료되었는지 확인합니다.
9.1.7. 구성 정책 CR 생성 검증
정책
CR(사용자 정의 리소스)은 해당 리소스가 생성되는 PolicyGenerator
와 동일한 네임스페이스에 생성됩니다. 동일한 문제 해결 흐름은 다음 명령을 사용하여 표시된 것처럼 ztp-common
,ztp-group
또는 ztp-site
기반 여부에 관계없이 PolicyGenerator
에서 생성된 모든 정책 CR에 적용됩니다.
$ export NS=<namespace>
$ oc get policy -n $NS
정책 래핑된 CR의 예상 세트가 표시되어야 합니다.
정책 동기화에 실패한 경우 다음 문제 해결 단계를 사용하십시오.
프로세스
정책에 대한 자세한 정보를 표시하려면 다음 명령을 실행합니다.
$ oc describe -n openshift-gitops application policies
Status: Conditions:
를 확인하여 오류 로그를 표시합니다. 예를 들어 잘못된sourceFile
항목을fileName:
로 설정하면 다음과 같이 오류가 생성됩니다.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
상태 확인: 동기화:
.Status: Conditions:
에 로그 오류가 있는 경우Status: Sync:
showsUnknown
orError
: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
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은 적용 가능한 모든 정책을 클러스터 네임스페이스에 복사합니다. 복사된 정책 이름의 형식은 <
PolicyGenerator.Namespace>.<PolicyGenerator.Name>-<policyName
>입니다.클러스터 네임스페이스에 복사되지 않은 모든 정책의 배치 규칙을 확인합니다. 해당 정책에 대한
배치
의matchSelector
는ManagedCluster
오브젝트의 라벨과 일치해야 합니다.$ oc get Placement -n $NS
다음 명령을 사용하여 누락된 정책, 공통, 그룹 또는 사이트에 적합한
배치
이름을 확인합니다.$ oc get Placement -n $NS <placement_rule_name> -o yaml
- status-decisions에는 클러스터 이름이 포함되어야 합니다.
-
사양에 있는
matchSelector
의 키-값 쌍은 관리 클러스터의 라벨과 일치해야 합니다.
다음 명령을 사용하여
ManagedCluster
오브젝트에서 라벨을 확인합니다.$ oc get ManagedCluster $CLUSTER -o jsonpath='{.metadata.labels}' | jq
다음 명령을 사용하여 호환되는 정책을 확인합니다.
$ oc get policy -n $CLUSTER
네임스페이스
,
OperatorGroup
및서브스크립션
정책이 호환되지만 Operator 구성 정책이 적용되지 않은 경우 Operator가 관리 클러스터에 설치되지 않을 수 있습니다. 이로 인해 CRD가 아직 spoke에 적용되지 않았기 때문에 Operator 구성 정책이 적용되지 않습니다.
9.1.8. 정책 조정 다시 시작
예를 들어 ClusterGroupUpgrade
CR(사용자 정의 리소스)이 시간 초과된 경우 예기치 않은 규정 준수 문제가 발생하면 정책 조정을 다시 시작할 수 있습니다.
프로세스
ClusterGroupUpgrade
CR은 관리 클러스터가Ready
가 된 후 토폴로지 Aware Lifecycle Manager를 통해ztp-install
네임스페이스에 생성됩니다.$ export CLUSTER=<clusterName>
$ oc get clustergroupupgrades -n ztp-install $CLUSTER
예기치 않은 문제가 있고 정책이 구성된 시간 내에 불만이 발생하지 않는 경우(기본값은 4시간)
ClusterGroupUpgrade
CR의 상태에UpgradeTimedOut
이 표시됩니다.$ oc get clustergroupupgrades -n ztp-install $CLUSTER -o jsonpath='{.status.conditions[?(@.type=="Ready")]}'
UpgradeTimedOut
상태의ClusterGroupUpgrade
CR은 시간마다 정책 조정을 자동으로 다시 시작합니다. 정책을 변경한 경우 기존ClusterGroupUpgrade
CR을 삭제하여 즉시 재시도를 시작할 수 있습니다. 이렇게 하면 새ClusterGroupUpgrade
CR의 자동 생성이 트리거되고 즉시 정책 조정이 시작됩니다.$ oc delete clustergroupupgrades -n ztp-install $CLUSTER
ClusterGroupUpgrade
CR이 UpgradeCompleted
상태로 완료되고 관리 클러스터에 ztp-done
레이블이 적용된 경우 PolicyGenerator
를 사용하여 추가 구성을 변경할 수 있습니다. 기존 ClusterGroupUpgrade
CR을 삭제하면 TALM에서 새 CR이 생성되지 않습니다.
이 시점에서 GitOps ZTP는 클러스터와의 상호 작용을 완료했으며 추가 상호 작용을 업데이트 및 정책 수정을 위해 생성된 새 ClusterGroupUpgrade
CR로 처리해야 합니다.
추가 리소스
-
TALM( Topology Aware Lifecycle Manager)을 사용하여 자체
ClusterGroupUpgrade
CR을 구성하는 방법에 대한 자세한 내용은 ClusterGroupUpgrade CR 정보를 참조하십시오.
9.1.9. 정책을 사용하여 적용된 관리 클러스터 CR 변경
정책을 통해 관리 클러스터에 배포된 CR(사용자 정의 리소스)에서 콘텐츠를 제거할 수 있습니다.
기본적으로
CR에서 생성된 모든 Policy CR에는 Policy
GeneratorcomplianceType
필드가 musthave
로 설정되어 있습니다. 관리 클러스터의 CR에 지정된 콘텐츠가 모두 있으므로 제거된 콘텐츠가 없는 musthave
정책은 계속 호환됩니다. 이 구성을 사용하면 CR에서 콘텐츠를 제거할 때 TALM은 정책에서 콘텐츠를 제거하지만 콘텐츠는 관리 클러스터의 CR에서 제거되지 않습니다.
mustonlyhave
에 complianceType
필드를 사용하면 정책에서 클러스터의 CR이 정책에 지정된 내용과 정확히 일치하도록 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
cluster-admin
권한이 있는 사용자로 hub 클러스터에 로그인했습니다. - RHACM을 실행하는 허브 클러스터에서 관리 클러스터를 배포했습니다.
- hub 클러스터에 Topology Aware Lifecycle Manager를 설치했습니다.
프로세스
영향을 받는 CR에서 더 이상 필요하지 않은 콘텐츠를 제거합니다. 이 예에서는
disableDrain: false
행이SriovOperatorConfig
CR에서 제거되었습니다.CR 예
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovOperatorConfig metadata: name: default namespace: openshift-sriov-network-operator spec: configDaemonNodeSelector: "node-role.kubernetes.io/$mcp": "" disableDrain: true enableInjector: true enableOperatorWebhook: true
영향을 받는 정책의
complianceType
을acm-group-du-sno-ranGen.yaml
파일에서mustonlyhave
로 변경합니다.YAML의 예
# ... policyDefaults: complianceType: "mustonlyhave" # ... policies: - name: config-policy policyAnnotations: ran.openshift.io/ztp-deploy-wave: "" manifests: - path: source-crs/SriovOperatorConfig.yaml
ClusterGroupUpdates
CR을 생성하고 CR 변경 사항을 받아야 하는 클러스터를 지정합니다.ClusterGroupUpdates CR의 예
apiVersion: ran.openshift.io/v1alpha1 kind: ClusterGroupUpgrade metadata: name: cgu-remove namespace: default spec: managedPolicies: - ztp-group.group-du-sno-config-policy enable: false clusters: - spoke1 - spoke2 remediationStrategy: maxConcurrency: 2 timeout: 240 batchTimeoutAction:
다음 명령을 실행하여
ClusterGroupUpgrade
CR을 생성합니다.$ oc create -f cgu-remove.yaml
적절한 유지 관리 기간 동안 변경 사항을 적용할 준비가 되면 다음 명령을 실행하여
spec.enable
필드의 값을true
로 변경합니다.$ oc --namespace=default patch clustergroupupgrade.ran.openshift.io/cgu-remove \ --patch '{"spec":{"enable":true}}' --type=merge
검증
다음 명령을 실행하여 정책의 상태를 확인합니다.
$ oc get <kind> <changed_cr_name>
출력 예
NAMESPACE NAME REMEDIATION ACTION COMPLIANCE STATE AGE default cgu-ztp-group.group-du-sno-config-policy enforce 17m default ztp-group.group-du-sno-config-policy inform NonCompliant 15h
정책의
COMPLIANCE STATE
가Compliant
인 경우 CR이 업데이트되고 원하지 않는 콘텐츠가 제거됨을 의미합니다.관리 클러스터에서 다음 명령을 실행하여 정책이 대상 클러스터에서 제거되었는지 확인합니다.
$ oc get <kind> <changed_cr_name>
결과가 없는 경우 관리 클러스터에서 CR이 제거됩니다.
9.1.10. GitOps ZTP 설치에 대해 수행됨 표시
GitOps ZTP(ZTP)는 클러스터의 GitOps ZTP 설치 상태를 확인하는 프로세스를 단순화합니다. GitOps ZTP 상태는 클러스터 설치, 클러스터 구성 및 GitOps ZTP의 세 단계로 이동합니다.
- 클러스터 설치 단계
-
클러스터 설치 단계는 ManagedCluster CR의
ManagedClusterJoined
및ManagedCluster
AvailableManagedCluster
CR에 이러한 조건이 없거나 조건이False
로 설정되어 있는 경우 클러스터는 여전히 설치 단계에 있습니다. 설치에 대한 자세한 내용은AgentClusterInstall
및ClusterDeployment
CR에서 확인할 수 있습니다. 자세한 내용은 "Troubleshooting GitOps ZTP"를 참조하십시오. - 클러스터 구성 단계
-
클러스터 구성 단계는 클러스터의
ManagedCluster
CR을 적용한ztp 실행
라벨에 의해 표시됩니다. - GitOps ZTP 완료
GitOps ZTP 완료 단계에서 클러스터 설치 및 구성이 완료됩니다. 이는
ztp-running
레이블을 제거하고ztp-done
레이블을ManagedCluster
CR에 추가하여 표시됩니다.ztp-done
레이블은 구성이 적용되었으며 기준 DU 구성이 클러스터 튜닝을 완료했음을 보여줍니다.GitOps ZTP done 상태의 변경 사항은 RHACM(Red Hat Advanced Cluster Management) 검증 검증 정보 정책의 준수 상태에서 적용됩니다. 이 정책은 완료된 설치에 대한 기존 기준을 캡처하고 관리 클러스터의 GitOps ZTP 프로비저닝이 완료된 경우에만 규정 준수 상태로 이동하는지 확인합니다.
검증기 정보 정책은 클러스터 구성이 완전히 적용되고 Operator가 초기화를 완료하도록 합니다. 정책은 다음을 확인합니다.
-
대상
MachineConfigPool
에는 예상되는 항목이 포함되어 있으며 업데이트가 완료되었습니다. 모든 노드를 사용할 수 있으며 성능이 저하되지 않습니다. -
SR-IOV Operator는
syncStatus: Succeeded
가 있는 하나 이상의SriovNetworkNodeState
에 표시된 대로 초기화를 완료했습니다. - PTP Operator 데몬 세트가 있습니다.
-
대상