애플리케이션
애플리케이션 관리
초록
1장. 애플리케이션 관리
다음 주제를 검토하여 애플리케이션 생성, 배포 및 관리에 대해 자세히 알아보십시오. 이 가이드에서는 Kubernetes 개념 및 용어에 대해 잘 알고 있다고 가정합니다. 주요 Kubernetes 용어 및 구성 요소는 정의되지 않습니다. Kubernetes 개념에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.
애플리케이션 관리 기능을 사용하면 애플리케이션 및 애플리케이션 업데이트를 구성하고 배포하기 위한 통합적이고 단순화된 옵션을 사용할 수 있습니다. 이러한 기능을 통해 개발자와 DevOps 직원은 채널 및 서브스크립션 기반 자동화를 통해 환경 전반에서 애플리케이션을 생성하고 관리할 수 있습니다.
중요: 애플리케이션 이름은 37자를 초과할 수 없습니다.
다음 항목을 참조하십시오.
1.1. 애플리케이션 모델 및 정의
애플리케이션 모델은 관리 클러스터에 배포된 리소스가 포함된 하나 이상의 Kubernetes 리소스 리포지토리(채널 리소스)에 가입하는 것을 기반으로 합니다. 단일 클러스터 애플리케이션과 다중 클러스터 애플리케이션 모두 동일한 Kubernetes 사양을 사용하지만 다중 클러스터 애플리케이션은 배포 및 애플리케이션 관리 라이프사이클을 더욱 자동화해야 합니다.
애플리케이션 모델에 대한 자세한 내용은 다음 이미지를 참조하십시오.
다음 애플리케이션 리소스 섹션을 확인합니다.
모범 사례: 채널 및 서브스크립션 모델 대신 GitOps Operator 또는 Argo CD 통합을 사용합니다. GitOps 개요 에서 자세히 알아보십시오.
1.1.1. 애플리케이션
Red Hat Advanced Cluster Management for Kubernetes의 애플리케이션(application.app.k8s.io
)은 애플리케이션을 구성하는 Kubernetes 리소스를 그룹화하는 데 사용됩니다.
Kubernetes 애플리케이션용 Red Hat Advanced Cluster Management의 모든 애플리케이션 구성 요소 리소스는 YAML 파일 사양 섹션에 정의되어 있습니다. 애플리케이션 구성 요소 리소스를 생성하거나 업데이트해야 하는 경우 리소스를 정의하는 레이블을 포함하도록 적절한 섹션을 생성하거나 편집해야 합니다.
OpenShift Container Platform GitOps 또는 클러스터에 설치된 Argo CD Operator에서 검색한 애플리케이션인 Discovered 애플리케이션에서도 작업할 수 있습니다. 동일한 리포지토리를 공유하는 애플리케이션은 이 보기에서 함께 그룹화됩니다.
1.1.2. 서브스크립션
서브스크립션(subscription.apps.open-cluster-management.io
)을 사용하면 클러스터에서 Git 리포지토리, Helm 릴리스 레지스트리 또는 오브젝트 스토리지 리포지토리의 유형일 수 있는 소스 리포지토리(채널)를 구독할 수 있습니다.
허브 클러스터가 자체 관리인 경우 서브스크립션을 통해 허브 클러스터에 로컬로 애플리케이션 리소스를 배포할 수 있습니다. 그런 다음 토폴로지에서 로컬 클러스터
(자체 관리 허브 클러스터) 서브스크립션을 볼 수 있습니다. 리소스 요구 사항은 허브 클러스터 성능에 부정적인 영향을 미칠 수 있습니다.
서브스크립션은 새 리소스 또는 업데이트된 리소스 템플릿을 식별하기 위해 채널 또는 스토리지 위치를 가리킬 수 있습니다. 그런 다음 서브스크립션 Operator는 스토리지 위치에서 직접 다운로드하고 허브 클러스터를 먼저 확인하지 않고 대상 관리 클러스터에 배포할 수 있습니다. 서브스크립션을 통해 서브스크립션 Operator는 허브 클러스터 대신 새 리소스 또는 업데이트된 리소스에 대한 채널을 모니터링할 수 있습니다.
다음 서브스크립션 아키텍처 이미지를 참조하십시오.
1.1.2.1. 채널
채널(channel.apps.open-cluster-management.io
)은 클러스터가 서브스크립션으로 구독할 수 있는 소스 리포지토리를 정의하고 허브 클러스터의 Git, Helm 릴리스 및 오브젝트 스토리지 리포지토리 및 리소스 템플릿일 수 있습니다.
권한이 부여된 Git 리포지토리와 같이 권한이 필요한 채널에서 Kubernetes 리소스 또는 Helm 차트가 필요한 애플리케이션이 있는 경우 보안을 사용하여 이러한 채널에 대한 액세스를 제공할 수 있습니다. 서브스크립션은 데이터 보안을 유지하면서 이러한 채널에서 배포하기 위해 Kubernetes 리소스 및 Helm 차트에 액세스할 수 있습니다.
채널은 허브 클러스터 내에서 네임스페이스를 사용하고 배포를 위해 리소스가 저장되는 물리적 위치를 가리킵니다. 클러스터는 채널을 구독하여 각 클러스터에 배포할 리소스를 식별할 수 있습니다.
참고: 고유 네임스페이스에 각 채널을 생성하는 것이 좋습니다. 그러나 Git 채널에서는 Git, Helm, 오브젝트 스토리지를 포함한 다른 유형의 채널과 네임스페이스를 공유할 수 있습니다.
채널 내의 리소스에는 해당 채널을 구독하는 클러스터만 액세스할 수 있습니다.
1.1.2.1.1. 지원되는 Git 리포지토리 서버
- GitHub
- GitLab
- Bitbucket
- Gogs
1.1.3. ApplicationSet
ApplicationSet
은 GitOps Operator에서 지원하는 Argo CD의 하위 프로젝트입니다. ApplicationSet
은 Argo CD 애플리케이션에 대한 다중 클러스터 지원을 추가합니다. Red Hat Advanced Cluster Management 콘솔에서 애플리케이션 세트를 생성할 수 있습니다.
참고: ApplicationSet
배포를 위한 사전 요구 사항에 대한 자세한 내용은 GitOps에 관리 클러스터 등록을 참조하십시오.
OpenShift Container Platform GitOps는 Argo CD를 사용하여 클러스터 리소스를 유지 관리합니다. Argo CD는 애플리케이션의 CI/CD(연속 통합 및 연속 배포)에 사용되는 오픈 소스 선언 도구입니다. OpenShift Container Platform GitOps는 Argo CD를 컨트롤러(OpenShift Container Platform GitOps Operator)로 구현하여 Git 리포지토리에 정의된 애플리케이션 정의 및 구성을 지속적으로 모니터링합니다. 그러면 Argo CD에서 이러한 구성의 지정된 상태를 클러스터의 라이브 상태와 비교합니다.
ApplicationSet
컨트롤러는 GitOps Operator 인스턴스를 통해 클러스터에 설치되고 cluster-administrator 중심 시나리오의 지원에 추가 기능을 추가하여 보완합니다. ApplicationSet
컨트롤러는 다음 기능을 제공합니다.
- 단일 Kubernetes 매니페스트를 사용하여 GitOps Operator를 사용하여 여러 Kubernetes 클러스터를 대상으로 하는 기능입니다.
- 단일 Kubernetes 매니페스트를 사용하여 GitOps Operator가 있는 하나 이상의 Git 리포지토리에서 여러 애플리케이션을 배포하는 기능
- Argo CD의 컨텍스트에 있는 monorepo에 대한 지원 개선, 단일 Git 리포지토리에 정의된 여러 Argo CD 애플리케이션 리소스입니다.
- 다중 테넌트 클러스터 내에서 개별 클러스터 테넌트가 대상 클러스터/네임스페이스를 활성화하는 데 권한 있는 클러스터 관리자를 사용하지 않고도 Argo CD를 사용하여 애플리케이션을 배포할 수 있는 기능이 개선되었습니다.
ApplicationSet
Operator는 클러스터 의사 결정 생성기를 활용하여 사용자 정의 리소스별 논리를 사용하여 배포할 관리 클러스터를 결정하는 Kubernetes 사용자 정의 리소스를 연결합니다. 클러스터 의사 결정 리소스는 관리되는 클러스터 목록을 생성한 다음 ApplicationSet
리소스의 템플릿 필드로 렌더링됩니다. 이 작업은 참조된 Kubernetes 리소스의 전체 모양에 대한 지식이 필요하지 않은 duck-typing을 사용하여 수행됩니다.
ApplicationSet
내에서 generators.clusterDecisionResource
값의 다음 예를 참조하십시오.
apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: sample-application-set namespace: sample-gitops-namespace spec: generators: - clusterDecisionResource: configMapRef: acm-placement labelSelector: matchLabels: cluster.open-cluster-management.io/placement: sample-application-placement requeueAfterSeconds: 180 template: metadata: name: sample-application-{{name}} spec: project: default sources: [ { repoURL: https://github.com/sampleapp/apprepo.git targetRevision: main path: sample-application } ] destination: namespace: sample-application server: "{{server}}" syncPolicy: syncOptions: - CreateNamespace=true - PruneLast=true - Replace=true - ApplyOutOfSyncOnly=true - Validate=false automated: prune: true allowEmpty: true selfHeal: true
다음 배치를
참조하십시오.
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: sample-application-placement namespace: sample-gitops-namespace spec: clusterSets: - sampleclusterset
ApplicationSets
에 대한 자세한 내용은 Cluster Decision Resource Generator 를 참조하십시오.
1.1.4. 애플리케이션 문서
다음 문서에서 자세히 알아보십시오.
1.2. 애플리케이션 콘솔
콘솔에는 애플리케이션 라이프사이클을 관리하기 위한 대시보드가 포함되어 있습니다. 콘솔 대시보드를 사용하여 애플리케이션을 생성 및 관리하고 애플리케이션 상태를 볼 수 있습니다. 향상된 기능을 사용하면 개발자와 운영 담당자가 클러스터 전체에서 애플리케이션을 생성, 배포, 업데이트, 관리 및 시각화할 수 있습니다.
다음 목록의 일부 콘솔 기능을 참조하십시오. 용어, 작업 및 토폴로지 읽기 방법에 대한 자세한 내용은 콘솔을 참조하십시오.
중요: 사용 가능한 작업은 할당된 역할을 기반으로 합니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.
- 관련 리소스 리포지토리, 서브스크립션 및 배치 구성을 포함하여 클러스터 전체에서 배포된 애플리케이션을 시각화합니다.
-
애플리케이션을 생성 및 편집하고 리소스를 서브스크립션합니다. 작업 메뉴에서 검색, 편집 또는 삭제할 수 있습니다. 필드를 업데이트할 때
YAML:On
을 선택하여 YAML을 보고 편집해야 합니다. - 기본 개요 탭에서 애플리케이션 이름을 클릭하여 리소스 리포지토리, 서브스크립션, 배치 및 배포된 리소스를 포함하여 Ansible Automation Platform 작업을 사용하는 선택적 사전 배포 및 배포 후 후크와 같은 세부 정보 및 애플리케이션 리소스를 볼 수 있습니다(Git 리포지토리의 경우). 개요에서 애플리케이션을 생성할 수도 있습니다.
ApplicationSet,Subscription,OpenShift,Flux, Argo CD 유형과 같은 애플리케이션을 생성하고 봅니다.
ApplicationSet
은 컨트롤러에서 생성된 Argo 애플리케이션을 나타냅니다.-
Argo CD
ApplicationSet
을 생성하려면 동기화정책에서
를 활성화해야 합니다.클러스터 상태가 변경될 때 자동으로 동기화
-
kustomization
컨트롤러가 있는 Flux의 경우kustomize.toolkit.fluxcd.io/name=<app_name
> 레이블이 있는 Kubernetes 리소스를 찾습니다. -
helm
컨트롤러가 있는 Flux의 경우helm.toolkit.fluxcd.io/name=<app_name
> 레이블이 있는 Kubernetes 리소스를 찾습니다.
-
Argo CD
- 기본 개요 에서는 표의 애플리케이션 이름을 클릭하여 단일 애플리케이션 개요를 볼 때 다음 정보를 확인할 수 있습니다.
- 리소스 상태와 같은 클러스터 세부 정보
- 리소스 토폴로지
- 서브스크립션 세부 정보
- 편집할 편집기 탭에 액세스
-
프로젝트의 모든 애플리케이션 및 리소스를 시각적으로 표시하려면 Topology 탭을 클릭합니다. Helm 서브스크립션의 경우 패키지 덮어쓰기 구성을 참조하여 적절한
packageName
및packageAlias
를 정의하여 정확한 토폴로지 표시를 가져옵니다. - 고급 구성 탭을 클릭하여 모든 애플리케이션에 대한 용어 및 리소스 테이블을 확인합니다. 리소스를 찾을 수 있으며 서브스크립션, 배치 및 채널을 필터링할 수 있습니다. 액세스 권한이 있는 경우 편집, 검색 및 삭제와 같은 여러 작업을 클릭할 수도 있습니다.
- 배포된 애플리케이션에 대해 Ansible 작업을 prehook 또는 posthook로 사용하는 경우 Ansible Automation Platform 배포를 확인합니다.
- 검색에서 리소스 시작을 클릭하여 관련 리소스를 검색합니다.
Search 를 사용하여 각 리소스의 구성 요소
종류로
애플리케이션 리소스를 찾습니다. 리소스를 검색하려면 다음 값을 사용합니다.애플리케이션 리소스 kind(검색 매개변수) 서브스크립션
서브스크립션
채널
채널
Secret
Secret
배치
배치
애플리케이션
애플리케이션
name, namespace, cluster, label 등을 포함하여 다른 필드에서 검색할 수도 있습니다. 검색 사용에 대한 자세한 내용은 콘솔 소개에서 검색을 참조하십시오.
1.3. 서브스크립션 보고서
서브스크립션 보고서는 플릿에 있는 모든 관리 클러스터의 애플리케이션 상태 컬렉션입니다. 특히 상위 애플리케이션 리소스는 확장 가능한 양의 관리 클러스터의 보고서를 저장할 수 있습니다.
허브 클러스터의 subscriptionReports
는 가볍고 확장 가능한 상태에서 관리 클러스터에서 자세한 애플리케이션 상태를 사용할 수 있습니다. 다음 세 가지 유형의 하위 상태 보고서를 참조하십시오.
-
패키지 수준
SubscriptionStatus
:appsub
네임스페이스의 애플리케이션에서 배포한 모든 리소스에 대한 자세한 상태로 관리 클러스터의 애플리케이션 패키지 상태입니다. -
클러스터 수준
SubscriptionReport
: 특정 클러스터에 배포된 모든 애플리케이션에 대한 전체 상태 보고서입니다. 애플리케이션 수준
SubscriptionReport
: 특정 애플리케이션이 배포된 모든 관리 클러스터에 대한 전체 상태 보고서입니다.
1.3.1. SubscriptionStatus 패키지 수준
패키지 수준 관리 클러스터 상태는 관리 클러스터의 < namespace:<your-appsub-namespace
>에 있으며 애플리케이션에서 배포한 모든 리소스에 대한 세부 상태를 포함합니다. 관리 클러스터에 배포된 모든 appsub
에 대해 관리 클러스터의 appsub
네임스페이스에 생성된 SubscriptionStatus
CR이 있습니다. 오류가 있는 경우 모든 리소스가 자세한 오류와 함께 보고됩니다.
패키지 상태는 개별 패키지의 상태만 나타냅니다. .status.subscription
필드를 참조하여 전체 서브스크립션 상태를 볼 수 있습니다.
다음 SubscriptionStatus
샘플 YAML 파일을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1alpha1 kind: SubscriptionStatus metadata: labels: apps.open-cluster-management.io/cluster: <your-managed-cluster> apps.open-cluster-management.io/hosting-subscription: <your-appsub-namespace>.<your-appsub-name> name: <your-appsub-name> namespace: <your-appsub-namespace> statuses: packages: - apiVersion: v1 kind: Service lastUpdateTime: "2021-09-13T20:12:34Z" Message: <detailed error. visible only if the package fails> name: frontend namespace: test-ns-2 phase: Deployed - apiVersion: apps/v1 kind: Deployment lastUpdateTime: "2021-09-13T20:12:34Z" name: frontend namespace: test-ns-2 phase: Deployed - apiVersion: v1 kind: Service lastUpdateTime: "2021-09-13T20:12:34Z" name: redis-master namespace: test-ns-2 phase: Deployed - apiVersion: apps/v1 kind: Deployment lastUpdateTime: "2021-09-13T20:12:34Z" name: redis-master namespace: test-ns-2 phase: Deployed - apiVersion: v1 kind: Service lastUpdateTime: "2021-09-13T20:12:34Z" name: redis-slave namespace: test-ns-2 phase: Deployed - apiVersion: apps/v1 kind: Deployment lastUpdateTime: "2021-09-13T20:12:34Z" name: redis-slave namespace: test-ns-2 phase: Deployed subscription: lastUpdateTime: "2021-09-13T20:12:34Z" phase: Deployed
1.3.2. SubscriptionReport 클러스터 수준
클러스터 수준 상태는 hub 클러스터의 < namespace:<your-managed-cluster-1
>에 있으며 해당 관리 클러스터의 각 애플리케이션에 대한 전체 상태만 포함됩니다. hub 클러스터의 각 클러스터 네임스페이스의 subscriptionReport
는 다음 상태 중 하나를 보고합니다.
-
배포됨
-
Failed
-
propagationFailed
다음 SubscriptionStatus
샘플 YAML 파일을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1alpha1 kind: subscriptionReport metadata: labels: apps.open-cluster-management.io/cluster: "true" name: <your-managed-cluster-1> namespace: <your-managed-cluster-1> reportType: Cluster results: - result: deployed source: appsub-1-ns/appsub-1 // appsub 1 to <your-managed-cluster-1> timestamp: nanos: 0 seconds: 1634137362 - result: failed source: appsub-2-ns/appsub-2 // appsub 2 to <your-managed-cluster-1> timestamp: nanos: 0 seconds: 1634137362 - result: propagationFailed source: appsub-3-ns/appsub-3 // appsub 3 to <your-managed-cluster-1> timestamp: nanos: 0 seconds: 1634137362
1.3.3. SubscriptionReport 애플리케이션 수준
각 애플리케이션에 대한 하나의 애플리케이션 수준 subscriptionReport
는 hub 클러스터의 appsub 네임스페이스의 < namespace:<your-
namespace>에 있으며 다음 정보를 포함합니다.
appsub
-
- 각 관리 클러스터의 애플리케이션 전체 상태
- 애플리케이션의 모든 리소스 목록
- 총 클러스터 수가 포함된 보고서 요약
-
애플리케이션이 상태에 있는 총 클러스터 수(
deployed
,failed
,propagationFailed
,inProgress
)가 포함된 보고서 요약입니다.
참고: inProcess
상태는 배포된 총 - 배치된
값입니다. - failed ', - 'propagationFailed
.
다음 SubscriptionStatus
샘플 YAML 파일을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1alpha1 kind: subscriptionReport metadata: labels: apps.open-cluster-management.io/hosting-subscription: <your-appsub-namespace>.<your-appsub-name> name: <your-appsub-name> namespace: <your-appsub-namespace> reportType: Application resources: - apiVersion: v1 kind: Service name: redis-master2 namespace: playback-ns-2 - apiVersion: apps/v1 kind: Deployment name: redis-master2 namespace: playback-ns-2 - apiVersion: v1 kind: Service name: redis-slave2 namespace: playback-ns-2 - apiVersion: apps/v1 kind: Deployment name: redis-slave2 namespace: playback-ns-2 - apiVersion: v1 kind: Service name: frontend2 namespace: playback-ns-2 - apiVersion: apps/v1 kind: Deployment name: frontend2 namespace: playback-ns-2 results: - result: deployed source: cluster-1 //cluster 1 status timestamp: nanos: 0 seconds: 0 - result: failed source: cluster-3 //cluster 2 status timestamp: nanos: 0 seconds: 0 - result: propagationFailed source: cluster-4 //cluster 3 status timestamp: nanos: 0 seconds: 0 summary: deployed: 8 failed: 1 inProgress: 0 propagationFailed: 1 clusters: 10
1.3.4. ManagedClusterView
ManagedClusterView
CR은 첫 번째 실패한
클러스터에서 보고됩니다. 애플리케이션이 리소스 배포 실패가 있는 여러 클러스터에 배포된 경우 허브 클러스터에서 첫 번째 실패한 클러스터 네임스페이스에 대해 하나의 managedClusterView
CR만 생성됩니다. managedClusterView
CR은 실패한 클러스터에서 세부 서브스크립션 상태를 검색하여 애플리케이션 소유자가 실패한 원격 클러스터에 액세스할 필요가 없도록 합니다.
상태를 가져오기 위해 실행할 수 있는 다음 명령을 참조하십시오.
% oc get managedclusterview -n <failing-clusternamespace> "<app-name>-<app name>"
1.3.5. CLI 애플리케이션 수준 상태
관리 클러스터에 액세스하여 서브스크립션 상태를 가져올 수 없는 경우 CLI를 사용할 수 있습니다. 클러스터 수준 또는 애플리케이션 수준 구독 보고서는 전체 상태를 제공하지만 애플리케이션에 대한 자세한 오류 메시지는 제공하지 않습니다.
- multicloud-operators-subscription 에서 CLI를 다운로드합니다.
-
다음 명령을 실행하여 오류를 식별할 수 있도록 관리 클러스터 애플리케이션
SubscriptionStatus
를 보려면managedClusterView
리소스를 생성합니다.
% getAppSubStatus.sh -c <your-managed-cluster> -s <your-appsub-namespace> -n <your-appsub-name>
1.3.6. CLI 마지막 업데이트 시간
또한 이 정보를 검색하기 위해 각 관리 클러스터에 로그인하는 것이 실용적이지 않은 경우 지정된 관리 클러스터에서 앱 서브의 마지막 업데이트 시간을 가져올 수도 있습니다. 따라서 관리 클러스터에서 AppSub의 마지막 업데이트 시간 검색을 간소화하기 위해 유틸리티 스크립트가 생성되었습니다. 이 스크립트는 Hub 클러스터에서 실행되도록 설계되었습니다. 관리 클러스터에서 AppSub를 가져오고 마지막 업데이트 시간을 가져오기 위해 데이터를 구문 분석하기 위해 managedClusterView 리소스를 생성합니다.
- multicloud-operators-subscription 에서 CLI를 다운로드합니다.
-
다음 명령을 실행하여 관리 클러스터에서
App
검색합니다. 이 스크립트는 hub 클러스터에서 실행되도록 설계되었습니다. 관리 클러스터에서 AppSub를 가져오고 마지막 업데이트 시간을 가져오기 위해 데이터를 구문 분석하기 위해Sub
의 마지막 업데이트 시간을managedClusterView
리소스를 생성합니다.
% getLastUpdateTime.sh -c <your-managed-cluster> -s <your-appsub-namespace> -n <your-appsub-name>
1.4. 애플리케이션 리소스 관리
콘솔에서 Git 리포지토리, Helm 리포지토리 및 오브젝트 스토리지 리포지토리를 사용하여 애플리케이션을 생성할 수 있습니다.
중요: Git 채널은 Helm, 오브젝트 스토리지 및 기타 Git 네임스페이스와 다른 모든 채널 유형과 네임스페이스를 공유할 수 있습니다.
앱 관리를 시작하려면 다음 항목을 참조하십시오.
1.4.1. Git 리포지토리를 사용하여 앱 관리
애플리케이션을 사용하여 Kubernetes 리소스를 배포할 때 리소스는 특정 리포지토리에 있습니다. 다음 절차에서 Git 리포지토리에서 리소스를 배포하는 방법을 알아봅니다. 애플리케이션 모델 및 정의에서 애플리케이션 모델에 대해 자세히 알아보십시오.
사용자 필수 액세스: 애플리케이션을 생성할 수 있는 사용자 역할입니다. 역할이 할당된 작업만 수행할 수 있습니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.
- 콘솔 탐색 메뉴에서 애플리케이션을 클릭하여 나열된 애플리케이션을 확인하고 새 애플리케이션을 생성합니다.
- 선택 사항: 생성할 애플리케이션 종류를 선택한 후 YAML 을 선택하여 애플리케이션을 생성하고 편집할 때 콘솔에서 YAML을 볼 수 있습니다. 주제의 뒷부분에 있는 YAML 샘플을 참조하십시오.
사용할 수 있는 리포지토리 목록에서 Git 을 선택하고 올바른 필드에 값을 입력합니다. 콘솔의 지침에 따라 입력에 따라 YAML 편집기 변경 값을 확인합니다.
참고:
- 기존 Git 리포지토리 경로를 선택하는 경우 개인 리포지토리인 경우 연결 정보를 지정할 필요가 없습니다. 연결 정보는 미리 설정되어 있으므로 이러한 값을 볼 필요가 없습니다.
- 새 Git 리포지토리 경로를 입력하면 개인 Git 리포지토리인 경우 Git 연결 정보를 선택적으로 입력할 수 있습니다.
-
조정 옵션을 확인합니다.
merge
옵션은 기본 선택이며, 이는 새 필드가 추가되고 리소스에서 기존 필드가 업데이트됨을 의미합니다.교체
하도록 선택할 수 있습니다.replace
옵션을 사용하면 기존 리소스가 Git 소스로 교체됩니다. 서브스크립션 조정 비율이낮게
설정되면 서브스크립션된 애플리케이션 리소스를 조정하는 데 최대 1시간이 걸릴 수 있습니다. 단일 애플리케이션 뷰의 카드에서 동기화 를 클릭하여 수동으로 조정합니다.off
로 설정하면 조정되지 않습니다.
-
선택적 사전 배포 및 배포 후 작업을 설정합니다. 서브스크립션 이전 또는 이후에 실행할 Ansible Automation Platform 작업이 있는 경우 Ansible Automation Platform 시크릿을 설정합니다. 작업을 정의하는 Ansible Automation Platform 작업은 이 리포지토리의
prehook
및posthook
폴더 내에 배치해야 합니다. - 콘솔을 사용하여 인증 정보를 추가해야 하는 경우 인증 정보 추가 를 클릭할 수 있습니다. 콘솔의 지침을 따르십시오. 인증 정보 관리 개요 에서 자세한 내용을 참조하십시오.
- 생성을 클릭합니다.
- 세부 정보 및 토폴로지를 볼 수 있는 개요 페이지로 리디렉션됩니다.
1.4.1.1. 더 많은 예
-
root-subscription/
의 예는application-subscribe-all
을 참조하십시오. -
동일한 리포지토리의 다른 폴더를 가리키는 서브스크립션의 예는
subscribe-all
을 참조하십시오. -
nginx-apps
리포지토리에서 애플리케이션 아티팩트가 있는common-managed
폴더의 예를 참조하십시오. - 정책 컬렉션의 정책 예제를 참조하십시오.
1.4.1.2. Git을 사용하여 서브스크립션을 삭제한 후 배포된 리소스 유지
Git 리포지토리를 사용하여 서브스크립션을 생성할 때 do-not-delete
주석을 추가하여 서브스크립션을 삭제한 후 특정 배포된 리소스를 유지할 수 있습니다. do-not-delete
주석은 최상위 배포 리소스에서만 작동합니다. do-not-delete
주석을 추가하려면 다음 단계를 완료합니다.
- 하나 이상의 리소스를 배포하는 서브스크립션을 생성합니다.
서브스크립션을 삭제한 후에도 유지하려는 리소스 또는 리소스에 다음 주석을 추가합니다.
apps.open-cluster-management.io/do-not-delete: 'true'
다음 예제를 참조하십시오.
apiVersion: v1 kind: PersistentVolumeClaim metadata: annotations: apps.open-cluster-management.io/do-not-delete: 'true' apps.open-cluster-management.io/hosting-subscription: sub-ns/subscription-example apps.open-cluster-management.io/reconcile-option: merge pv.kubernetes.io/bind-completed: "yes"
서브스크립션을 삭제한 후에도 다른 리소스가 삭제되는 동안 do-not-delete
주석이 있는 리소스가 여전히 존재합니다.
참고: 네임스페이스에 바인딩되는 do-not-delete
주석을 사용하여 배포된 리소스입니다. 따라서 나머지 리소스를 제거할 때까지 네임스페이스를 삭제할 수 없습니다.
1.4.2. Helm 리포지터리를 사용하여 앱 관리
애플리케이션을 사용하여 Kubernetes 리소스를 배포할 때 리소스는 특정 리포지토리에 있습니다. 다음 절차에서 Helm 리포지토리에서 리소스를 배포하는 방법을 알아봅니다. 애플리케이션 모델 및 정의에서 애플리케이션 모델에 대해 자세히 알아보십시오.
사용자 필수 액세스: 애플리케이션을 생성할 수 있는 사용자 역할입니다. 역할이 할당된 작업만 수행할 수 있습니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.
- 콘솔 탐색 메뉴에서 애플리케이션을 클릭하여 나열된 애플리케이션을 확인하고 새 애플리케이션을 생성합니다.
- 선택 사항: 생성할 애플리케이션 종류를 선택한 후 YAML 을 선택하여 애플리케이션을 생성하고 편집할 때 콘솔에서 YAML을 볼 수 있습니다. 주제의 뒷부분에 있는 YAML 샘플을 참조하십시오.
- 사용할 수 있는 리포지토리 목록에서 Helm 을 선택하고 올바른 필드의 값을 입력합니다. 콘솔의 지침에 따라 입력에 따라 YAML 편집기 변경 값을 확인합니다.
- 생성을 클릭합니다.
- 세부 정보 및 토폴로지를 볼 수 있는 개요 페이지로 리디렉션됩니다.
1.4.2.1. 샘플 YAML
다음 예제 채널 정의는 Helm 리포지터리를 채널로 추상화합니다.
참고: Helm 차트에 포함된 모든 Kubernetes 리소스에 레이블 릴리스가 있어야 합니다. 애플리케이션 토폴로지가 올바르게 표시되도록 {{ .release.Name }}'
입니다.
apiVersion: v1 kind: Namespace metadata: name: hub-repo --- apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: helm namespace: hub-repo spec: pathname: [https://kubernetes-charts.storage.googleapis.com/] # URL points to a valid chart URL. type: HelmRepo
다음 채널 정의에서는 Helm 리포지터리 채널의 또 다른 예를 보여줍니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: predev-ch namespace: ns-ch labels: app: nginx-app-details spec: type: HelmRepo pathname: https://kubernetes-charts.storage.googleapis.com/
참고: REST API를 보려면 API를 사용하십시오.
1.4.2.2. Helm을 사용하여 서브스크립션을 삭제한 후 배포된 리소스 유지
Helm은 서브스크립션을 삭제한 후 특정 배포된 리소스를 유지하기 위한 주석을 제공합니다. 자세한 내용은 리소스를 설치 제거하지 않으려면 Tell Helm Not To Uninstall a Resource 를 참조하십시오.
참고: 주석은 Helm 차트에 있어야 합니다.
1.4.3. 오브젝트 스토리지 리포지토리를 사용하여 앱 관리
애플리케이션을 사용하여 Kubernetes 리소스를 배포할 때 리소스는 특정 리포지토리에 있습니다. 애플리케이션 모델 및 정의에서 애플리케이션 모델에 대해 자세히 알아보십시오.
사용자 필수 액세스: 애플리케이션을 생성할 수 있는 사용자 역할입니다. 역할이 할당된 작업만 수행할 수 있습니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.
- 콘솔 탐색 메뉴에서 애플리케이션을 클릭하여 나열된 애플리케이션을 확인하고 새 애플리케이션을 생성합니다.
- 선택 사항: 생성할 애플리케이션 종류를 선택한 후 YAML 을 선택하여 애플리케이션을 생성하고 편집할 때 콘솔에서 YAML을 볼 수 있습니다. 주제의 뒷부분에 있는 YAML 샘플을 참조하십시오.
- 사용할 수 있는 리포지토리 목록에서 오브젝트 저장소를 선택하고 올바른 필드의 값을 입력합니다. 콘솔의 지침에 따라 입력에 따라 YAML 편집기 변경 값을 확인합니다.
- 생성을 클릭합니다.
- 세부 정보 및 토폴로지를 볼 수 있는 개요 페이지로 리디렉션됩니다.
1.4.3.1. 샘플 YAML
다음 예제 채널 정의는 오브젝트 스토리지를 채널로 추상화합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: dev namespace: ch-obj spec: type: Object storage pathname: [http://sample-ip:#####/dev] # URL is appended with the valid bucket name, which matches the channel name. secretRef: name: miniosecret gates: annotations: dev-ready: true
참고: REST API를 보려면 API를 사용하십시오.
1.4.3.2. AWS(Amazon Web Services) S3 오브젝트 스토리지 버킷 생성
Amazon Simple Storage Service(Amazon S3) 오브젝트 스토리지 서비스에 정의된 리소스를 서브스크립션하기 위해 서브스크립션을 설정할 수 있습니다. 다음 절차를 참조하십시오.
- AWS 계정, 사용자 이름 및 암호를 사용하여 AWS 콘솔에 로그인합니다.
- Amazon S3 > Buckets 로 이동합니다. 버킷 홈 페이지로 이동합니다.
- 버킷 생성 을 클릭하여 버킷을 생성합니다.
- AWS S3 오브젝트 버킷 연결에 필요한 AWS 리전 을 선택합니다.
- 버킷 액세스 토큰을 생성합니다.
- 탐색 모음에서 사용자 이름으로 이동한 다음 드롭다운 메뉴에서 내 보안 자격 증명을 선택합니다.
- AWS IAM 인증 정보 탭에서 CLI, SDK 및 API 액세스에 대한 액세스 키로 이동하여 액세스 키 생성 을 클릭합니다.
- 액세스 키 ID , 시크릿 액세스 키를 저장합니다.
- 오브젝트 YAML 파일을 버킷에 업로드합니다.
1.4.3.3. AWS 버킷의 오브젝트 구독
- 시크릿이 있는 오브젝트 버킷 유형 채널을 생성하여 AWS 버킷 연결을 위한 AccessKeyID,SecretAccessKey 및 리전 을 지정합니다. 세 개의 필드는 AWS 버킷이 생성될 때 생성됩니다.
URL을 추가합니다. URL에 s3
:// 또는
버킷의 채널을 식별합니다. 예를 들어 다음 버킷 URL에 AWS s3 버킷 식별자가 있는지 확인합니다.s
3 및 aws 키워드가 포함된 경우 URL은 AWS S3https://s3.console.aws.amazon.com/s3/buckets/sample-bucket-1 s3://sample-bucket-1/ https://sample-bucket-1.s3.amazonaws.com/
참고: AWS S3 오브젝트 버킷 URL은 버킷을 AWS S3 API와 연결하는 데 필요하지 않습니다.
1.4.3.4. 샘플 AWS 서브스크립션
다음 전체 AWS S3 오브젝트 버킷 채널 샘플 YAML 파일을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: object-dev namespace: ch-object-dev spec: type: ObjectBucket pathname: https://s3.console.aws.amazon.com/s3/buckets/sample-bucket-1 secretRef: name: secret-dev --- apiVersion: v1 kind: Secret metadata: name: secret-dev namespace: ch-object-dev stringData: AccessKeyID: <your AWS bucket access key id> SecretAccessKey: <your AWS bucket secret access key> Region: <your AWS bucket region> type: Opaque
더 이상 사용되지 않음: kind: PlacementRule
및 kind: Subscription
이 추가된 다음 샘플 YAML에서 볼 수 있듯이 다른 AWS 서브스크립션 및 배치 규칙 오브젝트를 계속 생성할 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: towhichcluster namespace: obj-sub-ns spec: clusterSelector: {} --- apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: obj-sub namespace: obj-sub-ns spec: channel: ch-object-dev/object-dev placement: placementRef: kind: PlacementRule name: towhichcluster
오브젝트 버킷의 특정 하위 폴더 내의 오브젝트를 구독할 수도 있습니다. 서브스크립션에 subfolder
주석을 추가하여 오브젝트 버킷 서브스크립션이 하위 경로의 모든 리소스만 적용하도록 강제 적용합니다.
subfolder-1
이 있는 주석을 bucket-path
로 참조하십시오.
annotations: apps.open-cluster-management.io/bucket-path: <subfolder-1>
하위 폴더는 다음 전체 샘플을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: annotations: apps.open-cluster-management.io/bucket-path: subfolder1 name: obj-sub namespace: obj-sub-ns labels: name: obj-sub spec: channel: ch-object-dev/object-dev placement: placementRef: kind: PlacementRule name: towhichcluster
1.4.3.5. 오브젝트 스토리지를 사용하여 서브스크립션을 삭제한 후 배포된 리소스 유지
오브젝트 스토리지 리포지터리를 사용하여 서브스크립션을 생성할 때 do-not-delete
주석을 추가하여 서브스크립션을 삭제한 후 특정 배포된 리소스를 유지할 수 있습니다. do-not-delete
주석은 최상위 배포 리소스에서만 작동합니다. do-not-delete
주석을 추가하려면 다음 단계를 완료합니다.
- 하나 이상의 리소스를 배포하는 서브스크립션을 생성합니다.
서브스크립션을 삭제한 후에도 유지하려는 리소스 또는 리소스에 다음 주석을 추가합니다.
apps.open-cluster-management.io/do-not-delete: 'true'
다음 예제를 참조하십시오.
apiVersion: v1 kind: PersistentVolumeClaim metadata: annotations: apps.open-cluster-management.io/do-not-delete: 'true' apps.open-cluster-management.io/hosting-subscription: sub-ns/subscription-example apps.open-cluster-management.io/reconcile-option: merge pv.kubernetes.io/bind-completed: "yes"
서브스크립션을 삭제한 후에도 다른 리소스가 삭제되는 동안 do-not-delete
주석이 있는 리소스가 여전히 존재합니다.
참고: 네임스페이스에 바인딩되는 do-not-delete
주석을 사용하여 배포된 리소스입니다. 따라서 나머지 리소스를 제거할 때까지 네임스페이스를 삭제할 수 없습니다.
1.5. Ansible Automation Platform 통합 및 도입
Red Hat Advanced Cluster Management는 Red Hat Ansible Automation Platform과 통합되어 Git 서브스크립션 애플리케이션 관리를 위한 prehook 및 posthook AnsibleJob
인스턴스를 생성할 수 있습니다. 구성 요소 및 Ansible Automation Platform 구성 방법에 대해 알아봅니다.
필수 액세스: 클러스터 관리자
1.5.1. 통합 및 구성 요소
Ansible Automation Platform 작업을 Git 서브스크립션에 통합할 수 있습니다. 예를 들어 데이터베이스 프런트 엔드 및 백엔드 애플리케이션의 경우 Ansible Automation Platform 작업에서 Ansible Automation Platform을 사용하여 데이터베이스를 인스턴스화해야 합니다. 애플리케이션은 Git 서브스크립션을 통해 설치됩니다. 서브스크립션을 사용하여 프런트 엔드 및 백엔드 애플리케이션을 배포하기 전에 데이터베이스가 인스턴스화됩니다.
애플리케이션 서브스크립션 Operator는 prehook
및 posthook
라는 두 개의 하위 폴더를 정의하도록 향상되었습니다. 두 폴더 모두 Git 리포지토리 리소스 루트 경로에 있으며 각각 prehook 및 posthook Ansible Automation Platform 작업을 포함합니다.
Git 서브스크립션이 생성되면 모든 prehook 및 posthook AnsibleJob
리소스가 구문 분석되어 메모리에 오브젝트로 저장됩니다. 애플리케이션 서브스크립션 컨트롤러는 prehook 및 posthook AnsibleJob
인스턴스를 생성할 시기를 결정합니다.
서브스크립션 사용자 지정 리소스를 생성할 때 Git 분기 및 Git 경로는 Git 리포지토리 루트 위치를 가리킵니다. Git 루트 위치에서 두 개의 하위 폴더 prehook
및 posthook
에는 Kind:AnsibleJob
리소스가 하나 이상 포함되어야 합니다.
1.5.1.1. prehook
애플리케이션 서브스크립션 컨트롤러는 prehook AnsibleJob
오브젝트로 prehook 폴더의 모든 kind:AnsibleJob
CR을 검색한 다음 새 prehook AnsibleJob
인스턴스를 생성합니다. 새 인스턴스 이름은 prehook AnsibleJob
오브젝트 이름과 임의의 접미사 문자열입니다.
다음 예제 인스턴스 이름: database-sync-1-2913063
을 참조하십시오.
애플리케이션 서브스크립션 컨트롤러는 1분 루프에 조정 요청을 다시 대기열에 넣습니다. 여기서 prehook AnsibleJob
상태를 확인합니다.AnsibleJobResult
. prehook 상태가 성공하면
애플리케이션 서브스크립션이 기본 서브스크립션을 계속 배포합니다.
1.5.1.2. posthook
애플리케이션 서브스크립션 상태가 업데이트되면 서브스크립션 상태가 서브스크립션 상태인 모든 대상 클러스터에 가입하거나 전파되면 애플리케이션 서브스크립션 컨트롤러는 posthook AnsibleJob
오브젝트로 posthook 폴더의 모든 AnsibleJob
유형의
사용자 정의 리소스를 검색합니다. 그런 다음 새 posthook AnsibleJob
인스턴스를 생성합니다. 새 인스턴스 이름은 posthook AnsibleJob
오브젝트 이름과 임의의 접미사 문자열입니다.
다음 예제 인스턴스 이름: service-ticket-1-2913849
를 참조하십시오.
{aap_short}을 활성화하려면 다음 항목을 참조하십시오.
1.5.2. Ansible Automation Platform 설정
Ansible Automation Platform 작업을 사용하면 작업을 자동화하고 Slack 및 PagerDuty 서비스와 같은 외부 서비스와 통합할 수 있습니다. Git 리포지토리 리소스 루트 경로에는 애플리케이션 배포, 애플리케이션 업데이트 또는 클러스터에서 애플리케이션 제거의 일부로 실행되는 Ansible Automation Platform 작업의 prehook
및 posthook
디렉터리가 포함됩니다.
필수 액세스: 클러스터 관리자
1.5.2.1. 사전 요구 사항
- OpenShift Container Platform 4.13 이상을 설치합니다.
- Ansible Automation Platform을 설치합니다. 지원되는 최신 버전을 설치하려면 Red Hat Ansible Automation Platform Documenation을 참조하십시오.
- Ansible Automation Platform Resource Operator를 설치하여 Ansible Automation Platform 작업을 Git 서브스크립션 라이프사이클에 연결합니다. 모범 사례: Ansible Automation Platform 작업 템플릿은 멱등이어야 합니다.
-
INVENTORY
및EXTRA VARIABLES
둘 다에 대해 템플릿에서PROMPT ON
Cryostat를 선택합니다. 자세한 내용은 작업 템플릿을 참조하십시오.
1.5.2.2. Ansible Automation Platform Resource Operator 설치
- OpenShift Container Platform 클러스터 콘솔에 로그인합니다.
- 콘솔 탐색에서 OperatorHub 를 클릭합니다.
Ansible Automation Platform Resource Operator 를 검색하고 설치합니다. 참고: prehook 및 posthook
AnsibleJobs
를 제출하려면 다음 OpenShift Container Platform 버전에서 사용 가능한 해당 버전으로 Red Hat Ansible Automation Platform Resource Operator를 설치합니다.- OpenShift Container Platform 4.8 필요 (AAP) Resource Operator early-access, stable-2.1, stable-2.2
- OpenShift Container Platform 4.9 needs (AAP) Resource Operator early-access, stable-2.1, stable-2.2
- OpenShift Container Platform 4.10 이상 필요 (AAP) Resource Operator stable-2.1, stable-2.2
그런 다음 콘솔의 인증 정보 페이지에서 인증 정보를 생성할 수 있습니다. 인증 정보 추가 를 클릭하거나 탐색의 페이지에 액세스합니다. 인증 정보 정보는 Ansible Automation Platform의 인증 정보 생성 을 참조하십시오.
1.5.3. Ansible Automation Platform 구성
With {aap-short} jobs, you can automate tasks and integrate with external services, such as Slack and PagerDuty services. Your Git repository resource root path will contain `prehook` and `posthook` directories for {aap-short} jobs that run as part of deploying the application, updating the application, or removing the application from a cluster.
필수 액세스: 클러스터 관리자
다음 작업을 사용하여 Ansible Automation Platform 구성을 구성할 수 있습니다.
1.5.3.1. Ansible Automation Platform 시크릿 설정
동일한 서브스크립션 네임스페이스에 Ansible Automation Platform 시크릿 사용자 정의 리소스를 생성해야 합니다. Ansible Automation Platform 시크릿은 동일한 서브스크립션 네임스페이스로 제한됩니다.
Ansible Automation Platform 시크릿 이름 섹션을 작성하여 콘솔에서 시크릿을
생성합니다. 터미널을 사용하여 보안을 생성하려면 샘플yaml
파일을 편집하고 적용합니다.참고:
네임스페이스
는 서브스크립션 네임스페이스와 동일합니다.stringData:token
및host
는 Ansible Automation Platform에서 가져온 것입니다.apiVersion: v1 kind: Secret metadata: name: toweraccess namespace: same-as-subscription type: Opaque stringData: token: ansible-tower-api-token host: https://ansible-tower-host-url
다음 명령을 실행하여 YAML 파일을 추가합니다.
oc apply -f
앱 서브스크립션 컨트롤러에서 prehook 및 posthook Ansible 작업을 생성할 때 subscription spec.hooksecretref
의 시크릿을 사용할 수 있는 경우 AnsibleJob
사용자 정의 리소스 spec.tower_auth_secret
으로 전송되고 AnsibleJob
은 Ansible Automation Platform에 액세스할 수 있습니다.
1.5.3.2. 보안 조정 설정
prehook 및 posthook AnsibleJob
이 포함된 기본 서브스크립션의 경우 모든 prehook 및 posthook AnsibleJob
또는 기본 서브스크립션이 Git 리포지토리에서 업데이트된 후 기본 서브스크립션을 조정해야 합니다.
prehook AnsibleJob
및 기본 서브스크립션은 새 pre AnsibleJob
인스턴스를 지속적으로 조정 및 다시 시작합니다.
-
pre
AnsibleJob
이 완료된 후 기본 서브스크립션을 다시 실행합니다. - 기본 서브스크립션에 사양 변경 사항이 있는 경우 서브스크립션을 재배포합니다. 재배포 절차에 맞게 기본 서브스크립션 상태를 업데이트해야 합니다.
hub 클러스터 서브스크립션 상태를
nil
로 재설정합니다. 서브스크립션은 대상 클러스터에서 서브스크립션 배포와 함께 새로 고쳐집니다.대상 클러스터에서 배포가 완료되면 대상 클러스터의 서브스크립션 상태가 "서브스크립션
" 또는 "
실패"
로 업데이트되고 허브 클러스터 서브스크립션 상태와 동기화됩니다.-
기본 서브스크립션이 완료되면 새
AnsibleJob
인스턴스를 다시 시작합니다. 서브스크립션이 업데이트되었는지 확인합니다. 다음 출력을 참조하십시오.
-
subscription.status ==
"subscribed"
-
subscription.status == 모든 대상 클러스터가
"서브스크립션됨"
-
subscription.status ==
AnsibleJob
사용자 정의 리소스가 생성되면 대상 Ansible Automation Platform과 통신하여 Ansible Automation Platform 작업을 시작하기 위해 Kubernetes 작업 사용자 정의 리소스가 생성됩니다. 작업이 완료되면 작업의 최종 상태가 AnsibleJob
status.AnsibleJob Result
로 반환됩니다.
참고:
AnsibleJob
status.conditions
는 Kubernetes 작업 결과 생성을 저장하기 위해 Ansible Automation Platform 작업 Operator에 의해 예약되어 있습니다. status.conditions
는 실제 Ansible Automation Platform 작업 상태를 반영하지 않습니다.
서브스크립션 컨트롤러는 AnsibleJob.status.conditions
대신 AnsibleJob.status.AnsibleJob.Result
에서 Ansible Automation Platform 작업 상태를 확인합니다.
이전에 prehook 및 posthook AnsibleJob
워크플로우에서 언급했듯이 기본 서브스크립션이 Git 리포지토리에서 업데이트되면 새 prehook 및 posthook AnsibleJob
인스턴스가 생성됩니다. 결과적으로 하나의 기본 서브스크립션이 여러 AnsibleJob
인스턴스에 연결할 수 있습니다.
4개의 필드는 subscription.status.ansiblejobs
에 정의되어 있습니다.
-
lastPrehookJobs
: 가장 최근 prehook Ansible 작업 -
prehookJobsHistory
: All the prehook Ansible jobs history -
lastPosthookJobs
: 가장 최근 posthook Ansible 작업 -
posthookJobsHistory
: 모든 posthook Ansible 작업 내역
1.5.3.3. Ansible Automation Platform 샘플 YAML 파일 사용
Git prehook 및 posthook 폴더에서 AnsibleJob
YAML 파일의 다음 샘플을 참조하십시오.
apiVersion: tower.ansible.com/v1alpha1 kind: AnsibleJob metadata: name: demo-job-001 namespace: default spec: tower_auth_secret: toweraccess job_template_name: Demo Job Template extra_vars: cost: 6.88 ghosts: ["inky","pinky","clyde","sue"] is_enable: false other_variable: foo pacman: mrs size: 8 targets_list: - aaa - bbb - ccc version: 1.23.45 job_tags: "provision,install,configuration" skip_tags: "configuration,restart"
1.5.3.4. 워크플로우 시작
AnsibleJob
사용자 정의 리소스를 사용하여 Ansible Automation Platform 워크플로를 시작하려면 다음 예에 표시되는 job_template_name
필드를 workflow_template_name
으로 바꿉니다.
1.5.3.5. Ansible Automation Platform 샘플 YAML 워크플로우 사용
Git prehook 및 Git posthook 폴더에서 워크플로 AnsibleJob
YAML 파일의 다음 샘플을 참조하십시오.
apiVersion: tower.ansible.com/v1alpha1 kind: AnsibleJob metadata: name: demo-job-001 namespace: default spec: tower_auth_secret: toweraccess workflow_template_name: Demo Workflow Template extra_vars: cost: 6.88 ghosts: ["inky","pinky","clyde","sue"] is_enable: false other_variable: foo pacman: mrs size: 8 targets_list: - aaa - bbb - ccc version: 1.23.45
Ansible 워크플로에 대한 자세한 내용은 워크플로우를 참조하십시오.
1.6. 애플리케이션 고급 구성
Red Hat Advanced Cluster Management for Kubernetes 내에서 애플리케이션은 여러 애플리케이션 리소스로 구성됩니다. 채널, 서브스크립션 및 배치를 사용하여 전체 애플리케이션을 배포, 업데이트 및 관리할 수 있습니다.
단일 클러스터 애플리케이션과 다중 클러스터 애플리케이션 모두 동일한 Kubernetes 사양을 사용하지만 다중 클러스터 애플리케이션은 배포 및 애플리케이션 관리 라이프사이클을 더욱 자동화해야 합니다.
Kubernetes 애플리케이션용 Red Hat Advanced Cluster Management의 모든 애플리케이션 구성 요소 리소스는 YAML 파일 사양 섹션에 정의되어 있습니다. 애플리케이션 구성 요소 리소스를 생성하거나 업데이트해야 하는 경우 리소스를 정의하는 레이블을 포함하도록 적절한 섹션을 생성하거나 편집해야 합니다.
다음 애플리케이션 고급 구성 주제를 확인합니다.
1.6.1. Git 리소스 구독
기본적으로 서브스크립션이 서브스크립션된 애플리케이션을 대상 클러스터에 배포하면 애플리케이션 리소스가 다른 네임스페이스와 연결되어 있어도 애플리케이션이 해당 서브스크립션 네임스페이스에 배포됩니다. 서브스크립션 관리자 권한 부여에 설명된 대로 서브스크립션 관리자는 기본 동작을 변경할 수 있습니다.
또한 애플리케이션 리소스가 클러스터에 있고 서브스크립션을 통해 생성되지 않은 경우 해당 기존 리소스에 새 리소스를 적용할 수 없습니다. 서브스크립션 관리자로 기본 설정을 변경하려면 다음 프로세스를 참조하십시오.
필수 액세스: 클러스터 관리자
1.6.1.1. Git에서 애플리케이션 리소스 생성
구독할 때 리소스 YAML에서 apiVersion
의 전체 그룹 및 버전을 지정해야 합니다. 예를 들어 apiVersion: v1
을 구독하면 서브스크립션 컨트롤러가 서브스크립션을 검증하지 못하고 Resource /v1, Kind=ImageStream이 지원되지 않습니다
.
다음 샘플과 같이 apiVersion
이 image.openshift.io/v1
로 변경된 경우 서브스크립션 컨트롤러에서 검증을 통과하고 리소스가 성공적으로 적용됩니다.
apiVersion: `image.openshift.io/v1` kind: ImageStream metadata: name: default namespace: default spec: lookupPolicy: local: true tags: - name: 'latest' from: kind: DockerImage name: 'quay.io/repository/open-cluster-management/multicluster-operators-subscription:community-latest'
다음으로 서브스크립션 관리자가 기본 동작을 변경하는 방법에 대한 더 유용한 예를 참조하십시오.
1.6.1.2. 애플리케이션 네임스페이스 예
다음 예제에서는 서브스크립션 관리자로 로그인했습니다.
1.6.1.2.1. 다른 네임스페이스에 애플리케이션
서브스크립션을 생성하여 Git 리포지토리에서 샘플 리소스 YAML 파일을 서브스크립션합니다. 예제 파일에는 다음과 같은 다른 네임스페이스 내에 있는 서브스크립션이 포함되어 있습니다.
적용 가능한 채널 유형: Git
-
ConfigMap
test-configmap-1
은다중 서버 네임스페이스에서
생성됩니다. -
ConfigMap
test-configmap-2
가기본
네임스페이스에서 생성됩니다. ConfigMap
test-configmap-3
이서브스크립션
네임스페이스에 생성됩니다.--- apiVersion: v1 kind: Namespace metadata: name: multins --- apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: multins data: path: resource1 --- apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-2 namespace: default data: path: resource2 --- apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-3 data: path: resource3
다른 사용자가 서브스크립션을 생성한 경우 서브스크립션과 동일한 네임스페이스에서 모든 ConfigMap이 생성됩니다.
1.6.1.2.2. 동일한 네임스페이스로 애플리케이션
서브스크립션 관리자는 모든 애플리케이션 리소스를 동일한 네임스페이스에 배포해야 할 수 있습니다.
허용 및 거부 목록을 서브스크립션 관리자로 생성하여 모든 애플리케이션 리소스를 서브스크립션 네임스페이스에 배포할 수 있습니다.
apps.open-cluster-management.io/current-namespace-scoped: true
주석을 서브스크립션 YAML에 추가합니다. 예를 들어 서브스크립션 관리자가 다음 서브스크립션을 생성하면 이전 예제의 세 가지 ConfigMap이 모두 subscription-ns
네임스페이스에 생성됩니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: subscription-example namespace: subscription-ns annotations: apps.open-cluster-management.io/git-path: sample-resources apps.open-cluster-management.io/reconcile-option: merge apps.open-cluster-management.io/current-namespace-scoped: "true" spec: channel: channel-ns/somechannel placement: placementRef: name: dev-clusters
1.6.1.3. 리소스 덮어쓰기 예
적용 가능한 채널 유형: Git, ObjectBucket ( 콘솔의 오브젝트 스토리지)
참고: helm
차트 리소스는 Helm에서 관리하므로 리소스 덮어쓰기 옵션은 Git 리포지토리의 helm
차트에는 적용되지 않습니다.
이 예에서는 대상 클러스터에 다음 ConfigMap이 이미 있습니다.
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: name: user1 age: 19
Git 리포지토리에서 다음 샘플 리소스 YAML 파일을 구독하고 기존 ConfigMap을 교체합니다. 데이터
사양의 변경 사항을 참조하십시오.
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: age: 20
1.6.1.3.1. 기본 병합 옵션
기본 apps.open-cluster-management.io/reconcile-option: merge
주석을 사용하여 Git 리포지토리의 다음 샘플 리소스 YAML 파일을 참조하십시오. 다음 예제를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: subscription-example namespace: sub-ns annotations: apps.open-cluster-management.io/git-path: sample-resources apps.open-cluster-management.io/reconcile-option: merge spec: channel: channel-ns/somechannel placement: placementRef: name: dev-clusters
서브스크립션 관리자가 이 서브스크립션을 생성하고 ConfigMap 리소스를 구독하면 다음 예와 같이 기존 ConfigMap이 병합됩니다.
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: name: user1 age: 20
merge
옵션을 사용하면 서브스크립션 리소스의 항목이 기존 리소스에서 생성되거나 업데이트됩니다. 기존 리소스에서 항목이 제거되지 않습니다.
중요: 서브스크립션으로 덮어쓰려는 기존 리소스가 다른 Operator 또는 컨트롤러에 의해 자동으로 조정되면 서브스크립션과 컨트롤러 또는 Operator 둘 다에서 리소스 구성이 업데이트됩니다. 이 경우에는 이 방법을 사용하지 마십시오.
1.6.1.3.2. mergeAndOwn option
mergeAndOwn
을 사용하면 서브스크립션 리소스의 항목이 기존 리소스에서 생성되거나 업데이트됩니다. 서브스크립션 관리자로 로그인하여 apps.open-cluster-management.io/reconcile-option: mergeAndOwn
주석을 사용하여 서브스크립션을 생성합니다. 다음 예제를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: subscription-example namespace: sub-ns annotations: apps.open-cluster-management.io/git-path: sample-resources apps.open-cluster-management.io/reconcile-option: mergeAndOwn spec: channel: channel-ns/somechannel placement: placementRef: name: dev-clusters
서브스크립션 관리자가 이 서브스크립션을 생성하고 ConfigMap 리소스를 구독하면 다음 예와 같이 기존 ConfigMap이 병합됩니다.
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns annotations: apps.open-cluster-management.io/hosting-subscription: sub-ns/subscription-example data: name: user1 age: 20
앞서 언급했듯이 mergeAndOwn
옵션이 사용되면 서브스크립션 리소스의 항목이 기존 리소스에서 생성되거나 업데이트됩니다. 기존 리소스에서 항목이 제거되지 않습니다. 또한 apps.open-cluster-management.io/hosting-subscription
주석을 추가하여 이제 리소스가 서브스크립션에서 소유하고 있음을 나타냅니다. 서브스크립션을 삭제하면 ConfigMap이 삭제됩니다.
1.6.1.3.3. 교체 옵션
서브스크립션 관리자로 로그인하여 apps.open-cluster-management.io/reconcile-option: replace
주석을 사용하여 서브스크립션을 생성합니다. 다음 예제를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: subscription-example namespace: sub-ns annotations: apps.open-cluster-management.io/git-path: sample-resources apps.open-cluster-management.io/reconcile-option: replace spec: channel: channel-ns/somechannel placement: placementRef: name: dev-clusters
서브스크립션 관리자가 이 서브스크립션을 생성하고 ConfigMap 리소스를 구독하면 기존 ConfigMap이 다음으로 교체됩니다.
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: age: 20
1.6.1.4. 특정 Git 요소 구독
특정 Git 분기, 커밋 또는 태그를 구독할 수 있습니다.
1.6.1.4.1. 특정 분기 구독
multicloud-operators-subscription
리포지토리에 포함된 서브스크립션 Operator는 Git 리포지토리의 기본 분기를 서브스크립션합니다. 다른 분기를 구독하려면 서브스크립션에 분기 이름 주석을 지정해야 합니다.
다음 예제로 YAML 파일은 apps.open-cluster-management.io/git-branch: <branch1
>을 사용하여 다른 분기를 지정하는 방법을 표시합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-mongodb-subscription annotations: apps.open-cluster-management.io/git-path: stable/ibm-mongodb-dev apps.open-cluster-management.io/git-branch: <branch1>
1.6.1.4.2. 특정 커밋 등록
multicloud-operators-subscription
리포지토리에 포함된 서브스크립션 Operator는 기본적으로 Git 리포지토리의 지정된 분기의 최신 커밋을 서브스크립션합니다. 특정 커밋을 구독하려면 서브스크립션에서 커밋 해시를 사용하여 원하는 커밋 주석을 지정해야 합니다.
다음 예제로 YAML 파일은 apps.open-cluster-management.io/git-desired-commit: <full commit number
>를 사용하여 다른 커밋을 지정하는 방법을 표시합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-mongodb-subscription annotations: apps.open-cluster-management.io/git-path: stable/ibm-mongodb-dev apps.open-cluster-management.io/git-desired-commit: <full commit number> apps.open-cluster-management.io/git-clone-depth: 100
git-clone-depth
주석은 선택 사항이며 기본적으로 20
으로 설정됩니다. 즉, 서브스크립션 컨트롤러는 Git 리포지토리에서 이전 20 커밋 기록을 검색합니다. 훨씬 오래된 git-desired-commit
를 지정하는 경우 원하는 커밋을 위해 git-clone-depth
를 적절하게 지정해야 합니다.
1.6.1.4.3. 특정 태그 구독
multicloud-operators-subscription
리포지토리에 포함된 서브스크립션 Operator는 기본적으로 Git 리포지토리의 지정된 분기의 최신 커밋을 서브스크립션합니다. 특정 태그를 구독하려면 서브스크립션에 태그 주석을 지정해야 합니다.
다음 예제로 YAML 파일은 apps.open-cluster-management.io/git-tag: <v1.0> :
을 사용하여 다른 태그를 지정하는 방법을 표시합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-mongodb-subscription annotations: apps.open-cluster-management.io/git-path: stable/ibm-mongodb-dev apps.open-cluster-management.io/git-tag: <v1.0> apps.open-cluster-management.io/git-clone-depth: 100
참고: Git 원하는 커밋 및 태그 주석이 모두 지정되면 태그가 무시됩니다.
git-clone-depth
주석은 선택 사항이며 기본적으로 20
으로 설정됩니다. 즉, 서브스크립션 컨트롤러에서 Git 리포지토리에서 이전 20
커밋 기록을 검색합니다. 훨씬 오래된 git-tag
를 지정하는 경우 원하는 태그 커밋에 따라 git-clone-depth
를 지정해야 합니다.
1.6.2. 서브스크립션 관리자 권한 부여
서브스크립션 관리자 액세스 권한을 부여하는 방법을 알아보십시오. 서브스크립션 관리자는 기본 동작을 변경할 수 있습니다. 다음 프로세스에서 자세히 알아보십시오.
- 콘솔에서 Red Hat OpenShift Container Platform 클러스터에 로그인합니다.
하나 이상의 사용자를 생성합니다. 사용자 생성에 대한 정보는 사용자 준비를 참조하십시오. 그룹 또는 서비스 계정을 준비할 수도 있습니다.
생성하는 사용자는
app.open-cluster-management.io/subscription
애플리케이션의 관리자입니다. OpenShift Container Platform을 사용하면 서브스크립션 관리자가 기본 동작을 변경할 수 있습니다. 이러한 사용자를 그룹화하여 나중에 설명하는 서브스크립션 관리 그룹을 나타낼 수 있습니다.- 터미널에서 Red Hat Advanced Cluster Management 클러스터에 로그인합니다.
open-cluster-management:subscription-admin
ClusterRoleBinding이 없으면 생성해야 합니다. 다음 예제를 참조하십시오.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: open-cluster-management:subscription-admin roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: open-cluster-management:subscription-admin
다음 명령을 사용하여
open-cluster-management:subscription-admin
ClusterRoleBinding에 다음 제목을 추가합니다.oc edit clusterrolebinding open-cluster-management:subscription-admin
참고: 초기에는
open-cluster-management:subscription-admin
ClusterRoleBinding에는 제목이 없습니다.주체는 다음 예와 같이 표시될 수 있습니다.
subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: example-name - apiGroup: rbac.authorization.k8s.io kind: Group name: example-group-name - kind: ServiceAccount name: my-service-account namespace: my-service-account-namespace - apiGroup: rbac.authorization.k8s.io kind: User name: 'system:serviceaccount:my-service-account-namespace:my-service-account'
서비스 계정
은 사용자 주체로 사용할 수 있습니다.
1.6.3. 서브스크립션 관리자로서 허용 및 거부 목록 생성
서브스크립션 관리자는 지정된 Kubernetes 종류
리소스만 배포할 수 있도록 허용
목록이 포함된 Git 리포지토리 애플리케이션 서브스크립션에서 애플리케이션을 생성할 수 있습니다. 애플리케이션 서브스크립션에 특정 Kubernetes 종류
리소스의 배포를 거부하기 위해 거부 목록을 생성할 수도 있습니다.
기본적으로 policy.open-cluster-management.io/v1
리소스는 애플리케이션 서브스크립션에서 배포되지 않습니다. 이 기본 동작을 방지하려면 애플리케이션 서브스크립션이 서브스크립션 관리자가 배포해야 합니다.
허용
및 거부
사양의 예는 다음과 같습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: annotations: apps.open-cluster-management.io/github-path: sub2 name: demo-subscription namespace: demo-ns spec: channel: demo-ns/somechannel allow: - apiVersion: policy.open-cluster-management.io/v1 kinds: - Policy - apiVersion: v1 kinds: - Deployment deny: - apiVersion: v1 kinds: - Service - ConfigMap placement: local: true
다음 애플리케이션 서브스크립션 YAML은 소스 리포지토리의 myapplication
디렉터리에서 애플리케이션을 배포할 때 소스 리포지토리에 다른 리소스가 있는 경우에도 v1/Deployment
리소스만 배포하도록 지정합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: annotations: apps.open-cluster-management.io/github-path: myapplication name: demo-subscription namespace: demo-ns spec: channel: demo-ns/somechannel deny: - apiVersion: v1 kinds: - Service - ConfigMap placement: placementRef: name: demo-placement kind: Placement
이 예제 애플리케이션 서브스크립션 YAML은 v1/Service
및 v1/ConfigMap
리소스를 제외한 모든 유효한 리소스의 배포를 지정합니다. API 그룹 내에서 개별 리소스 종류를 나열하는 대신 "*"
를 추가하여 API 그룹의 모든 리소스 종류를 허용하거나 거부할 수 있습니다.
1.6.4. 조정 옵션 추가
개별 리소스에서 apps.open-cluster-management.io/reconcile-option
주석을 사용하여 서브스크립션 수준 조정 옵션을 덮어쓸 수 있습니다.
예를 들어 구독에서 apps.open-cluster-management.io/reconcile-option: replace
주석을 추가하고 구독한 Git 리포지토리의 리소스 YAML에 apps.open-cluster-management.io/reconcile-option: merge
주석을 추가하는 경우 다른 리소스가 교체되는 동안 해당 리소스가 대상 클러스터에서 병합됩니다.
1.6.4.1. 빈도 Git 채널 조정
채널 구성에서 high
,medium
,low
및 off
의 빈도 옵션을 선택하여 불필요한 리소스 조정을 방지하고 서브스크립션 Operator에 대한 과부하를 방지할 수 있습니다.
필수 액세스: 관리자 및 클러스터 관리자
설정의 다음 정의를 참조하십시오.attribute:<value>
:
-
off
: 배포된 리소스가 자동으로 조정되지 않습니다.서브스크립션
사용자 정의 리소스의 변경으로 인해 조정이 시작됩니다. 레이블 또는 주석을 추가하거나 업데이트할 수 있습니다. -
낮음
: 소스 Git 리포지토리가 변경되지 않더라도 배포된 리소스는 매시간 자동으로 조정됩니다. -
중간
: 기본 설정입니다. 서브스크립션 Operator는 현재 배포된 커밋 ID를 3분마다 소스 리포지토리의 최신 커밋 ID와 비교하고 대상 클러스터에 변경 사항을 적용합니다. 15분마다 리포지토리가 변경되지 않은 경우에도 모든 리소스가 소스 Git 리포지토리에서 대상 클러스터로 다시 적용됩니다. -
High
: 소스 Git 리포지토리가 변경되지 않더라도 배포된 리소스는 2분마다 자동으로 조정됩니다.
서브스크립션에서 참조하는 채널 사용자 정의 리소스에서 apps.open-cluster-management.io/reconcile-rate
주석을 사용하여 이 값을 설정할 수 있습니다.
다음 이름: git-channel
예제를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: git-channel namespace: sample annotations: apps.open-cluster-management.io/reconcile-rate: <value from the list> spec: type: GitHub pathname: <Git URL> --- apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-subscription annotations: apps.open-cluster-management.io/git-path: <application1> apps.open-cluster-management.io/git-branch: <branch1> spec: channel: sample/git-channel placement: local: true
이전 예에서 샘플/git-channel
을 사용하는 모든 서브스크립션에는 낮은
조정 빈도가 할당됩니다.
-
서브스크립션 조정 비율이
낮게
설정되면 서브스크립션된 애플리케이션 리소스를 조정하는 데 최대 1시간이 걸릴 수 있습니다. 단일 애플리케이션 뷰의 카드에서 동기화 를 클릭하여 수동으로 조정합니다.off
로 설정하면 조정되지 않습니다.
채널의 reconcile-rate
설정에 관계없이 서브스크립션에서 Subscription
사용자 정의 리소스에서 apps.open-cluster-management.io/reconcile-rate:
주석을 지정하여 자동 조정 기능을 해제할 수 있습니다.
off
다음 git-channel
예제를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: git-channel namespace: sample annotations: apps.open-cluster-management.io/reconcile-rate: high spec: type: GitHub pathname: <Git URL> --- apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-subscription annotations: apps.open-cluster-management.io/git-path: application1 apps.open-cluster-management.io/git-branch: branch1 apps.open-cluster-management.io/reconcile-rate: "off" spec: channel: sample/git-channel placement: local: true
채널에서 reconcile-rate
가 high
로 설정된 경우에도 git-subscription
에서 배포한 리소스가 자동으로 조정되지 않음을 참조하십시오.
1.6.4.2. 빈도 Helm 채널 조정
서브스크립션 Operator는 15분마다 현재 배포된 Helm 차트 해시와 소스 리포지터리의 해시를 비교합니다. 변경 사항은 대상 클러스터에 적용됩니다. 리소스 조정 빈도는 다른 애플리케이션 배포 및 업데이트의 성능에 영향을 미칩니다.
예를 들어 수백 개의 애플리케이션 서브스크립션이 있고 모든 서브스크립션을 더 자주 조정하려는 경우 대응 시간이 느려집니다.
애플리케이션의 Kubernetes 리소스에 따라 적절한 조정 빈도로 성능이 향상될 수 있습니다.
-
off
: 배포된 리소스가 자동으로 조정되지 않습니다. 서브스크립션 사용자 정의 리소스의 변경으로 인해 조정이 시작됩니다. 레이블 또는 주석을 추가하거나 업데이트할 수 있습니다. -
낮음
: 서브스크립션 Operator는 현재 배포된 해시를 매시간 소스 리포지토리의 해시와 비교하고 변경 사항이 변경될 때 대상 클러스터에 변경 사항을 적용합니다. -
중간
: 기본 설정입니다. 서브스크립션 Operator는 현재 배포된 해시를 15분마다 소스 리포지토리의 해시와 비교하고 변경 사항이 있을 때 대상 클러스터에 변경 사항을 적용합니다. -
서브스크립션 Operator는 현재 배포된 해시를 2분마다 소스 리포지토리의 해시와 비교하고 변경 사항이 있을 때 대상 클러스터에 변경 사항을 적용합니다.
서브스크립션에서 참조하는 Channel
사용자 정의 리소스에서 apps.open-cluster-management.io/reconcile-rate
주석을 사용하여 설정할 수 있습니다. 다음 helm-channel
예제를 참조하십시오.
다음 helm-channel
예제를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: helm-channel namespace: sample annotations: apps.open-cluster-management.io/reconcile-rate: low spec: type: HelmRepo pathname: <Helm repo URL> --- apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: helm-subscription spec: channel: sample/helm-channel name: nginx-ingress packageOverrides: - packageName: nginx-ingress packageAlias: nginx-ingress-simple packageOverrides: - path: spec value: defaultBackend: replicaCount: 3 placement: local: true
이 예에서 sample/helm-channel
을 사용하는 모든 서브스크립션에는 낮은
조정 빈도가 할당됩니다.
채널의 reconcile-rate 설정에 관계없이 다음 예에 표시된 대로 subscription은 apps.open-cluster-management.io/reconcile-rate:
주석을 지정하여 자동 조정 기능을 해제할 수 있습니다. off
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: helm-channel namespace: sample annotations: apps.open-cluster-management.io/reconcile-rate: high spec: type: HelmRepo pathname: <Helm repo URL> --- apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: helm-subscription annotations: apps.open-cluster-management.io/reconcile-rate: "off" spec: channel: sample/helm-channel name: nginx-ingress packageOverrides: - packageName: nginx-ingress packageAlias: nginx-ingress-simple packageOverrides: - path: spec value: defaultBackend: replicaCount: 3 placement: local: true
이 예에서 helm-subscription
에서 배포한 리소스는 채널에서 reconcile-rate
가 high
로 설정되어 있어도 자동으로 조정되지 않습니다.
1.6.5. 리더 선택 방식 구성
LeaderElection
을 사용하면 컨트롤러가 실패한 경우 새 리더를 선택하도록 요청하는 방법을 변경하여 하나의 리더 인스턴스만 한 번에 조정을 처리하도록 할 수 있습니다. 컨트롤러가 LeaderElection
을 얻는 데 걸리는 시간을 늘리거나 줄일 수 있습니다. 시간이 단축됨에 따라 새로운 리더가 실패 중에 더 빨리 선택됩니다.
참고: 컨트롤러의 기본값을 변경하면 해당 작업 중에 시스템 성능에 영향을 미칠 수 있습니다. 리스 기간
,renewDeadline
또는 컨트롤러의 retryPeriod
의 기본값을 변경하여 etcd
부하를 줄일 수 있습니다.
필수 액세스: 클러스터 관리자
1.6.5.1. 컨트롤러 플래그 편집
LeaderElection
을 구성하려면 다음 기본값을 변경합니다.
-
leader-election-lease-duration: 137초
-
renew-deadline: 107초
-
retry-period: 26초
multicluster-operators-application
,multicluster-operators-channel
, multicluster-operators-standalone-subscription 또는
컨트롤러를 변경하려면 다음 단계를 참조하십시오.
multicluster-operators
-hub-subscription
다음 명령을 실행하여
multiclusterhub
를 일시 중지합니다.oc annotate mch -n open-cluster-management multiclusterhub mch-pause=true --overwrite=true
oc edit
명령에 컨트롤러 이름을 추가하여배포
파일을 편집합니다. 다음 예제 명령을 참조하십시오.oc edit deployment -n open-cluster-management multicluster-operators-hub-subscription
-
-
명령을 검색하여 컨트롤러 명령 플래그를 찾습니다. -
컨트롤러의 containers 섹션에서
- 명령
플래그를 삽입합니다. 예를 들어RetryPeriod
를 삽입합니다. - 파일을 저장합니다. 컨트롤러가 자동으로 다시 시작되어 플래그를 적용합니다.
- 변경하려는 각 컨트롤러에 대해 이 절차를 반복합니다.
-
다음 명령을 실행하여
multiclusterhub
를 다시 시작합니다.
oc annotate mch -n open-cluster-management multiclusterhub mch-pause=false --overwrite=true
command
에 대한 성공적으로 편집의 다음 예제 출력을 참조하십시오. retryPeriod
플래그가 이전에 언급된 기본 시간을 52
로 두 배로 늘립니다. 이 경우 leaderElection
을 다시 시도합니다.
command: - /usr/local/bin/multicluster-operators-subscription - --sync-interval=60 - --retry-period=52
1.6.6. 보안 Git 연결을 위한 애플리케이션 채널 및 서브스크립션 구성
Git 채널 및 서브스크립션은 HTTPS 또는 SSH를 통해 지정된 Git 리포지토리에 연결합니다. 다음 애플리케이션 채널 구성은 보안 Git 연결에 사용할 수 있습니다.
1.6.6.1. 사용자 및 액세스 토큰을 사용하여 개인 리포지토리에 연결
채널 및 서브스크립션을 사용하여 Git 서버에 연결할 수 있습니다. 사용자 및 액세스 토큰을 사용하여 프라이빗 리포지토리에 연결하려면 다음 절차를 참조하십시오.
채널과 동일한 네임스페이스에 시크릿을 생성합니다.
user
필드를 Git 사용자 ID로 설정하고accessToken
필드를 Git 개인 액세스 토큰으로 설정합니다. 값은 base64로 인코딩되어야 합니다. user 및 accessToken이 채워진 다음 샘플을 참조하십시오.apiVersion: v1 kind: Secret metadata: name: my-git-secret namespace: channel-ns data: user: dXNlcgo= accessToken: cGFzc3dvcmQK
시크릿을 사용하여 채널을 구성합니다.
secretRef
가 채워진 다음 샘플을 참조하십시오.apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: sample-channel namespace: channel-ns spec: type: Git pathname: <Git HTTPS URL> secretRef: name: my-git-secret
1.6.6.2. Git 서버에 비보안 HTTPS 연결
개발 환경에서 다음 연결 방법을 사용하여 사용자 지정 또는 자체 서명된 인증 기관에서 서명한 SSL 인증서를 사용하여 개인 호스팅 Git 서버에 연결할 수 있습니다. 그러나 이 절차는 프로덕션에는 권장되지 않습니다.
채널 사양에 insecureSkipVerify: true
를 지정합니다. 그러지 않으면 Git 서버에 대한 연결이 실패하고 다음과 유사한 오류가 발생합니다.
x509: certificate is valid for localhost.com, not localhost
이 방법은 채널 사양을 추가하여 다음 샘플을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: labels: name: sample-channel namespace: sample spec: type: GitHub pathname: <Git HTTPS URL> insecureSkipVerify: true
1.6.6.3. 보안 HTTPS 연결에 사용자 정의 CA 인증서 사용
이 연결 방법을 사용하여 사용자 지정 또는 자체 서명된 인증 기관에서 서명한 SSL 인증서를 사용하여 개인 호스팅 Git 서버에 안전하게 연결할 수 있습니다.
PEM 형식으로 Git 서버 루트 및 중간 CA 인증서를 포함하는 ConfigMap을 생성합니다. ConfigMap은 channel CR과 동일한 네임스페이스에 있어야 합니다. 필드 이름은
caCerts
및 use|
여야 합니다. 다음 샘플에서caCerts
는 루트 및 중간 CA와 같은 여러 인증서를 포함할 수 있습니다.apiVersion: v1 kind: ConfigMap metadata: name: git-ca namespace: channel-ns data: caCerts: | # Git server root CA -----BEGIN CERTIFICATE----- MIIF5DCCA8wCCQDInYMol7LSDTANBgkqhkiG9w0BAQsFADCBszELMAkGA1UEBhMC Q0ExCzAJBgNVBAgMAk9OMRAwDgYDVQQHDAdUb3JvbnRvMQ8wDQYDVQQKDAZSZWRI YXQxDDAKBgNVBAsMA0FDTTFFMEMGA1UEAww8Z29ncy1zdmMtZGVmYXVsdC5hcHBz LnJqdW5nLWh1YjEzLmRldjA2LnJlZC1jaGVzdGVyZmllbGQuY29tMR8wHQYJKoZI hvcNAQkBFhByb2tlakByZWRoYXQuY29tMB4XDTIwMTIwMzE4NTMxMloXDTIzMDky MzE4NTMxMlowgbMxCzAJBgNVBAYTAkNBMQswCQYDVQQIDAJPTjEQMA4GA1UEBwwH VG9yb250bzEPMA0GA1UECgwGUmVkSGF0MQwwCgYDVQQLDANBQ00xRTBDBgNVBAMM PGdvZ3Mtc3ZjLWRlZmF1bHQuYXBwcy5yanVuZy1odWIxMy5kZXYwNi5yZWQtY2hl c3RlcmZpZWxkLmNvbTEfMB0GCSqGSIb3DQEJARYQcm9rZWpAcmVkaGF0LmNvbTCC AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAM3nPK4mOQzaDAo6S3ZJ0Ic3 U9p/NLodnoTIC+cn0q8qNCAjf13zbGB3bfN9Zxl8Q5fv+wYwHrUOReCp6U/InyQy 6OS3gj738F635inz1KdyhKtlWW2p9Ye9DUtx1IlfHkDVdXtynjHQbsFNIdRHcpQP upM5pwPC3BZXqvXChhlfAy2m4yu7vy0hO/oTzWIwNsoL5xt0Lw4mSyhlEip/t8lU xn2y8qhm7MiIUpXuwWhSYgCrEVqmTcB70Pc2YRZdSFolMN9Et70MjQN0TXjoktH8 PyASJIKIRd+48yROIbUn8rj4aYYBsJuoSCjJNwujZPbqseqUr42+v+Qp2bBj1Sjw +SEZfHTvSv8AqX0T6eo6njr578+DgYlwsS1A1zcAdzp8qmDGqvJDzwcnQVFmvaoM gGHCdJihfy3vDhxuZRDse0V4Pz6tl6iklM+tHrJL/bdL0NdfJXNCqn2nKrM51fpw diNXs4Zn3QSStC2x2hKnK+Q1rwCSEg/lBawgxGUslTboFH77a+Kwu4Oug9ibtm5z ISs/JY4Kiy4C2XJOltOR2XZYkdKaX4x3ctbrGaD8Bj+QHiSAxaaSXIX+VbzkHF2N aD5ijFUopjQEKFrYh3O93DB/URIQ+wHVa6+Kvu3uqE0cg6pQsLpbFVQ/I8xHvt9L kYy6z6V/nj9ZYKQbq/kPAgMBAAEwDQYJKoZIhvcNAQELBQADggIBAKZuc+lewYAv jaaSeRDRoToTb/yN0Xsi69UfK0aBdvhCa7/0rPHcv8hmUBH3YgkZ+CSA5ygajtL4 g2E8CwIO9ZjZ6l+pHCuqmNYoX1wdjaaDXlpwk8hGTSgy1LsOoYrC5ZysCi9Jilu9 PQVGs/vehQRqLV9uZBigG6oZqdUqEimaLHrOcEAHB5RVcnFurz0qNbT+UySjsD63 9yJdCeQbeKAR9SC4hG13EbM/RZh0lgFupkmGts7QYULzT+oA0cCJpPLQl6m6qGyE kh9aBB7FLykK1TeXVuANlNU4EMyJ/e+uhNkS9ubNJ3vuRuo+ECHsha058yi16JC9 NkZqP+df4Hp85sd+xhrgYieq7QGX2KOXAjqAWo9htoBhOyW3mm783A7WcOiBMQv0 2UGZxMsRjlP6UqB08LsV5ZBAefElR344sokJR1de/Sx2J9J/am7yOoqbtKpQotIA XSUkATuuQw4ctyZLDkUpzrDzgd2Bt+aawF6sD2YqycaGFwv2YD9t1YlD6F4Wh8Mc 20Qu5EGrkQTCWZ9pOHNSa7YQdmJzwbxJC4hqBpBRAJFI2fAIqFtyum6/8ZN9nZ9K FSEKdlu+xeb6Y6xYt0mJJWF6mCRi4i7IL74EU/VNXwFmfP6IadliUOST3w5t92cB M26t73UCExXMXTCQvnp0ki84PeR1kRk4 -----END CERTIFICATE----- # Git server intermediate CA 1 -----BEGIN CERTIFICATE----- MIIF5DCCA8wCCQDInYMol7LSDTANBgkqhkiG9w0BAQsFADCBszELMAkGA1UEBhMC Q0ExCzAJBgNVBAgMAk9OMRAwDgYDVQQHDAdUb3JvbnRvMQ8wDQYDVQQKDAZSZWRI YXQxDDAKBgNVBAsMA0FDTTFFMEMGA1UEAww8Z29ncy1zdmMtZGVmYXVsdC5hcHBz LnJqdW5nLWh1YjEzLmRldjA2LnJlZC1jaGVzdGVyZmllbGQuY29tMR8wHQYJKoZI hvcNAQkBFhByb2tlakByZWRoYXQuY29tMB4XDTIwMTIwMzE4NTMxMloXDTIzMDky MzE4NTMxMlowgbMxCzAJBgNVBAYTAkNBMQswCQYDVQQIDAJPTjEQMA4GA1UEBwwH VG9yb250bzEPMA0GA1UECgwGUmVkSGF0MQwwCgYDVQQLDANBQ00xRTBDBgNVBAMM PGdvZ3Mtc3ZjLWRlZmF1bHQuYXBwcy5yanVuZy1odWIxMy5kZXYwNi5yZWQtY2hl c3RlcmZpZWxkLmNvbTEfMB0GCSqGSIb3DQEJARYQcm9rZWpAcmVkaGF0LmNvbTCC AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAM3nPK4mOQzaDAo6S3ZJ0Ic3 U9p/NLodnoTIC+cn0q8qNCAjf13zbGB3bfN9Zxl8Q5fv+wYwHrUOReCp6U/InyQy 6OS3gj738F635inz1KdyhKtlWW2p9Ye9DUtx1IlfHkDVdXtynjHQbsFNIdRHcpQP upM5pwPC3BZXqvXChhlfAy2m4yu7vy0hO/oTzWIwNsoL5xt0Lw4mSyhlEip/t8lU xn2y8qhm7MiIUpXuwWhSYgCrEVqmTcB70Pc2YRZdSFolMN9Et70MjQN0TXjoktH8 PyASJIKIRd+48yROIbUn8rj4aYYBsJuoSCjJNwujZPbqseqUr42+v+Qp2bBj1Sjw +SEZfHTvSv8AqX0T6eo6njr578+DgYlwsS1A1zcAdzp8qmDGqvJDzwcnQVFmvaoM gGHCdJihfy3vDhxuZRDse0V4Pz6tl6iklM+tHrJL/bdL0NdfJXNCqn2nKrM51fpw diNXs4Zn3QSStC2x2hKnK+Q1rwCSEg/lBawgxGUslTboFH77a+Kwu4Oug9ibtm5z ISs/JY4Kiy4C2XJOltOR2XZYkdKaX4x3ctbrGaD8Bj+QHiSAxaaSXIX+VbzkHF2N aD5ijFUopjQEKFrYh3O93DB/URIQ+wHVa6+Kvu3uqE0cg6pQsLpbFVQ/I8xHvt9L kYy6z6V/nj9ZYKQbq/kPAgMBAAEwDQYJKoZIhvcNAQELBQADggIBAKZuc+lewYAv jaaSeRDRoToTb/yN0Xsi69UfK0aBdvhCa7/0rPHcv8hmUBH3YgkZ+CSA5ygajtL4 g2E8CwIO9ZjZ6l+pHCuqmNYoX1wdjaaDXlpwk8hGTSgy1LsOoYrC5ZysCi9Jilu9 PQVGs/vehQRqLV9uZBigG6oZqdUqEimaLHrOcEAHB5RVcnFurz0qNbT+UySjsD63 9yJdCeQbeKAR9SC4hG13EbM/RZh0lgFupkmGts7QYULzT+oA0cCJpPLQl6m6qGyE kh9aBB7FLykK1TeXVuANlNU4EMyJ/e+uhNkS9ubNJ3vuRuo+ECHsha058yi16JC9 NkZqP+df4Hp85sd+xhrgYieq7QGX2KOXAjqAWo9htoBhOyW3mm783A7WcOiBMQv0 2UGZxMsRjlP6UqB08LsV5ZBAefElR344sokJR1de/Sx2J9J/am7yOoqbtKpQotIA XSUkATuuQw4ctyZLDkUpzrDzgd2Bt+aawF6sD2YqycaGFwv2YD9t1YlD6F4Wh8Mc 20Qu5EGrkQTCWZ9pOHNSa7YQdmJzwbxJC4hqBpBRAJFI2fAIqFtyum6/8ZN9nZ9K FSEKdlu+xeb6Y6xYt0mJJWF6mCRi4i7IL74EU/VNXwFmfP6IadliUOST3w5t92cB M26t73UCExXMXTCQvnp0ki84PeR1kRk4 -----END CERTIFICATE----- # Git server intermediate CA 2 -----BEGIN CERTIFICATE----- MIIF5DCCA8wCCQDInYMol7LSDTANBgkqhkiG9w0BAQsFADCBszELMAkGA1UEBhMC Q0ExCzAJBgNVBAgMAk9OMRAwDgYDVQQHDAdUb3JvbnRvMQ8wDQYDVQQKDAZSZWRI YXQxDDAKBgNVBAsMA0FDTTFFMEMGA1UEAww8Z29ncy1zdmMtZGVmYXVsdC5hcHBz LnJqdW5nLWh1YjEzLmRldjA2LnJlZC1jaGVzdGVyZmllbGQuY29tMR8wHQYJKoZI hvcNAQkBFhByb2tlakByZWRoYXQuY29tMB4XDTIwMTIwMzE4NTMxMloXDTIzMDky MzE4NTMxMlowgbMxCzAJBgNVBAYTAkNBMQswCQYDVQQIDAJPTjEQMA4GA1UEBwwH VG9yb250bzEPMA0GA1UECgwGUmVkSGF0MQwwCgYDVQQLDANBQ00xRTBDBgNVBAMM PGdvZ3Mtc3ZjLWRlZmF1bHQuYXBwcy5yanVuZy1odWIxMy5kZXYwNi5yZWQtY2hl c3RlcmZpZWxkLmNvbTEfMB0GCSqGSIb3DQEJARYQcm9rZWpAcmVkaGF0LmNvbTCC AiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAM3nPK4mOQzaDAo6S3ZJ0Ic3 U9p/NLodnoTIC+cn0q8qNCAjf13zbGB3bfN9Zxl8Q5fv+wYwHrUOReCp6U/InyQy 6OS3gj738F635inz1KdyhKtlWW2p9Ye9DUtx1IlfHkDVdXtynjHQbsFNIdRHcpQP upM5pwPC3BZXqvXChhlfAy2m4yu7vy0hO/oTzWIwNsoL5xt0Lw4mSyhlEip/t8lU xn2y8qhm7MiIUpXuwWhSYgCrEVqmTcB70Pc2YRZdSFolMN9Et70MjQN0TXjoktH8 PyASJIKIRd+48yROIbUn8rj4aYYBsJuoSCjJNwujZPbqseqUr42+v+Qp2bBj1Sjw +SEZfHTvSv8AqX0T6eo6njr578+DgYlwsS1A1zcAdzp8qmDGqvJDzwcnQVFmvaoM gGHCdJihfy3vDhxuZRDse0V4Pz6tl6iklM+tHrJL/bdL0NdfJXNCqn2nKrM51fpw diNXs4Zn3QSStC2x2hKnK+Q1rwCSEg/lBawgxGUslTboFH77a+Kwu4Oug9ibtm5z ISs/JY4Kiy4C2XJOltOR2XZYkdKaX4x3ctbrGaD8Bj+QHiSAxaaSXIX+VbzkHF2N aD5ijFUopjQEKFrYh3O93DB/URIQ+wHVa6+Kvu3uqE0cg6pQsLpbFVQ/I8xHvt9L kYy6z6V/nj9ZYKQbq/kPAgMBAAEwDQYJKoZIhvcNAQELBQADggIBAKZuc+lewYAv jaaSeRDRoToTb/yN0Xsi69UfK0aBdvhCa7/0rPHcv8hmUBH3YgkZ+CSA5ygajtL4 g2E8CwIO9ZjZ6l+pHCuqmNYoX1wdjaaDXlpwk8hGTSgy1LsOoYrC5ZysCi9Jilu9 PQVGs/vehQRqLV9uZBigG6oZqdUqEimaLHrOcEAHB5RVcnFurz0qNbT+UySjsD63 9yJdCeQbeKAR9SC4hG13EbM/RZh0lgFupkmGts7QYULzT+oA0cCJpPLQl6m6qGyE kh9aBB7FLykK1TeXVuANlNU4EMyJ/e+uhNkS9ubNJ3vuRuo+ECHsha058yi16JC9 NkZqP+df4Hp85sd+xhrgYieq7QGX2KOXAjqAWo9htoBhOyW3mm783A7WcOiBMQv0 2UGZxMsRjlP6UqB08LsV5ZBAefElR344sokJR1de/Sx2J9J/am7yOoqbtKpQotIA XSUkATuuQw4ctyZLDkUpzrDzgd2Bt+aawF6sD2YqycaGFwv2YD9t1YlD6F4Wh8Mc 20Qu5EGrkQTCWZ9pOHNSa7YQdmJzwbxJC4hqBpBRAJFI2fAIqFtyum6/8ZN9nZ9K FSEKdlu+xeb6Y6xYt0mJJWF6mCRi4i7IL74EU/VNXwFmfP6IadliUOST3w5t92cB M26t73UCExXMXTCQvnp0ki84PeR1kRk4 -----END CERTIFICATE-----
이 ConfigMap을 사용하여 채널을 구성합니다. 이전 단계의
git-ca
이름으로 다음 샘플을 참조하십시오.apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: my-channel namespace: channel-ns spec: configMapRef: name: git-ca pathname: <Git HTTPS URL> type: Git
1.6.6.4. Git 서버에 SSH 연결
데이터
의sshKey
필드에 개인 SSH 키를 포함할 시크릿을 생성합니다. 키가 암호로 보호되는 경우 password 필드에암호를
지정합니다. 이 시크릿은 channel CR과 동일한 네임스페이스에 있어야 합니다.oc
명령을 사용하여 시크릿 일반git-ssh-key --from-file=sshKey=./.ssh/id_rsa
를 생성한 다음 base64로 인코딩된암호를
추가합니다. 다음 샘플을 참조하십시오.apiVersion: v1 kind: Secret metadata: name: git-ssh-key namespace: channel-ns data: sshKey: LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQ21GbGN6STFOaTFqZEhJQUFBQUdZbU55ZVhCMEFBQUFHQUFBQUJDK3YySHhWSIwCm8zejh1endzV3NWODMvSFVkOEtGeVBmWk5OeE5TQUgcFA3Yk1yR2tlRFFPd3J6MGIKOUlRM0tKVXQzWEE0Zmd6NVlrVFVhcTJsZWxxVk1HcXI2WHF2UVJ5Mkc0NkRlRVlYUGpabVZMcGVuaGtRYU5HYmpaMmZOdQpWUGpiOVhZRmd4bTNnYUpJU3BNeTFLWjQ5MzJvOFByaDZEdzRYVUF1a28wZGdBaDdndVpPaE53b0pVYnNmYlZRc0xMS1RrCnQwblZ1anRvd2NEVGx4TlpIUjcwbGVUSHdGQTYwekM0elpMNkRPc3RMYjV2LzZhMjFHRlMwVmVXQ3YvMlpMOE1sbjVUZWwKSytoUWtxRnJBL3BUc1ozVXNjSG1GUi9PV25FPQotLS0tLUVORCBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0K passphrase: cGFzc3cwcmQK type: Opaque
시크릿을 사용하여 채널을 구성합니다. 다음 샘플을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: my-channel namespace: channel-ns spec: secretRef: name: git-ssh-key pathname: <Git SSH URL> type: Git
서브스크립션 컨트롤러는 제공된 Git 호스트 이름으로
ssh-keyscan
을 수행하여 SSH 연결에서 MITM(Man-in-the-middle) 공격을 방지하기 위해known_hosts
목록을 빌드합니다. 이 단계를 건너뛰고 비보안 연결을 만들려면 채널 구성에서insecureSkipVerify: true
를 사용합니다. 특히 프로덕션 환경에서는 이 방법이 좋지 않습니다.apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: my-channel namespace: channel-ns spec: secretRef: name: git-ssh-key pathname: <Git SSH URL> type: Git insecureSkipVerify: true
1.6.6.5. 인증서 및 SSH 키 업데이트
Git 채널 연결 구성에 CA 인증서, 인증 정보 또는 SSH 키와 같은 업데이트가 필요한 경우 동일한 네임스페이스에 새 시크릿 및 ConfigMap을 생성하고 해당 새 시크릿 및 ConfigMap을 참조하도록 채널을 업데이트해야 합니다. 자세한 내용은 보안 HTTPS 연결에 사용자 정의 CA 인증서 사용을 참조하십시오.
1.6.7. 네임스페이스 리소스를 조사하도록 Helm 구성
기본적으로 서브스크립션이 서브스크립션된 Helm 리소스를 대상 클러스터에 배포하면 애플리케이션 리소스가 감시됩니다. 네임스페이스 범위 리소스를 조사하도록 Helm 채널 유형을 구성할 수 있습니다. 활성화하면 조사 중인 네임스페이스 범위 리소스에 대한 수동 변경 사항이 되돌아갑니다.
1.6.7.1. 구성
필수 액세스: 클러스터 관리자
네임스페이스 범위 리소스를 조사하도록 Helm 애플리케이션을 구성하려면 서브스크립션 정의의 watchHelmNamespaceScopedResources
필드 값을 true
로 설정합니다. 다음 샘플을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 spec: watchHelmNamespaceScopedResources: true channel: ns-ch/predev-ch name: nginx-ingress packageFilter: version: "1.36.x"
1.6.8. 배포 예약
특정 시간 동안 새로운 또는 Helm 차트 또는 기타 리소스를 배포해야 하는 경우 해당 리소스에 대한 서브스크립션을 정의하여 해당 특정 시간 동안만 배포를 시작할 수 있습니다. 또는 배포를 제한할 수 있습니다.
예를 들어 매주 금요일 오후 1시부터 오후 11시 사이에 시간 창을 정의하여 패치 또는 기타 애플리케이션 업데이트를 클러스터에 적용하기 위한 스케줄링된 유지 관리 창 역할을 할 수 있습니다.
최대 업무 시간 동안 예기치 않은 배포를 방지하기 위해 특정 기간 동안 배포를 처음부터 제한하거나 차단할 수 있습니다. 예를 들어 최대 시간을 피하려면 오전 8시부터 오후 8시부터 오후 8시 사이의 배포를 피하기 위해 서브스크립션의 시간 창을 정의할 수 있습니다.
서브스크립션에 대한 시간 창을 정의하여 모든 애플리케이션 및 클러스터에 대한 업데이트를 조정할 수 있습니다. 예를 들어 오후 6:01 PM과 11:59 PM 사이에 새 애플리케이션 리소스만 배포하도록 서브스크립션을 정의하고 다른 서브스크립션을 정의하여 오전 12시~59시 사이에 업데이트된 버전의 기존 리소스만 배포할 수 있습니다.
서브스크립션에 대한 시간 창이 정의되면 서브스크립션이 활성으로 변경될 때의 시간 범위입니다. 시간 창 정의의 일부로 해당 기간 동안 활성화 또는 차단 할 서브스크립션을 정의할 수 있습니다.
새 리소스 또는 변경된 리소스의 배포는 서브스크립션이 활성화된 경우에만 시작됩니다. 서브스크립션이 활성 상태인지 또는 차단되었는지 여부에 관계없이 서브스크립션은 새 리소스 또는 변경된 리소스를 계속 모니터링합니다. 활성 및 차단된 설정은 배포에만 영향을 미칩니다.
새 리소스 또는 변경된 리소스가 감지되면 시간 창 정의에 따라 서브스크립션의 다음 작업이 결정됩니다.
-
HelmRepo
,ObjectBucket
및Git
유형 채널에 대한 서브스크립션의 경우: - 서브스크립션이 활성 상태일 때 시간 범위 중에 리소스가 감지되면 리소스 배포가 시작됩니다.
- 서브스크립션이 실행 중인 배포에서 차단될 때 시간 범위 외부에서 리소스가 감지되면 리소스 배포 요청이 캐시됩니다. 다음에 서브스크립션 범위가 활성화되면 캐시된 요청이 적용되고 관련 배포가 시작됩니다.
- 시간 창이 차단 되면 애플리케이션 서브스크립션을 통해 이전에 배포한 모든 리소스가 그대로 유지됩니다. 새 업데이트는 시간 창이 다시 활성화될 때까지 차단됩니다.
최종 사용자는 앱 하위 시간 창이 차단되면 배포된 모든 리소스가 제거된다고 잘못 생각할 수 있습니다. 그리고 앱 하위 시간 창이 다시 활성 상태일 때 돌아올 것입니다.
정의된 시간 기간 동안 배포가 시작되고 시간이 지남에 따라 정의된 기간이 지나면 배포가 완료될 때까지 계속 실행됩니다.
서브스크립션의 시간 창을 정의하려면 필수 필드 및 값을 서브스크립션 리소스 정의 YAML에 추가해야 합니다.
- 시간 창을 정의하는 과정의 일부로 시간 창에 대한 요일과 시간을 정의할 수 있습니다.
- 정의된 시간 프레임 중 배포가 발생할 수 있는지 여부를 결정하는 시간 창 유형을 정의할 수도 있습니다.
-
시간 창 유형이
활성
상태이면 정의된 기간 동안만 배포를 시작할 수 있습니다. 특정 유지 관리 기간 내에서만 배포를 수행하려는 경우 이 설정을 사용할 수 있습니다. -
시간 창 유형이
블록
인 경우 정의된 기간 동안 배포를 시작할 수 없지만 언제든지 시작할 수 있습니다. 필수 중요 업데이트가 있지만 특정 기간 동안 배포를 피해야 하는 경우에도 이 설정을 사용할 수 있습니다. 예를 들어 이 유형을 사용하여 오후 1시~오후 2시를 제외한 언제든지 보안 관련 업데이트를 적용할 수 있도록 시간 창을 정의할 수 있습니다. - 매주 월요일과 수요일마다 시간 창을 정의하는 등 서브스크립션에 대해 여러 시간 창을 정의할 수 있습니다.
1.6.9. 패키지 덮어쓰기 구성
서브스크립션에서 서브스크립션하는 Helm 차트 또는 Kubernetes 리소스의 서브스크립션 덮어쓰기 값에 대한 패키지 덮어쓰기를 구성합니다.
패키지 덮어쓰기를 구성하려면 경로
필드 값으로 재정의할 Kubernetes 리소스 사양
내에 필드를 지정합니다. 대체 값을 value 필드의 값으로
지정합니다.
예를 들어 서브스크립션된 Helm 차트에 대한 Helm 릴리스의 spec
내의 values 필드를 재정의해야 하는 경우 서브스크립션 정의의 path
필드 값을 spec
로 설정해야 합니다.
packageOverrides:
- packageName: nginx-ingress
packageOverrides:
- path: spec
value: my-override-values 1
- 1
value
필드의 내용은Helm
사양의spec
필드 내의 값을 덮어쓰는 데 사용됩니다.-
Helm 릴리스의 경우
spec
필드의 덮어쓰기 값이 Helm 릴리스values.yaml
파일에 병합되어 기존 값을 덮어씁니다. 이 파일은 Helm 릴리스에 대한 구성 가능한 변수를 검색하는 데 사용됩니다. Helm 릴리스의 릴리스 이름을 재정의해야 하는 경우 정의 내에
packageOverride
섹션을 포함합니다. 다음 필드를 포함하여 Helm 릴리스에 대한packageAlias
를 정의합니다.-
Helm
차트
를 식별하는 PACKAGENAME. -
packageAlias
: 릴리스 이름을 재정의하고 있음을 나타냅니다.
기본적으로 Helm 릴리스 이름이 지정되지 않은 경우 Helm 차트 이름이 릴리스를 식별하는 데 사용됩니다. 동일한 차트에 서브스크립션된 릴리스가 여러 개 있는 경우와 같이 충돌이 발생할 수 있습니다. 릴리스 이름은 네임스페이스 내의 서브스크립션 간에 고유해야 합니다. 생성하는 서브스크립션의 릴리스 이름이 고유하지 않은 경우 오류가 발생합니다.
packageOverride
를 정의하여 서브스크립션의 다른 릴리스 이름을 설정해야 합니다. 기존 서브스크립션 내에서 이름을 변경하려면 먼저 해당 서브스크립션을 삭제한 다음 기본 릴리스 이름으로 서브스크립션을 다시 생성해야 합니다.-
Helm
packageOverrides: - packageName: nginx-ingress packageAlias: my-helm-release-name
-
Helm 릴리스의 경우
1.6.10. 채널 샘플 개요
파일을 빌드하는 데 사용할 수 있는 샘플 및 YAML 정의를 확인합니다. 채널(channel.apps.open-cluster-management.io
)은 Kubernetes 애플리케이션용 Red Hat Advanced Cluster Management를 생성 및 관리하기 위한 지속적인 통합 및 지속적인 제공 기능을 제공합니다.
OpenShift CLI 툴을 사용하려면 다음 절차를 참조하십시오.
- 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
다음 명령을 실행하여 파일을 API 서버에 적용합니다.
파일
이름을 파일 이름으로 바꿉니다.oc apply -f filename.yaml
다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.
oc get application.app
1.6.10.1. 채널 YAML 구조
배포할 수 있는 애플리케이션 샘플은 stolostron
리포지토리를 참조하십시오.
다음 YAML 구조는 채널의 필수 필드와 일반적인 일부 선택적 필드를 보여줍니다. YAML 구조에 몇 가지 필수 필드와 값을 포함해야 합니다. 애플리케이션 관리 요구 사항에 따라 다른 선택적 필드 및 값을 포함해야 할 수 있습니다. 모든 툴과 제품 콘솔을 사용하여 자체 YAML 콘텐츠를 작성할 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: namespace: # Each channel needs a unique namespace, except Git channel. spec: sourceNamespaces: type: pathname: secretRef: name: gates: annotations: labels:
1.6.10.2. 채널 YAML 테이블
필드 | 선택 사항 또는 필수 | 설명 |
---|---|---|
apiVersion | 필수 항목 |
값을 |
kind | 필수 항목 |
값을 |
metadata.name | 필수 항목 | 채널의 이름입니다. |
metadata.namespace | 필수 항목 | 채널의 네임스페이스입니다. 각 채널에는 Git 채널을 제외한 고유한 네임스페이스가 필요합니다. |
spec.sourceNamespaces | 선택 사항 | 채널 컨트롤러에서 채널을 검색하고 승격하기 위해 신규 또는 업데이트된 배포가 필요한 네임스페이스를 식별합니다. |
spec.type | 필수 항목 |
채널 유형입니다. 지원되는 유형은 |
spec.pathname |
|
|
spec.secretRef.name | 선택 사항 |
리포지토리에 액세스하거나 차트에 액세스하는 경우와 같이 인증에 사용할 Kubernetes Secret 리소스를 식별합니다. |
spec.gates | 선택 사항 |
채널 내에서 배포 가능을 승격하기 위한 요구 사항을 정의합니다. 요구 사항이 설정되지 않은 경우 채널 네임스페이스 또는 소스에 추가되는 배포 가능한 모든 배포가 채널로 확장됩니다. |
spec.gates.annotations | 선택 사항 | 채널의 주석입니다. 배포 가능 항목에는 채널에 포함할 일치하는 주석이 있어야 합니다. |
metadata.labels | 선택 사항 | 채널의 레이블입니다. |
spec.insecureSkipVerify | 선택 사항 |
기본값은 |
채널의 정의 구조는 다음 YAML 콘텐츠와 유사할 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: predev-ch namespace: ns-ch labels: app: nginx-app-details spec: type: HelmRepo pathname: https://kubernetes-charts.storage.googleapis.com/
1.6.10.3. 오브젝트 스토리지 버킷(ObjectBucket) 채널
다음 예제 채널 정의는 오브젝트 스토리지 버킷을 채널로 추상화합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: dev namespace: ch-obj spec: type: ObjectBucket pathname: [http://9.28.236.243:xxxx/dev] # URL is appended with the valid bucket name, which matches the channel name. secretRef: name: miniosecret gates: annotations: dev-ready: true
1.6.10.4. Helm 리포지터리 (HelmRepo
) 채널
다음 예제 채널 정의는 Helm 리포지터리를 채널로 추상화합니다.
사용 중단 알림: 2.10의 경우 Helm 리포지터리 SSL 인증서를 건너뛰도록 채널 ConfigMap
참조에 insecureSkipVerify: "true"
를 지정하는 것은 더 이상 사용되지 않습니다. 다음 샘플의 교체를 참조하십시오. 대신 채널에서 사용되는 spec.insecureSkipVerify: true
를 사용합니다.
apiVersion: v1 kind: Namespace metadata: name: hub-repo --- apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: Helm namespace: hub-repo spec: pathname: [https://9.21.107.150:8443/helm-repo/charts] # URL points to a valid chart URL. insecureSkipVerify: true type: HelmRepo
다음 채널 정의에서는 Helm 리포지터리 채널의 또 다른 예를 보여줍니다.
참고: Helm 차트에 포함된 모든 Kubernetes 리소스에 애플리케이션 토폴로지가 올바르게 표시하려면 레이블 릴리스 {{ .Release.Name }}
이 있어야 합니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: predev-ch namespace: ns-ch labels: app: nginx-app-details spec: type: HelmRepo pathname: https://kubernetes-charts.storage.googleapis.com/
1.6.10.5. Git (Git
) 리포지토리 채널
다음 예제 채널 정의에는 Git 리포지토리의 채널 예가 표시됩니다. 다음 예에서 secretRef
는 경로 이름에
지정된 Git 리포지토리에 액세스하는 데 사용되는 사용자 ID를 나타냅니다. 공용 리포지토리가 있는 경우 secretRef
레이블 및 값이 필요하지 않습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: hive-cluster-gitrepo namespace: gitops-cluster-lifecycle spec: type: Git pathname: https://github.com/open-cluster-management/gitops-clusters.git secretRef: name: github-gitops-clusters --- apiVersion: v1 kind: Secret metadata: name: github-gitops-clusters namespace: gitops-cluster-lifecycle data: user: dXNlcgo= # Value of user and accessToken is Base 64 coded. accessToken: cGFzc3dvcmQ
1.6.11. 서브스크립션 샘플 개요
파일을 빌드하는 데 사용할 수 있는 샘플 및 YAML 정의를 확인합니다. 채널과 마찬가지로 서브스크립션(subscription.apps.open-cluster-management.io
)은 애플리케이션 관리를 위한 지속적인 통합 및 지속적인 제공 기능을 제공합니다.
OpenShift CLI 툴을 사용하려면 다음 절차를 참조하십시오.
- 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
다음 명령을 실행하여 파일을 api 서버에 적용합니다.
파일
이름을 파일 이름으로 바꿉니다.oc apply -f filename.yaml
다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.
oc get application.app
1.6.11.1. 서브스크립션 YAML 구조
다음 YAML 구조는 서브스크립션의 필수 필드와 몇 가지 공통 선택적 필드를 보여줍니다. YAML 구조에는 특정 필수 필드 및 값이 포함되어야 합니다.
애플리케이션 관리 요구 사항에 따라 다른 선택적 필드 및 값을 포함해야 할 수 있습니다. 모든 툴을 사용하여 자체 YAML 콘텐츠를 작성할 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: namespace: labels: spec: sourceNamespace: source: channel: name: packageFilter: version: labelSelector: matchLabels: package: component: annotations: packageOverrides: - packageName: packageAlias: - path: value: placement: local: clusters: name: clusterSelector: placementRef: name: kind: Placement overrides: clusterName: clusterOverrides: path: value:
1.6.11.2. 서브스크립션 YAML 테이블
필드 | 필수 또는 선택 사항 | 설명 |
---|---|---|
apiVersion | 필수 항목 |
값을 |
kind | 필수 항목 |
값을 |
metadata.name | 필수 항목 | 서브스크립션을 식별하는 이름입니다. |
metadata.namespace | 필수 항목 | 서브스크립션에 사용할 네임스페이스 리소스입니다. |
metadata.labels | 선택 사항 | 서브스크립션의 레이블입니다. |
spec.channel | 선택 사항 |
서브스크립션 채널을 정의하는 네임스페이스 이름("Namespace/Name")입니다. |
spec.sourceNamespace | 선택 사항 |
배포 대상이 hub 클러스터에 저장되는 소스 네임스페이스입니다. 네임스페이스 채널에만 이 필드를 사용합니다. |
spec.source | 선택 사항 |
배포 대상이 저장되는 Helm 리포지토리의 경로 이름("URL")입니다. Helm 리포지토리 채널에만 이 필드를 사용합니다. |
spec.name |
|
대상 Helm 차트 또는 채널 내에서 배포할 수 있는 특정 이름입니다. 필드가 선택 사항인 채널 유형에 대해 |
spec.packageFilter | 선택 사항 | 대상 배포 가능 항목을 찾는 데 사용할 매개 변수 또는 배포 가능 항목의 하위 집합을 정의합니다. 여러 필터 조건이 정의된 경우 배포 가능한 모든 필터 조건을 충족해야 합니다. |
spec.packageFilter.version | 선택 사항 |
배포 가능한 버전 또는 버전입니다. 다양한 버전을 > |
spec.packageFilter.annotations | 선택 사항 | 배포 가능한 주석입니다. |
spec.packageOverrides | 선택 사항 | 채널 내의 Helm 차트, 배포 가능 또는 기타 Kubernetes 리소스와 같이 서브스크립션에서 구독한 Kubernetes 리소스에 대한 덮어쓰기를 정의하는 섹션입니다. |
spec.packageOverrides.packageName | 선택 사항이지만 덮어쓰기 설정에 필요합니다. | 덮어쓰는 Kubernetes 리소스를 식별합니다. |
spec.packageOverrides.packageAlias | 선택 사항 | 덮어쓰는 Kubernetes 리소스에 별칭을 지정합니다. |
spec.packageOverrides.packageOverrides | 선택 사항 | Kubernetes 리소스를 재정의하는 데 사용할 매개변수 및 대체 값의 구성입니다. |
spec.placement | 필수 항목 | 배포 가능 항목을 배치해야 하는 서브스크립션 또는 클러스터를 정의하는 배치 규칙을 식별합니다. 배치 구성을 사용하여 다중 클러스터 배포 값을 정의합니다. |
spec.placement.local | 선택 사항이지만 직접 관리하려는 독립형 클러스터 또는 클러스터에 필요합니다. | 서브스크립션을 로컬로 배포해야 하는지 여부를 정의합니다.
서브스크립션이 지정된 채널과 동기화되도록 값을
서브스크립션이 지정된 채널의 리소스에 가입하지 못하도록 값을
클러스터가 독립형 클러스터이거나 이 클러스터를 직접 관리하는 경우 이 필드를 사용합니다. 클러스터가 다중 클러스터의 일부이고 클러스터를 직접 관리하지 않으려면 클러스터 , |
spec.placement.clusters | 선택 사항 |
서브스크립션을 배치할 클러스터를 정의합니다. 다중 |
spec.placement.clusters.name | 선택 사항이지만 클러스터를 정의하는 데 필요합니다. | 서브스크립션 클러스터의 이름 또는 이름입니다. |
spec.placement.clusterSelector | 선택 사항 |
서브스크립션을 배치할 클러스터를 식별하는 데 사용할 라벨 선택기를 정의합니다. , |
spec.placement.placementRef | 선택 사항 |
서브스크립션에 사용할 배치 규칙을 정의합니다. , |
spec.placement.placementRef.name | 배치 규칙을 사용하는 데 선택 사항이지만 필수 | 서브스크립션 배치 규칙의 이름입니다. |
spec.placement.placementRef.kind | 배치 규칙을 사용하는 데 선택 사항이지만 필요합니다. |
값을 |
spec.overrides | 선택 사항 | 클러스터별 설정과 같이 재정의해야 하는 매개변수와 값입니다. |
spec.overrides.clusterName | 선택 사항 | 매개변수 및 값을 재정의하는 클러스터 또는 클러스터의 이름입니다. |
spec.overrides.clusterOverrides | 선택 사항 | 재정의할 매개변수 및 값의 구성입니다. |
spec.timeWindow | 선택 사항 | 서브스크립션이 활성화되거나 차단될 때 시간 창을 구성하는 설정을 정의합니다. |
spec.timeWindow.type | 시간 창을 구성하는 데 선택 사항이지만 필수 | 구성된 시간 기간 동안 서브스크립션이 활성 상태인지 또는 차단되었는지 여부를 나타냅니다. 서브스크립션 배포는 서브스크립션이 활성화된 경우에만 수행됩니다. |
spec.timeWindow.location | 시간 창을 구성하는 데 선택 사항이지만 필수 | 시간 창에 대해 구성된 시간대의 시간대입니다. 모든 시간대는 Time Zone (tz) 데이터베이스 이름 형식을 사용해야 합니다. 자세한 내용은 시간대 데이터베이스 를 참조하십시오. |
spec.timeWindow.daysofweek | 시간 창을 구성하는 데 선택 사항이지만 필수 |
시간 범위를 적용하여 시간 창을 만들 때 요일을 나타냅니다. 일 목록은 |
spec.timeWindow.hours | 시간 창을 구성하는 데 선택 사항이지만 필수 | 시간 창에 대한 시간 범위를 정의합니다. 시간 범위의 시작 시간과 종료 시간은 각 시간 창에 대해 정의해야 합니다. 서브스크립션에 대해 여러 시간 창 범위를 정의할 수 있습니다. |
spec.timeWindow.hours.start | 시간 창을 구성하는 데 선택 사항이지만 필수 |
시간 창 시작을 정의하는 타임 스탬프입니다. 타임스탬프는 Go 프로그래밍 언어 Kitchen 형식 |
spec.timeWindow.hours.end | 시간 창을 구성하는 데 선택 사항이지만 필수 |
시간 창의 끝을 정의하는 타임 스탬프입니다. 타임스탬프는 Go 프로그래밍 언어 Kitchen 형식 |
참고:
-
YAML을 정의할 때 서브스크립션은
packageFilters
를 사용하여 여러 Helm 차트, 배포 가능 또는 기타 Kubernetes 리소스를 가리킬 수 있습니다. 그러나 서브스크립션은 최신 버전의 하나의 차트 또는 배포 가능한 리소스 또는 기타 리소스만 배포합니다. -
시간 창의 경우 창의 시간 범위를 정의하는 경우 종료 시간 전에 시작 시간을 설정해야 합니다. 구독에 대해 여러 시간 창을 정의하는 경우 창의 시간 범위가 겹치지 않습니다. 실제 시간 범위는 작업 중인 시간 및 위치와 다른 시간 및 위치로 설정할 수 있는
subscription-controller
컨테이너 시간을 기반으로 합니다. - 서브스크립션 사양 내에서 Helm 릴리스 배치를 서브스크립션 정의의 일부로 정의할 수도 있습니다. 각 서브스크립션은 기존 배치 규칙을 참조하거나 서브스크립션 정의 내에서 직접 배치 규칙을 정의할 수 있습니다.
-
spec.placement
섹션에 서브스크립션을 배치할 위치를 정의하는 경우 다중 클러스터 환경에 클러스터 ,clusterSelector
또는placementRef
중 하나만 사용합니다. 두 개 이상의 배치 설정을 포함하는 경우 하나의 설정이 사용되며 다른 설정은 무시됩니다. 다음 우선 순위는 서브스크립션 Operator에서 사용하는 설정을 결정하는 데 사용됩니다.
-
placementRef
-
클러스터
-
clusterSelector
-
서브스크립션은 다음 YAML 콘텐츠와 유사할 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch name: nginx-ingress packageFilter: version: "1.36.x" placement: placementRef: kind: Placement name: towhichcluster overrides: - clusterName: "/" clusterOverrides: - path: "metadata.namespace" value: default
1.6.11.3. 서브스크립션 파일 샘플
배포할 수 있는 애플리케이션 샘플은 stolostron
리포지토리를 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch name: nginx-ingress
1.6.11.4. 보조 채널 샘플
미러링된 채널(애플리케이션 소스 저장소)이 있는 경우 서브스크립션 YAML에 secondaryChannel
을 지정할 수 있습니다. 애플리케이션 서브스크립션이 기본 채널을 사용하여 리포지토리 서버에 연결하지 못하면 보조 채널을 사용하여 리포지토리 서버에 연결합니다. 보조 채널에 저장된 애플리케이션 매니페스트가 기본 채널과 동기화되었는지 확인합니다. secondaryChannel
을 사용하여 다음 샘플 서브스크립션 YAML을 참조하십시오.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch secondaryChannel: ns-ch-2/predev-ch-2 name: nginx-ingress
1.6.11.4.1. 서브스크립션 시간 창 예
다음 예제 서브스크립션에는 여러 구성된 시간 창이 포함됩니다. 시간 창은 월요일, 수요일, 금요일 오전 10시부터 오전 10시 30분 사이에 발생합니다. 또한 시간 창은 월요일, 수요일, 금요일마다 오후 12시 40분과 오후 1:40 사이에 발생합니다. 서브스크립션은 배포 기간 동안 6주 동안만 활성화됩니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch name: nginx-ingress packageFilter: version: "1.36.x" placement: placementRef: kind: Placement name: towhichcluster timewindow: windowtype: "active" location: "America/Los_Angeles" daysofweek: ["Monday", "Wednesday", "Friday"] hours: - start: "10:20AM" end: "10:30AM" - start: "12:40PM" end: "1:40PM"
timewindow
의 경우 유형의 목적에 따라 active
또는 blocked
를 입력합니다.
1.6.11.4.2. 덮어쓰기가 포함된 서브스크립션 예
다음 예제에는 Helm 차트에 대한 Helm 릴리스의 다른 릴리스 이름을 정의하는 패키지 덮어쓰기가 포함되어 있습니다. 패키지 덮어쓰기 설정은 이름 my-nginx-ingress-releaseName
을 nginx-ingress
Helm 릴리스의 다른 릴리스 이름으로 설정하는 데 사용됩니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: simple namespace: default spec: channel: ns-ch/predev-ch name: nginx-ingress packageOverrides: - packageName: nginx-ingress packageAlias: my-nginx-ingress-releaseName packageOverrides: - path: spec value: defaultBackend: replicaCount: 3 placement: local: false
1.6.11.4.3. Helm 리포지터리 서브스크립션 예
다음 서브스크립션은 버전 1.36.x
의 최신 nginx
Helm 릴리스를 자동으로 가져옵니다. 소스 Helm 리포지토리에서 새 버전을 사용할 수 있는 경우 Helm 릴리스 배포가 my- development-cluster-1
클러스터에 배치됩니다.
spec.packageOverrides
섹션에는 Helm 릴리스의 값을 재정의하는 데 필요한 선택적 매개변수가 표시됩니다. 덮어쓰기 값은 Helm 릴리스의 구성 가능한 변수를 검색하는 데 사용되는 Helm 릴리스 values.yaml
파일에 병합됩니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch name: nginx-ingress packageFilter: version: "1.36.x" placement: clusters: - name: my-development-cluster-1 packageOverrides: - packageName: my-server-integration-prod packageOverrides: - path: spec value: persistence: enabled: false useDynamicProvisioning: false license: accept tls: hostname: my-mcm-cluster.icp sso: registrationImage: pullSecret: hub-repo-docker-secret
1.6.11.4.4. Git 리포지토리 서브스크립션 예
1.6.11.4.4.1. Git 리포지토리의 특정 분기 및 디렉터리 구독
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: sample-subscription namespace: default annotations: apps.open-cluster-management.io/git-path: sample_app_1/dir1 apps.open-cluster-management.io/git-branch: branch1 spec: channel: default/sample-channel placement: placementRef: kind: Placement name: dev-clusters
이 예제 서브스크립션에서 주석 apps.open-cluster-management.io/git-path
는 서브스크립션이 채널에 지정된 Git 리포지토리의 sample_app_1/dir1
디렉터리 내의 모든 Helm 차트 및 Kubernetes 리소스에 가입함을 나타냅니다. 서브스크립션은 기본적으로 master
분기에 서브스크립션합니다. 이 예제 서브스크립션에서는 리포지토리의 branch1
분기를 서브스크립션하기 위해 apps.open-cluster-management.io/git-branch: branch1
주석이 지정됩니다.
참고: Helm 차트를 구독하는 Git 채널 서브스크립션을 사용하는 경우 리소스 토폴로지 보기에 추가 Helmrelease
리소스가 표시될 수 있습니다. 이 리소스는 내부 애플리케이션 관리 리소스이며 안전하게 무시할 수 있습니다.
1.6.11.4.4.2. .kubernetesignore
파일 추가
Git 리포지토리 루트 디렉터리에 .kubernetesignore
파일을 포함하거나 서브스크립션 주석에 지정된 apps.open-cluster-management.io/git-path
디렉터리에 포함할 수 있습니다.
이 .kubernetesignore
파일을 사용하여 파일이나 하위 디렉터리 또는 둘 다의 패턴을 지정하여 서브스크립션이 리포지토리에서 Kubernetes 리소스 또는 Helm 차트를 배포하는 경우를 무시할 수 있습니다.
세부 정보 필터링에 .kubernetesignore
파일을 사용하여 Kubernetes 리소스를 선택적으로 적용할 수도 있습니다. .kubernetesignore
파일의 패턴 형식은 .gitignore
파일과 동일합니다.
apps.open-cluster-management.io/git-path
주석이 정의되지 않은 경우 서브스크립션은 리포지토리 루트 디렉터리에서 .kubernetesignore
파일을 찾습니다. apps.open-cluster-management.io/git-path
필드가 정의된 경우 서브스크립션은 apps.open-cluster-management.io/git-path
디렉터리에서 .kubernetesignore
파일을 찾습니다. 서브스크립션은 다른 디렉터리에서 .kubernetesignore
파일을 검색하지 않습니다.
1.6.11.4.4.3. Kustomize 적용
서브스크립션 Git 폴더에 kustomization.yaml
또는 kustomization.yml
파일이 있는 경우 kustomize가 적용됩니다. spec.packageOverrides
를 사용하여 서브스크립션 배포 시 kustomization
을 덮어쓸 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: example-subscription namespace: default spec: channel: some/channel packageOverrides: - packageName: kustomization packageOverrides: - value: | patchesStrategicMerge: - patch.yaml
kustomization.yaml
파일을 재정의하려면 packageName: kustomization
이 packageOverrides
에 필요합니다. 덮어쓰기는 새 항목을 추가하거나 기존 항목을 업데이트합니다. 기존 항목은 제거되지 않습니다.
1.6.11.4.4.4. Git 웹 후크 활성화
기본적으로 Git 채널 서브스크립션은 1분마다 채널에 지정된 Git 리포지토리를 복제하고 커밋 ID가 변경되면 변경 사항을 적용합니다. 또는 Git 리포지토리에서 repo PUSH 및 PULL Webhook 이벤트 알림을 전송하는 경우에만 변경 사항을 적용하도록 서브스크립션을 구성할 수 있습니다.
Git 리포지토리에서 Webhook를 구성하려면 대상 Webhook 페이로드 URL과 필요한 경우 시크릿이 필요합니다.
1.6.11.4.4.4.1. 페이로드 URL
hub 클러스터에 경로(ingress)를 생성하여 서브스크립션 Operator의 웹 후크 이벤트 리스너 서비스를 노출합니다.
oc create route passthrough --service=multicluster-operators-subscription -n open-cluster-management
그런 다음 oc get route multicluster-operators-subscription -n open-cluster-management
명령을 사용하여 외부에서 연결할 수 있는 호스트 이름을 찾습니다.
Webhook 페이로드 URL은 https://<externally-reachable hostname>/webhook
입니다.
1.6.11.4.4.4.2. Webhook 시크릿
Webhook 시크릿은 선택 사항입니다. 채널 네임스페이스에 Kubernetes 시크릿을 생성합니다. 시크릿에는 data.secret
이 포함되어야 합니다.
다음 예제를 참조하십시오.
apiVersion: v1 kind: Secret metadata: name: my-github-webhook-secret data: secret: BASE64_ENCODED_SECRET
data.secret
의 값은 사용할 base-64로 인코딩된 WebHook 시크릿입니다.
모범 사례: 각 Git 리포지토리에 고유한 시크릿을 사용합니다.
1.6.11.4.4.4.3. Git 리포지토리에서 웹 후크 구성
페이로드 URL 및 Webhook 시크릿을 사용하여 Git 리포지토리에 WebHook를 구성합니다.
1.6.11.4.4.4.4. 채널에서 WebHook 이벤트 알림 활성화
서브스크립션 채널에 주석을 답니다. 다음 예제를 참조하십시오.
oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-enabled="true"
시크릿을 사용하여 WebHook를 구성한 경우 <the_secret_name>을 사용하여 채널에 주석을 답니다. 여기서 < the_secret_name
>은 Webhook 보안이 포함된 kubernetes 시크릿 이름입니다.
oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-secret="<the_secret_name>"
서브스크립션에는 Webhook 특정 구성이 필요하지 않습니다.
1.6.12. 배치 규칙 샘플 개요(더 이상 사용되지 않음)
더 이상 사용되지 않음: PlacementRules
는 더 이상 사용되지 않습니다. 대신 배치를
사용합니다.
배치 규칙(placementrule.apps.open-cluster-management.io
)은 배포 가능 항목을 배포할 수 있는 대상 클러스터를 정의합니다. 배치 규칙을 사용하여 배포 가능 항목의 다중 클러스터 배포를 원활하게 수행할 수 있습니다.
OpenShift CLI 툴을 사용하려면 다음 절차를 참조하십시오.
- 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
다음 명령을 실행하여 파일을 API 서버에 적용합니다.
파일
이름을 파일 이름으로 바꿉니다.oc apply -f filename.yaml
다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.
oc get application.app
1.6.12.1. 배치 규칙 YAML 구조
다음 YAML 구조는 배치 규칙의 필수 필드와 몇 가지 공통 선택적 필드를 보여줍니다. YAML 구조에 몇 가지 필수 필드와 값을 포함해야 합니다. 애플리케이션 관리 요구 사항에 따라 다른 선택적 필드 및 값을 포함해야 할 수 있습니다. 모든 툴과 제품 콘솔에서 고유한 YAML 콘텐츠를 작성할 수 있습니다.
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: namespace: resourceVersion: labels: app: chart: release: heritage: selfLink: uid: spec: clusterSelector: matchLabels: datacenter: environment: clusterReplicas: clusterConditions: ResourceHint: type: order: Policies:
1.6.12.2. 배치 규칙 YAML 값 표
필드 | 필수 또는 선택 사항 | 설명 |
---|---|---|
apiVersion | 필수 항목 |
값을 |
kind | 필수 항목 |
값을 |
metadata.name | 필수 항목 | 배치 규칙을 식별하는 이름입니다. |
metadata.namespace | 필수 항목 | 배치 규칙에 사용할 네임스페이스 리소스입니다. |
metadata.resourceVersion | 선택 사항 | 배치 규칙 리소스의 버전입니다. |
metadata.labels | 선택 사항 | 배치 규칙의 레이블입니다. |
spec.clusterSelector | 선택 사항 | 대상 클러스터를 식별하는 라벨 |
spec.clusterSelector.matchLabels | 선택 사항 | 대상 클러스터에 있어야 하는 라벨입니다. |
spec.clusterSelector.matchExpressions | 선택 사항 | 대상 클러스터에 있어야 하는 라벨입니다. |
status.decisions | 선택 사항 | 배포 대상이 배치되는 대상 클러스터를 정의합니다. |
status.decisions.clusterName | 선택 사항 | 대상 클러스터의 이름 |
status.decisions.clusterNamespace | 선택 사항 | 대상 클러스터의 네임스페이스입니다. |
spec.clusterReplicas | 선택 사항 | 생성할 복제본 수입니다. |
spec.clusterConditions | 선택 사항 | 클러스터의 조건을 정의합니다. |
spec.ResourceHint | 선택 사항 | 클러스터가 이전 필드에서 제공한 라벨 및 값과 일치하는 경우 리소스별 기준을 지정하여 클러스터를 선택할 수 있습니다. 예를 들어 사용 가능한 CPU 코어가 가장 많은 클러스터를 선택할 수 있습니다. |
spec.ResourceHint.type | 선택 사항 |
사용 가능한 메모리 리소스를 기반으로 클러스터를 선택하려면 사용 가능한 CPU 코어 또는 |
spec.ResourceHint.order | 선택 사항 |
이 값을 오름차순의 경우 |
spec.Policies | 선택 사항 | 배치 규칙에 대한 정책 필터입니다. |
1.6.12.3. 배치 규칙 샘플 파일
배포할 수 있는 애플리케이션 샘플은 stolostron
리포지토리를 참조하십시오.
기존 배치 규칙에는 배치 규칙의 상태를 나타내는 다음 필드가 포함될 수 있습니다. 이 status 섹션은 규칙에 대한 YAML 구조의 spec
섹션 뒤에 추가됩니다.
status: decisions: clusterName: clusterNamespace:
필드 | 설명 |
---|---|
status | 배치 규칙의 상태 정보입니다. |
status.decisions | 배포 대상이 배치되는 대상 클러스터를 정의합니다. |
status.decisions.clusterName | 대상 클러스터의 이름 |
status.decisions.clusterNamespace | 대상 클러스터의 네임스페이스입니다. |
- 예시 1
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: gbapp-gbapp namespace: development labels: app: gbapp spec: clusterSelector: matchLabels: environment: Dev clusterReplicas: 1 status: decisions: - clusterName: local-cluster clusterNamespace: local-cluster
- 예시 2
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: towhichcluster namespace: ns-sub-1 labels: app: nginx-app-details spec: clusterReplicas: 1 clusterConditions: - type: ManagedClusterConditionAvailable status: "True" clusterSelector: matchExpressions: - key: environment operator: In values: - dev
1.6.13. 애플리케이션 샘플
파일을 빌드하는 데 사용할 수 있는 샘플 및 YAML 정의를 확인합니다. Red Hat Advanced Cluster Management for Kubernetes의애플리케이션(application.app.k8s.io
)은 애플리케이션 구성 요소를 보는 데 사용됩니다.
OpenShift CLI 툴을 사용하려면 다음 절차를 참조하십시오.
- 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
다음 명령을 실행하여 파일을 API 서버에 적용합니다.
파일
이름을 파일 이름으로 바꿉니다.oc apply -f filename.yaml
다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.
oc get application.app
1.6.13.1. 애플리케이션 YAML 구조
애플리케이션 리소스를 생성하거나 업데이트하기 위해 애플리케이션 정의 YAML 콘텐츠를 구성하려면 YAML 구조에 몇 가지 필수 필드와 값이 포함되어야 합니다. 애플리케이션 요구 사항 또는 애플리케이션 관리 요구 사항에 따라 다른 선택적 필드 및 값을 포함해야 할 수 있습니다.
다음 YAML 구조는 애플리케이션의 필수 필드와 몇 가지 공통 선택적 필드를 보여줍니다.
apiVersion: app.k8s.io/v1beta1 kind: Application metadata: name: namespace: spec: selector: matchLabels: label_name: label_value
1.6.13.2. 애플리케이션 YAML 테이블
필드 | 현재의 | 설명 |
---|---|---|
apiVersion |
| 필수 항목 |
kind |
| 필수 항목 |
메타데이터 | ||
| 필수 항목 | |
| ||
spec | ||
selector.matchLabels |
이 애플리케이션이 연결될 서브스크립션 또는 서브스크립션에 있는 Kubernetes 레이블 및 값인 | 필수 항목 |
이러한 애플리케이션을 정의하는 사양은 Kubernetes Special interest Group(SIG)에서 제공하는 애플리케이션 메타데이터 설명자 사용자 정의 리소스 정의를 기반으로 합니다. 테이블에 표시된 값만 필요합니다.
이 정의를 사용하여 자체 애플리케이션 YAML 콘텐츠를 작성할 수 있습니다. 이 정의에 대한 자세한 내용은 Kubernetes SIG Application CRD 커뮤니티 사양을 참조하십시오.
1.6.13.3. 애플리케이션 파일 샘플
배포할 수 있는 애플리케이션 샘플은 stolostron
리포지토리를 참조하십시오.
애플리케이션의 정의 구조는 다음 예제 YAML 콘텐츠와 유사할 수 있습니다.
apiVersion: app.k8s.io/v1beta1 kind: Application metadata: name: my-application namespace: my-namespace spec: selector: matchLabels: my-label: my-label-value