검색

애플리케이션

download PDF
Red Hat Advanced Cluster Management for Kubernetes 2.11

애플리케이션 관리

초록

Git 리포지토리, Helm 리포지토리 및 오브젝트 스토리지 리포지토리를 사용하여 애플리케이션을 생성하는 방법을 알아보려면 자세한 내용을 참조하십시오.

1장. 애플리케이션 관리

다음 주제를 검토하여 애플리케이션 생성, 배포 및 관리에 대해 자세히 알아보십시오. 이 가이드에서는 Kubernetes 개념 및 용어에 대해 잘 알고 있다고 가정합니다. 주요 Kubernetes 용어 및 구성 요소는 정의되지 않습니다. Kubernetes 개념에 대한 자세한 내용은 Kubernetes 설명서를 참조하십시오.

애플리케이션 관리 기능을 사용하면 애플리케이션 및 애플리케이션 업데이트를 구성하고 배포하기 위한 통합적이고 단순화된 옵션을 사용할 수 있습니다. 이러한 기능을 통해 개발자와 DevOps 직원은 채널 및 서브스크립션 기반 자동화를 통해 환경 전반에서 애플리케이션을 생성하고 관리할 수 있습니다.

중요: 애플리케이션 이름은 37자를 초과할 수 없습니다.

다음 항목을 참조하십시오.

1.1. 애플리케이션 모델 및 정의

애플리케이션 모델은 관리 클러스터에 배포된 리소스가 포함된 하나 이상의 Kubernetes 리소스 리포지토리(채널 리소스)에 가입하는 것을 기반으로 합니다. 단일 클러스터 애플리케이션과 다중 클러스터 애플리케이션 모두 동일한 Kubernetes 사양을 사용하지만 다중 클러스터 애플리케이션은 배포 및 애플리케이션 관리 라이프사이클을 더욱 자동화해야 합니다.

애플리케이션 모델에 대한 자세한 내용은 다음 이미지를 참조하십시오.

Application model

다음 애플리케이션 리소스 섹션을 확인합니다.

모범 사례: 채널서브스크립션 모델 대신 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는 허브 클러스터 대신 새 리소스 또는 업데이트된 리소스에 대한 채널을 모니터링할 수 있습니다.

다음 서브스크립션 아키텍처 이미지를 참조하십시오.

Subscription model

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 리소스를 찾습니다.
  • 기본 개요 에서는 표의 애플리케이션 이름을 클릭하여 단일 애플리케이션 개요를 볼 때 다음 정보를 확인할 수 있습니다.
  • 리소스 상태와 같은 클러스터 세부 정보
  • 리소스 토폴로지
  • 서브스크립션 세부 정보
  • 편집할 편집기 탭에 액세스
  • 프로젝트의 모든 애플리케이션 및 리소스를 시각적으로 표시하려면 Topology 탭을 클릭합니다. Helm 서브스크립션의 경우 패키지 덮어쓰기 구성을 참조하여 적절한 packageNamepackageAlias 를 정의하여 정확한 토폴로지 표시를 가져옵니다.
  • 고급 구성 탭을 클릭하여 모든 애플리케이션에 대한 용어 및 리소스 테이블을 확인합니다. 리소스를 찾을 수 있으며 서브스크립션, 배치 및 채널을 필터링할 수 있습니다. 액세스 권한이 있는 경우 편집, 검색 및 삭제와 같은 여러 작업을 클릭할 수도 있습니다.
  • 배포된 애플리케이션에 대해 Ansible 작업을 prehook 또는 posthook로 사용하는 경우 Ansible Automation Platform 배포를 확인합니다.
  • 검색에서 리소스 시작을 클릭하여 관련 리소스를 검색합니다.
  • Search 를 사용하여 각 리소스의 구성 요소 종류로 애플리케이션 리소스를 찾습니다. 리소스를 검색하려면 다음 값을 사용합니다.

    애플리케이션 리소스kind(검색 매개변수)

    서브스크립션

    서브스크립션

    채널

    채널

    Secret

    Secret

    배치

    배치

    애플리케이션

    애플리케이션

name, namespace, cluster, label 등을 포함하여 다른 필드에서 검색할 수도 있습니다. 검색 사용에 대한 자세한 내용은 콘솔에서 검색을 참조하십시오.

1.3. 서브스크립션 보고서

서브스크립션 보고서는 플릿에 있는 모든 관리 클러스터의 애플리케이션 상태 컬렉션입니다. 특히 상위 애플리케이션 리소스는 확장 가능한 양의 관리 클러스터의 보고서를 저장할 수 있습니다.

