1.5. 애플리케이션 고급 구성

구독할 때 리소스 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'

다음으로 서브스크립션 관리자가 기본 동작을 변경하는 방법에 대한 유용한 예제를 참조하십시오.

다음 예제에서는 서브스크립션 관리자로 로그인되어 있습니다.

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

해당 채널 유형: 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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  name: user1
  age: 20

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

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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  age: 20

특정 Git 분기, 커밋 또는 태그를 구독할 수 있습니다.

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>

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

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

채널 구성에서 high,medium,low, off 등의 빈도 옵션을 선택하여 불필요한 리소스 조정을 방지하고 서브스크립션 운영자에 대한 과부하를 방지할 수 있습니다.

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

설정의 다음 정의를 참조하십시오:attribute:<value>:

서브스크립션에서 참조하는 채널 사용자 정의 리소스의 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

이전 예에서 sample/git-channel 을 사용하는 모든 서브스크립션에는 낮은 조정 빈도가 할당됩니다.

채널의 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

조정- rate가 채널에서 high 로 설정되어 있어도 git-subscription 에서 배포한 리소스가 자동으로 조정 되지 않음을 확인합니다.

15분마다 서브스크립션 Operator는 현재 배포된 Helm 차트의 해시와 소스 리포지터리의 해시를 비교합니다. 대상 클러스터에 변경 사항이 적용됩니다. 리소스 조정 빈도는 다른 애플리케이션 배포 및 업데이트의 성능에 영향을 미칩니다.

예를 들어 수백 개의 애플리케이션 서브스크립션이 있고 모든 서브스크립션을 더 자주 조정하려는 경우 조정 시간이 더 느립니다.

애플리케이션의 Kubernetes 리소스에 따라 적절한 조정 빈도가 성능을 향상시킬 수 있습니다.

서브스크립션에서 참조하는 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

이 예에서 조정- rate가 채널에서 high 로 설정되어 있어도 helm-subscription 에 의해 배포된 리소스는 자동으로 조정 되지 않습니다.

채널 및 서브스크립션을 사용하여 Git 서버에 연결할 수 있습니다. 사용자 및 액세스 토큰을 사용하여 개인 리포지토리에 연결하려면 다음 절차를 참조하십시오.

개발 환경에서 다음 연결 방법을 사용하여 사용자 정의 또는 자체 서명된 인증 기관에서 서명한 SSL 인증서로 개인 호스팅 Git 서버에 연결할 수 있습니다. 그러나 다음 절차는 프로덕션에는 권장되지 않습니다.

채널 사양에 insecureSkipVerify: true 를 지정합니다. 그러지 않으면 Git 서버에 대한 연결이 실패하고 다음과 유사한 오류와 함께 실패합니다.

x509: certificate is valid for localhost.com, not localhost

이 방법에 대한 채널 사양 추가를 사용하여 다음 샘플을 참조하십시오.

apiVersion: apps.open-cluster-management.io/v1
ind: Channel
metadata:
labels:
  name: sample-channel
  namespace: sample
spec:
  type: GitHub
  pathname: <Git HTTPS URL>
  insecureSkipVerify: true

이 연결 방법을 사용하여 사용자 정의 또는 자체 서명된 인증 기관에서 서명한 SSL 인증서로 개인 호스팅 Git 서버에 안전하게 연결할 수 있습니다.

Git 채널 연결 구성에 CA 인증서, 인증 정보 또는 SSH 키와 같은 업데이트가 필요한 경우 동일한 네임스페이스에 새 시크릿 및 ConfigMap을 생성하고 해당 새 시크릿 및 ConfigMap을 참조하도록 채널을 업데이트해야 합니다. 자세한 내용은 보안 HTTPS 연결에 사용자 정의 CA 인증서 사용을 참조하십시오.

INVENTORY 및 EXTRA VARIABLES 둘 다에 대해 템플릿에서 PROMPT ON >-<을 선택합니다. 자세한 내용은 작업 템플릿을 참조하십시오.