허브 클러스터의 subscriptionReports 는 가볍고 확장 가능한 상태에서 관리 클러스터에서 자세한 애플리케이션 상태를 사용할 수 있습니다. 다음 세 가지 유형의 하위 상태 보고서를 참조하십시오.

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- appsub - namespace>에 있으며 다음 정보를 포함합니다.

  • 각 관리 클러스터의 애플리케이션 전체 상태
  • 애플리케이션의 모든 리소스 목록
  • 총 클러스터 수가 포함된 보고서 요약
  • 애플리케이션이 상태에 있는 총 클러스터 수( 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를 사용할 수 있습니다. 클러스터 수준 또는 애플리케이션 수준 구독 보고서는 전체 상태를 제공하지만 애플리케이션에 대한 자세한 오류 메시지는 제공하지 않습니다.

  1. multicloud-operators-subscription 에서 CLI를 다운로드합니다.
  2. 다음 명령을 실행하여 오류를 식별할 수 있도록 관리 클러스터 애플리케이션 SubscriptionStatus 를 보려면 managedClusterView 리소스를 생성합니다.
% getAppSubStatus.sh -c <your-managed-cluster> -s <your-appsub-namespace> -n <your-appsub-name>

1.3.6. CLI 마지막 업데이트 시간

또한 이 정보를 검색하기 위해 각 관리 클러스터에 로그인하는 것이 실용적이지 않은 경우 지정된 관리 클러스터에서 앱 서브의 마지막 업데이트 시간을 가져올 수도 있습니다. 따라서 관리 클러스터에서 AppSub의 마지막 업데이트 시간 검색을 간소화하기 위해 유틸리티 스크립트가 생성되었습니다. 이 스크립트는 Hub 클러스터에서 실행되도록 설계되었습니다. 관리 클러스터에서 AppSub를 가져오고 마지막 업데이트 시간을 가져오기 위해 데이터를 구문 분석하기 위해 managedClusterView 리소스를 생성합니다.

  1. multicloud-operators-subscription 에서 CLI를 다운로드합니다.
  2. 다음 명령을 실행하여 관리 클러스터에서 App Sub 의 마지막 업데이트 시간을 검색합니다. 이 스크립트는 hub 클러스터에서 실행되도록 설계되었습니다. 관리 클러스터에서 AppSub를 가져오고 마지막 업데이트 시간을 가져오기 위해 데이터를 구문 분석하기 위해 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 리포지토리에서 리소스를 배포하는 방법을 알아봅니다. 애플리케이션 모델 및 정의에서 애플리케이션 모델에 대해 자세히 알아보십시오.

사용자 필수 액세스: 애플리케이션을 생성할 수 있는 사용자 역할입니다. 역할이 할당된 작업만 수행할 수 있습니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.

  1. 콘솔 탐색 메뉴에서 애플리케이션을 클릭하여 나열된 애플리케이션을 확인하고 새 애플리케이션을 생성합니다.
  2. 선택 사항: 생성할 애플리케이션 종류를 선택한 후 YAML 을 선택하여 애플리케이션을 생성하고 편집할 때 콘솔에서 YAML을 볼 수 있습니다. 주제의 뒷부분에 있는 YAML 샘플을 참조하십시오.
  3. 사용할 수 있는 리포지토리 목록에서 Git 을 선택하고 올바른 필드에 값을 입력합니다. 콘솔의 지침에 따라 입력에 따라 YAML 편집기 변경 값을 확인합니다.

    참고:

    • 기존 Git 리포지토리 경로를 선택하는 경우 개인 리포지토리인 경우 연결 정보를 지정할 필요가 없습니다. 연결 정보는 미리 설정되어 있으므로 이러한 값을 볼 필요가 없습니다.
    • 새 Git 리포지토리 경로를 입력하면 개인 Git 리포지토리인 경우 Git 연결 정보를 선택적으로 입력할 수 있습니다.
    • 조정 옵션을 확인합니다. merge 옵션은 기본 선택이며, 이는 새 필드가 추가되고 리소스에서 기존 필드가 업데이트됨을 의미합니다. 교체 하도록 선택할 수 있습니다. replace 옵션을 사용하면 기존 리소스가 Git 소스로 교체됩니다. 서브스크립션 조정 비율이 낮게 설정되면 서브스크립션된 애플리케이션 리소스를 조정하는 데 최대 1시간이 걸릴 수 있습니다. 단일 애플리케이션 뷰의 카드에서 동기화 를 클릭하여 수동으로 조정합니다. off 로 설정하면 조정되지 않습니다.
  4. 선택적 사전 배포 및 배포 후 작업을 설정합니다. 서브스크립션 이전 또는 이후에 실행할 Ansible Automation Platform 작업이 있는 경우 Ansible Automation Platform 시크릿을 설정합니다. 작업을 정의하는 Ansible Automation Platform 작업은 이 리포지토리의 prehookposthook 폴더 내에 배치해야 합니다.
  5. 콘솔을 사용하여 인증 정보를 추가해야 하는 경우 인증 정보 추가 를 클릭할 수 있습니다. 콘솔의 지침을 따르십시오. 인증 정보 관리 개요 에서 자세한 내용을 참조하십시오.
  6. 생성을 클릭합니다.
  7. 세부 정보 및 토폴로지를 볼 수 있는 개요 페이지로 리디렉션됩니다.
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 주석을 추가하려면 다음 단계를 완료합니다.

  1. 하나 이상의 리소스를 배포하는 서브스크립션을 생성합니다.
  2. 서브스크립션을 삭제한 후에도 유지하려는 리소스 또는 리소스에 다음 주석을 추가합니다.

    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 리포지토리에서 리소스를 배포하는 방법을 알아봅니다. 애플리케이션 모델 및 정의에서 애플리케이션 모델에 대해 자세히 알아보십시오.

사용자 필수 액세스: 애플리케이션을 생성할 수 있는 사용자 역할입니다. 역할이 할당된 작업만 수행할 수 있습니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.

  1. 콘솔 탐색 메뉴에서 애플리케이션을 클릭하여 나열된 애플리케이션을 확인하고 새 애플리케이션을 생성합니다.
  2. 선택 사항: 생성할 애플리케이션 종류를 선택한 후 YAML 을 선택하여 애플리케이션을 생성하고 편집할 때 콘솔에서 YAML을 볼 수 있습니다. 주제의 뒷부분에 있는 YAML 샘플을 참조하십시오.
  3. 사용할 수 있는 리포지토리 목록에서 Helm 을 선택하고 올바른 필드의 값을 입력합니다. 콘솔의 지침에 따라 입력에 따라 YAML 편집기 변경 값을 확인합니다.
  4. 생성을 클릭합니다.
  5. 세부 정보 및 토폴로지를 볼 수 있는 개요 페이지로 리디렉션됩니다.
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 리소스를 배포할 때 리소스는 특정 리포지토리에 있습니다. 애플리케이션 모델 및 정의에서 애플리케이션 모델에 대해 자세히 알아보십시오.

사용자 필수 액세스: 애플리케이션을 생성할 수 있는 사용자 역할입니다. 역할이 할당된 작업만 수행할 수 있습니다. 역할 기반 액세스 제어 설명서에서 액세스 요구 사항에 대해 알아봅니다.

  1. 콘솔 탐색 메뉴에서 애플리케이션을 클릭하여 나열된 애플리케이션을 확인하고 새 애플리케이션을 생성합니다.
  2. 선택 사항: 생성할 애플리케이션 종류를 선택한 후 YAML 을 선택하여 애플리케이션을 생성하고 편집할 때 콘솔에서 YAML을 볼 수 있습니다. 주제의 뒷부분에 있는 YAML 샘플을 참조하십시오.
  3. 사용할 수 있는 리포지토리 목록에서 오브젝트 저장소를 선택하고 올바른 필드의 값을 입력합니다. 콘솔의 지침에 따라 입력에 따라 YAML 편집기 변경 값을 확인합니다.
  4. 생성을 클릭합니다.
  5. 세부 정보 및 토폴로지를 볼 수 있는 개요 페이지로 리디렉션됩니다.
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) 오브젝트 스토리지 서비스에 정의된 리소스를 서브스크립션하기 위해 서브스크립션을 설정할 수 있습니다. 다음 절차를 참조하십시오.

  1. AWS 계정, 사용자 이름 및 암호를 사용하여 AWS 콘솔에 로그인합니다.
  2. Amazon S3 > Buckets 로 이동합니다. 버킷 홈 페이지로 이동합니다.
  3. 버킷 생성 을 클릭하여 버킷을 생성합니다.
  4. AWS S3 오브젝트 버킷 연결에 필요한 AWS 리전 을 선택합니다.
  5. 버킷 액세스 토큰을 생성합니다.
  6. 탐색 모음에서 사용자 이름으로 이동한 다음 드롭다운 메뉴에서 내 보안 자격 증명을 선택합니다.
  7. AWS IAM 인증 정보 탭에서 CLI, SDK 및 API 액세스에 대한 액세스 키로 이동하여 액세스 키 생성 을 클릭합니다.
  8. 액세스 키 ID , 시크릿 액세스 키를 저장합니다.
  9. 오브젝트 YAML 파일을 버킷에 업로드합니다.
1.4.3.3. AWS 버킷의 오브젝트 구독
  1. 시크릿이 있는 오브젝트 버킷 유형 채널을 생성하여 AWS 버킷 연결을 위한 AccessKeyID,SecretAccessKey리전 을 지정합니다. 세 개의 필드는 AWS 버킷이 생성될 때 생성됩니다.
  2. URL을 추가합니다. URL에 s3 :// 또는 s 3 및 aws 키워드가 포함된 경우 URL은 AWS S3 버킷의 채널을 식별합니다. 예를 들어 다음 버킷 URL에 AWS s3 버킷 식별자가 있는지 확인합니다.

    https://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: PlacementRulekind: 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 주석을 추가하려면 다음 단계를 완료합니다.

  1. 하나 이상의 리소스를 배포하는 서브스크립션을 생성합니다.
  2. 서브스크립션을 삭제한 후에도 유지하려는 리소스 또는 리소스에 다음 주석을 추가합니다.

    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는 prehookposthook 라는 두 개의 하위 폴더를 정의하도록 향상되었습니다. 두 폴더 모두 Git 리포지토리 리소스 루트 경로에 있으며 각각 prehook 및 posthook Ansible Automation Platform 작업을 포함합니다.

Git 서브스크립션이 생성되면 모든 prehook 및 posthook AnsibleJob 리소스가 구문 분석되어 메모리에 오브젝트로 저장됩니다. 애플리케이션 서브스크립션 컨트롤러는 prehook 및 posthook AnsibleJob 인스턴스를 생성할 시기를 결정합니다.