콘솔의 인증 정보 페이지에서 필요한 인증 정보를 생성할 수 있습니다. 인증 정보 추가 를 클릭하거나 탐색에서 페이지에 액세스합니다. 인증 정보 정보는 Ansible Automation Platform에 대한 인증 정보 생성을 참조하십시오.

Ansible Tower 작업을 Git 서브스크립션에 통합할 수 있습니다. 예를 들어 데이터베이스 프런트 엔드 및 백엔드 애플리케이션의 경우 Ansible 작업과 함께 Ansible Tower를 사용하여 데이터베이스를 인스턴스화해야 하며 애플리케이션은 Git 서브스크립션을 통해 설치됩니다. 서브스크립션을 사용하여 프런트 엔드 및 백엔드 애플리케이션을 배포하기 전에 데이터베이스가 인스턴스화됩니다.

애플리케이션 서브스크립션 Operator가 향상되어 prehook 및 posthook 두 개의 하위 폴더를 정의할 수 있습니다. 두 폴더 모두 Git 리포지토리 리소스 루트 경로에 있으며, 각각 prehook 및 posthook Ansible 작업을 모두 포함합니다.

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

서브스크립션 CR을 생성할 때 Git-branch 및 Git-path는 Git 리포지토리 루트 위치를 가리킵니다. Git 루트 위치에서 두 개의 하위 폴더 prehook 및 posthook 에는 Kind:AnsibleJob 리소스가 하나 이상 포함되어야 합니다.

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

oc apply -f

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

prehook 및 posthook AnsibleJobs가 있는 기본 서브스크립션의 경우 모든 prehook 및 posthook AnsibleJobs 또는 기본 서브스크립션이 Git 리포지토리에 업데이트된 후 main-sub 서브스크립션을 조정해야 합니다.

Prehook AnsibleJobs 및 기본 서브스크립션은 AnsibleJob 이전 인스턴스를 지속적으로 조정하고 다시 시작합니다.

AnsibleJob CR이 생성되면 대상 Ansible Tower와 통신하여 Ansible Tower 작업을 시작하기 위해 Kubernetes 작업 CR이 생성됩니다. 작업이 완료되면 작업의 최종 상태가 AnsibleJob status.ansibleJobResult 로 반환됩니다.

참고:

AnsibleJob status.conditions는 Kubernetes 작업 결과 생성을 저장하기 위해 Ansible 작업 운영자가 예약합니다. status.conditions는 실제 Ansible Tower 작업 상태를 반영하지 않습니다.

서브스크립션 컨트롤러는 AnsibleJob.status.conditions 대신 AnsibleJob.status.ansibleJobResult 에서 Ansible Tower 작업 상태를 확인합니다.

prehook 및 posthook AnsibleJob 워크플로우에서 언급한 것처럼 기본 서브스크립션이 Git 리포지토리에서 업데이트되면 새로운 prehook 및 posthook AnsibleJob 인스턴스가 생성됩니다. 따라서 하나의 기본 서브스크립션을 통해 여러 AnsibleJob 인스턴스에 연결할 수 있습니다.

subscription.status.ansibleJobs에 네 개의 필드가 정의됩니다.

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

placement 및 ManagedClusterSetBinding 사용자 정의 리소스를 통해 GitOps 네임스페이스에 바인딩된 모든 관리 클러스터에 대해 GitOps Operator와 통합할 때 네임스페이스에 ManagedCluster 에 액세스할 토큰이 있는 시크릿이 생성됩니다. GitOps 컨트롤러에서 관리 클러스터에 리소스를 동기화하는 데 필요합니다. 애플리케이션 라이프사이클 작업을 수행하기 위해 GitOps 네임스페이스에 대한 관리자 액세스 권한이 부여되면 사용자는 이 시크릿 및 관리 수준에 대한 액세스 권한도 부여됩니다.