서브스크립션 사용자 지정 리소스를 생성할 때 Git 분기 및 Git 경로는 Git 리포지토리 루트 위치를 가리킵니다. Git 루트 위치에서 두 개의 하위 폴더 prehookposthook 에는 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 를 참조하십시오.

Ansible Automation Platform을 활성화하려면 다음 항목을 참조하십시오.

1.5.2. Ansible Automation Platform 설정

Ansible Automation Platform 작업을 사용하면 작업을 자동화하고 Slack 및 PagerDuty 서비스와 같은 외부 서비스와 통합할 수 있습니다. Git 리포지토리 리소스 루트 경로에는 애플리케이션 배포, 애플리케이션 업데이트 또는 클러스터에서 애플리케이션 제거의 일부로 실행되는 Ansible Automation Platform 작업의 prehookposthook 디렉터리가 포함됩니다.

필수 액세스: 클러스터 관리자

1.5.2.1. 사전 요구 사항
  • 지원되는 OpenShift Container Platform 버전을 설치합니다.
  • Ansible Automation Platform을 설치합니다. 지원되는 최신 버전을 설치하려면 Red Hat Ansible Automation Platform 설명서를 참조하십시오.
  • Ansible Automation Platform Resource Operator를 설치하여 Ansible Automation Platform 작업을 Git 서브스크립션 라이프사이클에 연결합니다. 모범 사례: Ansible Automation Platform 작업 템플릿은 idempotent여야 합니다.
  • INVENTORYEXTRA VARIABLES 둘 다에 대해 템플릿에서 PROMPT ON Cryostat를 선택합니다. 자세한 내용은 작업 템플릿을 참조하십시오.
1.5.2.2. Ansible Automation Platform Resource Operator 설치
  1. OpenShift Container Platform 클러스터 콘솔에 로그인합니다.
  2. 콘솔 탐색에서 OperatorHub 를 클릭합니다.
  3. 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 구성

Ansible Automation Platform 작업을 사용하면 작업을 자동화하고 Slack 및 PagerDuty 서비스와 같은 외부 서비스와 통합할 수 있습니다. Git 리포지토리 리소스 루트 경로에는 애플리케이션 배포, 애플리케이션 업데이트 또는 클러스터에서 애플리케이션 제거의 일부로 실행되는 Ansible Automation Platform 작업의 prehookposthook 디렉터리가 포함됩니다.

필수 액세스: 클러스터 관리자

다음 작업을 사용하여 Ansible Automation Platform 구성을 구성할 수 있습니다.

1.5.3.1. Ansible Automation Platform 시크릿 설정

동일한 서브스크립션 네임스페이스에 Ansible Automation Platform 시크릿 사용자 정의 리소스를 생성해야 합니다. Ansible Automation Platform 시크릿은 동일한 서브스크립션 네임스페이스로 제한됩니다.

  1. Ansible Automation Platform 시크릿 이름 섹션을 작성하여 콘솔에서 시크릿을 생성합니다. 터미널을 사용하여 보안을 생성하려면 샘플 yaml 파일을 편집하고 적용합니다.

    참고: 네임스페이스 는 서브스크립션 네임스페이스와 동일합니다. stringData:tokenhost 는 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
  2. 다음 명령을 실행하여 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 인스턴스를 지속적으로 조정 및 다시 시작합니다.

  1. pre AnsibleJob 이 완료된 후 기본 서브스크립션을 다시 실행합니다.
  2. 기본 서브스크립션에 사양 변경 사항이 있는 경우 서브스크립션을 재배포합니다. 재배포 절차에 맞게 기본 서브스크립션 상태를 업데이트해야 합니다.
  3. hub 클러스터 서브스크립션 상태를 nil 로 재설정합니다. 서브스크립션은 대상 클러스터에서 서브스크립션 배포와 함께 새로 고쳐집니다.

    대상 클러스터에서 배포가 완료되면 대상 클러스터의 서브스크립션 상태가 "서브스크립션 " 또는 " 실패" 로 업데이트되고 허브 클러스터 서브스크립션 상태와 동기화됩니다.

  4. 기본 서브스크립션이 완료되면 새AnsibleJob 인스턴스를 다시 시작합니다.
  5. 서브스크립션이 업데이트되었는지 확인합니다. 다음 출력을 참조하십시오.

    • subscription.status == "subscribed"
    • 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이 지원되지 않습니다.

다음 샘플과 같이 apiVersionimage.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. 서브스크립션 관리자 권한 부여

서브스크립션 관리자 액세스 권한을 부여하는 방법을 알아보십시오. 서브스크립션 관리자는 기본 동작을 변경할 수 있습니다. 다음 프로세스에서 자세히 알아보십시오.

  1. 콘솔에서 Red Hat OpenShift Container Platform 클러스터에 로그인합니다.
  2. 하나 이상의 사용자를 생성합니다. 사용자 생성에 대한 정보는 사용자 준비를 참조하십시오. 그룹 또는 서비스 계정을 준비할 수도 있습니다.

    생성하는 사용자는 app.open-cluster-management.io/subscription 애플리케이션의 관리자입니다. OpenShift Container Platform을 사용하면 서브스크립션 관리자가 기본 동작을 변경할 수 있습니다. 이러한 사용자를 그룹화하여 나중에 설명하는 서브스크립션 관리 그룹을 나타낼 수 있습니다.

  3. 터미널에서 Red Hat Advanced Cluster Management 클러스터에 로그인합니다.
  4. 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
  5. 다음 명령을 사용하여 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/Servicev1/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,lowoff 의 빈도 옵션을 선택하여 불필요한 리소스 조정을 방지하고 서브스크립션 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. 서브스크립션 조정 비율이 낮게 설정되면 서브스크립션된 애플리케이션 리소스를 조정하는 데 최대 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-ratehigh 로 설정된 경우에도 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-ratehigh 로 설정되어 있어도 자동으로 조정되지 않습니다.

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 컨트롤러를 변경하려면 다음 단계를 참조하십시오.

  1. 다음 명령을 실행하여 multiclusterhub 를 일시 중지합니다.

    oc annotate mch -n open-cluster-management multiclusterhub mch-pause=true --overwrite=true
  2. oc edit 명령에 컨트롤러 이름을 추가하여 배포 파일을 편집합니다. 다음 예제 명령을 참조하십시오.

    oc edit deployment -n open-cluster-management multicluster-operators-hub-subscription
  3. - 명령을 검색하여 컨트롤러 명령 플래그를 찾습니다.
  4. 컨트롤러의 containers 섹션에서 - 명령 플래그를 삽입합니다. 예를 들어 RetryPeriod 를 삽입합니다.
  5. 파일을 저장합니다. 컨트롤러가 자동으로 다시 시작되어 플래그를 적용합니다.
  6. 변경하려는 각 컨트롤러에 대해 이 절차를 반복합니다.
  7. 다음 명령을 실행하여 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 서버에 연결할 수 있습니다. 사용자 및 액세스 토큰을 사용하여 프라이빗 리포지토리에 연결하려면 다음 절차를 참조하십시오.

  1. 채널과 동일한 네임스페이스에 시크릿을 생성합니다. 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
  2. 시크릿을 사용하여 채널을 구성합니다. 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 서버에 안전하게 연결할 수 있습니다.

  1. 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-----
  2. 이 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 연결
  1. 데이터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
  2. 시크릿을 사용하여 채널을 구성합니다. 다음 샘플을 참조하십시오.

    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,ObjectBucketGit 유형 채널에 대한 서브스크립션의 경우:
  • 서브스크립션이 활성 상태일 때 시간 범위 중에 리소스가 감지되면 리소스 배포가 시작됩니다.
  • 서브스크립션이 실행 중인 배포에서 차단될 때 시간 범위 외부에서 리소스가 감지되면 리소스 배포 요청이 캐시됩니다. 다음에 서브스크립션 범위가 활성화되면 캐시된 요청이 적용되고 관련 배포가 시작됩니다.
  • 시간 창이 차단 되면 애플리케이션 서브스크립션을 통해 이전에 배포한 모든 리소스가 그대로 유지됩니다. 새 업데이트는 시간 창이 다시 활성화될 때까지 차단됩니다.

최종 사용자는 앱 하위 시간 창이 차단되면 배포된 모든 리소스가 제거된다고 잘못 생각할 수 있습니다. 그리고 앱 하위 시간 창이 다시 활성 상태일 때 돌아올 것입니다.

정의된 시간 기간 동안 배포가 시작되고 시간이 지남에 따라 정의된 기간이 지나면 배포가 완료될 때까지 계속 실행됩니다.

서브스크립션의 시간 창을 정의하려면 필수 필드 및 값을 서브스크립션 리소스 정의 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 를 정의하여 서브스크립션의 다른 릴리스 이름을 설정해야 합니다. 기존 서브스크립션 내에서 이름을 변경하려면 먼저 해당 서브스크립션을 삭제한 다음 기본 릴리스 이름으로 서브스크립션을 다시 생성해야 합니다.

packageOverrides:
- packageName: nginx-ingress
  packageAlias: my-helm-release-name

1.6.10. 채널 샘플 개요

파일을 빌드하는 데 사용할 수 있는 샘플 및 YAML 정의를 확인합니다. 채널(channel.apps.open-cluster-management.io)은 Kubernetes 애플리케이션용 Red Hat Advanced Cluster Management를 생성 및 관리하기 위한 지속적인 통합 및 지속적인 제공 기능을 제공합니다.