이를 원하지 않는 경우 사용자를 네임스페이스 범위 admin 역할에 바인딩하는 대신 생성 및 사용자를 바인딩하는 데 사용할 수 있는 애플리케이션 리소스와 함께 더 제한적인 사용자 정의 역할을 사용합니다. 다음 ClusterRole 예제를 참조하십시오.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: application-set-admin
rules:
- apiGroups:
  - argoproj.io
  resources:
  - applicationsets
  verbs:
  - get
  - list
  - watch
  - update
  - delete
  - deletecollection
  - patch

배포할 수 있는 애플리케이션 샘플은 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:

채널 정의 구조는 다음 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/

다음 예제 채널 정의는 Object 스토리지 버킷을 채널로 추상화합니다.

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

다음 예제 채널 정의에서는 Helm 리포지터리를 채널로 추상화합니다.

사용 중단 알림: 2.5의 경우 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/

다음 채널 정의에서는 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

다음 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: PlacementRule
  overrides:
    clusterName:
    clusterOverrides:
      path:
      value:

참고:

서브스크립션은 다음 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: PlacementRule
      name: towhichcluster
  overrides:
  - clusterName: "/"
    clusterOverrides:
    - path: "metadata.namespace"
      value: default

배포할 수 있는 애플리케이션 샘플은 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

미러링된 채널(애플리케이션 소스 저장소)이 있는 경우 서브스크립션 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

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: PlacementRule
      name: towhichcluster
  timewindow:
    windowtype: "active" #Enter active or blocked depending on the purpose of the type.
    location: "America/Los_Angeles"
    daysofweek: ["Monday", "Wednesday", "Friday"]
    hours:
      - start: "10:20AM"
        end: "10:30AM"
      - start: "12:40PM"
        end: "1:40PM"

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

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

    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: PlacementRule
          name: dev-clusters

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

oc create route passthrough --service=multicluster-operators-subscription -n open-cluster-management

apiVersion: v1
kind: Secret
metadata:
  name: my-github-webhook-secret
data:
  secret: BASE64_ENCODED_SECRET

oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-enabled="true"

oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-secret="<the_secret_name>"

다음 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:

배포할 수 있는 애플리케이션 샘플은 stolostron 리포지토리를 참조하십시오.

기존 배치 규칙에는 배치 규칙의 상태를 나타내는 다음 필드가 포함될 수 있습니다. 이 상태 섹션은 규칙에 대한 YAML 구조의 spec 섹션 뒤에 추가됩니다.

status:
  decisions:
    clusterName:
    clusterNamespace:

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

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

애플리케이션 리소스를 생성하거나 업데이트하기 위해 애플리케이션 정의 YAML 콘텐츠를 작성하려면 YAML 구조에 몇 가지 필수 필드 및 값을 포함해야 합니다. 애플리케이션 요구 사항 또는 애플리케이션 관리 요구 사항에 따라 다른 선택적 필드 및 값을 포함해야 할 수 있습니다.

다음 YAML 구조는 애플리케이션 및 일부 공통 선택적 필드에 대한 필수 필드를 보여줍니다.

apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  name:
  namespace:
spec:
  selector:
    matchLabels:
      label_name: label_value

이러한 애플리케이션을 정의하는 사양은 Kubernetes SIG(Special Interest Group)에서 제공하는 애플리케이션 메타데이터 설명자 사용자 정의 리소스 정의를 기반으로 합니다. 표에 표시된 값만 필요합니다.

이 정의를 사용하면 자체 애플리케이션 YAML 콘텐츠를 구성하는 데 도움이 될 수 있습니다. 이 정의에 대한 자세한 내용은 Kubernetes SIG Application CRD 커뮤니티 사양 을 참조하십시오.

배포할 수 있는 애플리케이션 샘플은 stolostron 리포지토리를 참조하십시오.

애플리케이션의 정의 구조는 다음 예제 YAML 콘텐츠와 유사합니다.

apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  name: my-application
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      my-label: my-label-value