OpenShift CLI 툴을 사용하려면 다음 절차를 참조하십시오.

  1. 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
  2. 다음 명령을 실행하여 파일을 API 서버에 적용합니다. 파일 이름을 파일 이름으로 바꿉니다.

    oc apply -f filename.yaml
  3. 다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.

    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

필수 항목

값을 apps.open-cluster-management.io/v1 로 설정합니다.

kind

필수 항목

값을 Channel 으로 설정하여 리소스가 채널임을 나타냅니다.

metadata.name

필수 항목

채널의 이름입니다.

metadata.namespace

필수 항목

채널의 네임스페이스입니다. 각 채널에는 Git 채널을 제외한 고유한 네임스페이스가 필요합니다.

spec.sourceNamespaces

선택 사항

채널 컨트롤러에서 채널을 검색하고 승격하기 위해 신규 또는 업데이트된 배포가 필요한 네임스페이스를 식별합니다.

spec.type

필수 항목

채널 유형입니다. 지원되는 유형은 HelmRepo,Git, ObjectBucket ( console의 오브젝트 스토리지)입니다.

spec.pathname

HelmRepo,Git,ObjectBucket 채널에 필요

HelmRepo 채널의 경우 값을 Helm 리포지토리의 URL로 설정합니다. ObjectBucket 채널의 경우 값을 오브젝트 스토리지의 URL로 설정합니다. Git 채널의 경우 값을 Git 리포지토리의 HTTPS URL로 설정합니다.

spec.secretRef.name

선택 사항

리포지토리에 액세스하거나 차트에 액세스하는 경우와 같이 인증에 사용할 Kubernetes Secret 리소스를 식별합니다. HelmRepo,ObjectBucketGit 유형 채널만 사용하여 인증에 보안을 사용할 수 있습니다.

spec.gates

선택 사항

채널 내에서 배포 가능을 승격하기 위한 요구 사항을 정의합니다. 요구 사항이 설정되지 않은 경우 채널 네임스페이스 또는 소스에 추가되는 배포 가능한 모든 배포가 채널로 확장됩니다. gates 값은 ObjectBucket 채널 유형에만 적용되며 HelmRepoGit 채널 유형 에는 적용되지 않습니다.

spec.gates.annotations

선택 사항

채널의 주석입니다. 배포 가능 항목에는 채널에 포함할 일치하는 주석이 있어야 합니다.

metadata.labels

선택 사항

채널의 레이블입니다.

spec.insecureSkipVerify

선택 사항

기본값은 false 입니다. true 설정된 경우 인증을 건너뛰어 채널 연결이 빌드됩니다.

채널의 정의 구조는 다음 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.11의 경우 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 툴을 사용하려면 다음 절차를 참조하십시오.

  1. 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
  2. 다음 명령을 실행하여 파일을 api 서버에 적용합니다. 파일 이름을 파일 이름으로 바꿉니다.

    oc apply -f filename.yaml
  3. 다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.

    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

필수 항목

값을 apps.open-cluster-management.io/v1 로 설정합니다.

kind

필수 항목

값을 Subscription 으로 설정하여 리소스가 서브스크립션임을 나타냅니다.

metadata.name

필수 항목

서브스크립션을 식별하는 이름입니다.

metadata.namespace

필수 항목

서브스크립션에 사용할 네임스페이스 리소스입니다.

metadata.labels

선택 사항

서브스크립션의 레이블입니다.

spec.channel

선택 사항

서브스크립션 채널을 정의하는 네임스페이스 이름("Namespace/Name")입니다. 채널 또는 소스 또는 source Namespace 필드를 정의합니다. 일반적으로 channel 필드를 사용하여 source 또는 sourceNamespace 필드를 사용하는 대신 채널을 가리킵니다. 둘 이상의 필드가 정의되면 정의된 첫 번째 필드가 사용됩니다.

spec.sourceNamespace

선택 사항

배포 대상이 hub 클러스터에 저장되는 소스 네임스페이스입니다. 네임스페이스 채널에만 이 필드를 사용합니다. 채널 또는 소스 또는 source Namespace 필드를 정의합니다. 일반적으로 channel 필드를 사용하여 source 또는 sourceNamespace 필드를 사용하는 대신 채널을 가리킵니다.

spec.source

선택 사항

배포 대상이 저장되는 Helm 리포지토리의 경로 이름("URL")입니다. Helm 리포지토리 채널에만 이 필드를 사용합니다. 채널 또는 소스 또는 source Namespace 필드를 정의합니다. 일반적으로 channel 필드를 사용하여 source 또는 sourceNamespace 필드를 사용하는 대신 채널을 가리킵니다.

spec.name

HelmRepo 유형 채널에 필요합니다. ObjectBucket 유형 채널의 경우 선택 사항

대상 Helm 차트 또는 채널 내에서 배포할 수 있는 특정 이름입니다. 필드가 선택 사항인 채널 유형에 대해 name 또는 packageFilter 가 정의되지 않은 경우 모든 배포 대상이 발견되고 각 배포 가능한 최신 버전이 검색됩니다.

spec.packageFilter

선택 사항

대상 배포 가능 항목을 찾는 데 사용할 매개 변수 또는 배포 가능 항목의 하위 집합을 정의합니다. 여러 필터 조건이 정의된 경우 배포 가능한 모든 필터 조건을 충족해야 합니다.

spec.packageFilter.version

선택 사항

배포 가능한 버전 또는 버전입니다. 다양한 버전을 > 1.0 이나 < 3.0 ) 형식으로 사용할 수 있습니다. 기본적으로 최신 "creationTimestamp" 값이 있는 버전이 사용됩니다.

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

선택 사항이지만 직접 관리하려는 독립형 클러스터 또는 클러스터에 필요합니다.

서브스크립션을 로컬로 배포해야 하는지 여부를 정의합니다.

서브스크립션이 지정된 채널과 동기화되도록 값을 true 로 설정합니다.

서브스크립션이 지정된 채널의 리소스에 가입하지 못하도록 값을 false 로 설정합니다.

클러스터가 독립형 클러스터이거나 이 클러스터를 직접 관리하는 경우 이 필드를 사용합니다. 클러스터가 다중 클러스터의 일부이고 클러스터를 직접 관리하지 않으려면 클러스터 ,clusterSelector 또는 placementRef 중 하나만 사용하여 서브스크립션을 배치할 위치를 정의합니다. 클러스터가 다중 클러스터의 Hub이고 클러스터를 직접 관리하려면 서브스크립션 운영자가 리소스에 로컬에 가입하기 전에 Hub를 관리 클러스터로 등록해야 합니다.

spec.placement.clusters

선택 사항

서브스크립션을 배치할 클러스터를 정의합니다. 다중 클러스터에 대해 서브스크립션을 배치해야 하는 위치를 정의하는 데 ,clusterSelector 또는 placementRef 중 하나만 사용됩니다. 클러스터가 허브 클러스터가 아닌 독립형 클러스터인 경우 로컬 클러스터를 사용할 수도 있습니다.

spec.placement.clusters.name

선택 사항이지만 클러스터를 정의하는 데 필요합니다.

서브스크립션 클러스터의 이름 또는 이름입니다.

spec.placement.clusterSelector

선택 사항

서브스크립션을 배치할 클러스터를 식별하는 데 사용할 라벨 선택기를 정의합니다. ,clusterSelector 또는 placementRef 중 하나만 사용하여 다중 클러스터에 대한 서브스크립션을 배치할 위치를 정의합니다. 클러스터가 허브 클러스터가 아닌 독립형 클러스터인 경우 로컬 클러스터를 사용할 수도 있습니다.

spec.placement.placementRef

선택 사항

서브스크립션에 사용할 배치 규칙을 정의합니다. ,clusterSelector 또는 placementRef 중 하나만 사용하여 다중 클러스터에 대한 서브스크립션을 배치할 위치를 정의합니다. 클러스터가 Hub 클러스터가 아닌 독립형 클러스터인 경우 로컬 클러스터를 사용할 수도 있습니다.

spec.placement.placementRef.name

배치 규칙을 사용하는 데 선택 사항이지만 필수

서브스크립션 배치 규칙의 이름입니다.

spec.placement.placementRef.kind

배치 규칙을 사용하는 데 선택 사항이지만 필요합니다.

값을 Placement 로 설정하여 서브스크립션 배포에 배치 규칙이 사용됨을 나타냅니다.

spec.overrides

선택 사항

클러스터별 설정과 같이 재정의해야 하는 매개변수와 값입니다.

spec.overrides.clusterName

선택 사항

매개변수 및 값을 재정의하는 클러스터 또는 클러스터의 이름입니다.

spec.overrides.clusterOverrides

선택 사항

재정의할 매개변수 및 값의 구성입니다.

spec.timeWindow

선택 사항

서브스크립션이 활성화되거나 차단될 때 시간 창을 구성하는 설정을 정의합니다.

spec.timeWindow.type

시간 창을 구성하는 데 선택 사항이지만 필수

구성된 시간 기간 동안 서브스크립션이 활성 상태인지 또는 차단되었는지 여부를 나타냅니다. 서브스크립션 배포는 서브스크립션이 활성화된 경우에만 수행됩니다.

spec.timeWindow.location

시간 창을 구성하는 데 선택 사항이지만 필수

시간 창에 대해 구성된 시간대의 시간대입니다. 모든 시간대는 Time Zone (tz) 데이터베이스 이름 형식을 사용해야 합니다. 자세한 내용은 시간대 데이터베이스 를 참조하십시오.

spec.timeWindow.daysofweek

시간 창을 구성하는 데 선택 사항이지만 필수

시간 범위를 적용하여 시간 창을 만들 때 요일을 나타냅니다. 일 목록은 요일: ["Monday", "Wednesday", "Friday"] 와 같은 배열로 정의되어야 합니다.

spec.timeWindow.hours

시간 창을 구성하는 데 선택 사항이지만 필수

시간 창에 대한 시간 범위를 정의합니다. 시간 범위의 시작 시간과 종료 시간은 각 시간 창에 대해 정의해야 합니다. 서브스크립션에 대해 여러 시간 창 범위를 정의할 수 있습니다.

spec.timeWindow.hours.start

시간 창을 구성하는 데 선택 사항이지만 필수

시간 창 시작을 정의하는 타임 스탬프입니다. 타임스탬프는 Go 프로그래밍 언어 Kitchen 형식 "hh:mmpm" 을 사용해야 합니다. 자세한 내용은 Constants 를 참조하십시오.

spec.timeWindow.hours.end

시간 창을 구성하는 데 선택 사항이지만 필수

시간 창의 끝을 정의하는 타임 스탬프입니다. 타임스탬프는 Go 프로그래밍 언어 Kitchen 형식 "hh:mmpm" 을 사용해야 합니다. 자세한 내용은 Constants 를 참조하십시오.

참고:

  • YAML을 정의할 때 서브스크립션은 packageFilters 를 사용하여 여러 Helm 차트, 배포 가능 또는 기타 Kubernetes 리소스를 가리킬 수 있습니다. 그러나 서브스크립션은 최신 버전의 하나의 차트 또는 배포 가능한 리소스 또는 기타 리소스만 배포합니다.
  • 시간 창의 경우 창의 시간 범위를 정의하는 경우 종료 시간 전에 시작 시간을 설정해야 합니다. 구독에 대해 여러 시간 창을 정의하는 경우 창의 시간 범위가 겹치지 않습니다. 실제 시간 범위는 작업 중인 시간 및 위치와 다른 시간 및 위치로 설정할 수 있는 subscription-controller 컨테이너 시간을 기반으로 합니다.
  • 서브스크립션 사양 내에서 Helm 릴리스 배치를 서브스크립션 정의의 일부로 정의할 수도 있습니다. 각 서브스크립션은 기존 배치 규칙을 참조하거나 서브스크립션 정의 내에서 직접 배치 규칙을 정의할 수 있습니다.
  • spec.placement 섹션에 서브스크립션을 배치할 위치를 정의하는 경우 다중 클러스터 환경에 클러스터 ,clusterSelector 또는 placementRef 중 하나만 사용합니다.
  • 두 개 이상의 배치 설정을 포함하는 경우 하나의 설정이 사용되며 다른 설정은 무시됩니다. 다음 우선 순위는 서브스크립션 Operator에서 사용하는 설정을 결정하는 데 사용됩니다.

    1. placementRef
    2. 클러스터
    3. 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-releaseNamenginx-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: kustomizationpackageOverrides 에 필요합니다. 덮어쓰기는 새 항목을 추가하거나 기존 항목을 업데이트합니다. 기존 항목은 제거되지 않습니다.

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 툴을 사용하려면 다음 절차를 참조하십시오.

  1. 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
  2. 다음 명령을 실행하여 파일을 API 서버에 적용합니다. 파일 이름을 파일 이름으로 바꿉니다.

    oc apply -f filename.yaml
  3. 다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.

    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

필수 항목

값을 apps.open-cluster-management.io/v1 로 설정합니다.

kind

필수 항목

값을 PlacementRule 로 설정하여 리소스가 배치 규칙임을 나타냅니다.

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 코어 또는 메모리 를 기반으로 클러스터를 선택하도록 cpu 로 값을 설정합니다.

spec.ResourceHint.order

선택 사항

이 값을 오름차순의 경우 asc 로 설정하거나 내림차순 으로 축소합니다.

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 툴을 사용하려면 다음 절차를 참조하십시오.

  1. 원하는 편집 툴을 사용하여 애플리케이션 YAML 파일을 작성하고 저장합니다.
  2. 다음 명령을 실행하여 파일을 API 서버에 적용합니다. 파일 이름을 파일 이름으로 바꿉니다.

    oc apply -f filename.yaml
  3. 다음 명령을 실행하여 애플리케이션 리소스가 생성되었는지 확인합니다.

    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

app.k8s.io/v1beta1

필수 항목

kind

애플리케이션

필수 항목

메타데이터

  
 

name: 애플리케이션 리소스를 식별하는 이름입니다.

필수 항목

 

namespace: 애플리케이션에 사용할 네임스페이스 리소스입니다.

 

spec

  

selector.matchLabels

이 애플리케이션이 연결될 서브스크립션 또는 서브스크립션에 있는 Kubernetes 레이블 및 값인 key:value 쌍입니다. 레이블을 사용하면 애플리케이션 리소스에서 레이블 이름과 값을 일치시켜 관련 서브스크립션을 찾을 수 있습니다.

필수 항목

이러한 애플리케이션을 정의하는 사양은 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

법적 공지

Copyright © 2024 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.