애플리케이션

채널(channel.apps.open-cluster-management.io)은 클러스터가 서브스크립션으로 구독할 수 있는 소스 리포지토리를 정의하고 hub 클러스터에서 Git, Helm 릴리스, 오브젝트 스토리지 리포지토리 및 리소스 템플릿과 같은 유형일 수 있습니다.

권한이 필요한 채널에 Kubernetes 리소스 또는 Helm 차트가 필요한 애플리케이션이 있는 경우(예: 권한이 부여된 Git 리포지토리) 보안을 사용하여 이러한 채널에 대한 액세스 권한을 제공할 수 있습니다. 서브스크립션은 데이터 보안을 유지하면서 이러한 채널에서 배포하기 위해 Kubernetes 리소스 및 Helm 차트에 액세스할 수 있습니다.

채널은 hub 클러스터 내의 네임스페이스를 사용하여 배포를 위해 리소스가 저장된 물리적 위치를 가리킵니다. 클러스터는 채널을 구독하여 각 클러스터에 배포할 리소스를 식별할 수 있습니다.

참고: 고유한 네임스페이스에 각 채널을 생성하는 것이 좋습니다. 그러나 Git 채널에서는 Git, Helm, 오브젝트 스토리지를 포함하여 다른 유형의 채널과 네임스페이스를 공유할 수 있습니다.

채널 내의 리소스는 해당 채널을 구독하는 클러스터에서만 액세스할 수 있습니다.

배치 규칙(placementrule.apps.open-cluster-management.io)은 리소스 템플릿을 배포할 수 있는 대상 클러스터를 정의합니다. 배치 규칙을 사용하면 배포 가능한 다중 클러스터를 쉽게 배포할 수 있습니다. 배치 규칙은 거버넌스 및 위험 정책에도 사용됩니다. 방법에 대한 자세한 내용은 Governance 를 참조하십시오.

클러스터를 관리하기 위해 Git 리포지토리를 조정하기 위한 모범 사례를 알아보십시오.

common-managed/
    apps/
      app-name-0/
      app-name-1/
    config/
      config001/
      config002/

managed-subscriptions
    apps/
    config/
    policies/

root-subscription/

Git 리포지토리를 사용하여 서브스크립션을 생성할 때 서브스크립션을 삭제한 후 do-not-delete 주석을 추가하여 특정 배포된 리소스를 유지할 수 있습니다. do-not-delete 주석은 최상위 배포 리소스에서만 작동합니다. do-not-delete 주석을 추가하려면 다음 단계를 완료합니다.

서브스크립션을 삭제한 후에도 다른 리소스가 삭제되는 동안 do-not-delete 주석이 있는 리소스는 계속 존재합니다.

참고: 네임스페이스에 바인드된 do-not-delete 주석을 사용하여 배포된 리소스입니다. 따라서 나머지 리소스를 제거할 때까지 네임스페이스를 삭제할 수 없습니다.

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

참고: 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를 사용합니다.

Helm은 서브스크립션을 삭제한 후 특정 배포된 리소스를 유지하기 위한 주석을 제공합니다. 자세한 내용은 Helm Not Uninstall a Resource 를 참조하십시오.

참고: 주석은 Helm 차트에 있어야 합니다.

다음 예제 채널 정의는 오브젝트 스토리지를 채널로 추상화합니다.

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를 사용합니다.

서브스크립션을 설정하여 Amazon Simple Storage Service(Amazon S3) 오브젝트 스토리지 서비스에 정의된 리소스를 구독할 수 있습니다. 다음 절차를 참조하십시오.

다음 전체 AWS S3 오브젝트 버킷 채널 샘플 YAML 파일을 참조하십시오.

apiVersion: apps.open-cluster-management.io/v1
kind: Channel
metadata:
  name: object-dev
  namespace: ch-object-dev
spec:
  type: ObjectBucket
  pathname: https://s3.console.aws.amazon.com/s3/buckets/sample-bucket-1
  secretRef:
    name: secret-dev
---
apiVersion: v1
kind: Secret
metadata:
  name: secret-dev
  namespace: ch-object-dev
stringData:
  AccessKeyID: <your AWS bucket access key id>
  SecretAccessKey: <your AWS bucket secret access key>
  Region: <your AWS  bucket region>
type: Opaque

kind: PlacementRule 및 kind: Subscription 과 함께 다음 샘플 YAML에 표시된 대로 다른 AWS 서브스크립션 및 배치 규칙 오브젝트를 계속 생성할 수 있습니다.

apiVersion: apps.open-cluster-management.io/v1
kind: PlacementRule
metadata:
  name: towhichcluster
  namespace: obj-sub-ns
spec:
  clusterSelector: {}
---
apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: obj-sub
  namespace: obj-sub-ns
spec:
  channel: ch-object-dev/object-dev
  placement:
    placementRef:
      kind: PlacementRule
      name: towhichcluster

오브젝트 버킷의 특정 하위 폴더 내의 오브젝트를 구독할 수도 있습니다. 하위 폴더 주석을 서브스크립션에 추가하여 오브젝트 버킷 서브스크립션이 하위 폴더의 모든 리소스만 적용하도록 강제 적용합니다.

subfolder-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

오브젝트 스토리지 리포지토리를 사용하여 서브스크립션을 생성할 때 서브스크립션을 삭제한 후 do-not-delete 주석을 추가하여 특정 배포된 리소스를 유지할 수 있습니다. do-not-delete 주석은 최상위 배포 리소스에서만 작동합니다. do-not-delete 주석을 추가하려면 다음 단계를 완료합니다.

서브스크립션을 삭제한 후에도 다른 리소스가 삭제되는 동안 do-not-delete 주석이 있는 리소스는 계속 존재합니다.

참고: 네임스페이스에 바인드된 do-not-delete 주석을 사용하여 배포된 리소스입니다. 따라서 나머지 리소스를 제거할 때까지 네임스페이스를 삭제할 수 없습니다.

애플리케이션 서브스크립션 컨트롤러는 prehook AnsibleJob 오브젝트로 prehook 폴더의 모든 kind:AnsibleJob CR을 검색한 다음 새 prehook AnsibleJob 인스턴스를 생성합니다. 새 인스턴스 이름은 prehook AnsibleJob 오브젝트 이름과 임의의 접미사 문자열입니다.

다음 인스턴스 이름: database-sync-1-2913063 을 참조하십시오.

애플리케이션 서브스크립션 컨트롤러는 prehook AnsibleJob status.AnsibleJobResult 를 확인하는 1분 루프에서 조정 요청을 다시 대기열에 넣습니다. prehook 상태가 성공 하면 애플리케이션 서브스크립션은 계속 기본 서브스크립션을 배포합니다.

애플리케이션 서브스크립션 상태가 업데이트되면 서브스크립션 상태가 서브스크립션되거나 서브스크립션 상태의 모든 대상 클러스터에 전파되는 경우 애플리케이션 서브스크립션 컨트롤러는 posthook AnsibleJob 오브젝트로 모든 AnsibleJob 종류 사용자 정의 리소스를 검색합니다. 그런 다음 새 posthook AnsibleJob 인스턴스를 생성합니다. 새 인스턴스 이름은 posthook AnsibleJob 오브젝트 이름과 임의의 접미사 문자열입니다.

service-ticket-1-2913849 예제 인스턴스 이름을 참조하십시오.

유효한 prehook AnsibleJob 으로 서브스크립션은 배치 규칙의 결정에 관계없이 prehook AnsibleJob 을 시작합니다.

예를 들어 배치 규칙 서브스크립션을 전파하지 못한 prehook AnsibleJob 이 있을 수 있습니다. 배치 규칙 결정이 변경되면 새로운 prehook 및 posthook AnsibleJob 인스턴스가 생성됩니다.

{aap_short}를 활성화하려면 다음 주제를 참조하십시오.

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

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

앱 서브스크립션 컨트롤러에서 prehook 및 posthook Ansible 작업을 생성할 때 서브스크립션 spec.hooksecretref 의 시크릿을 사용할 수 있는 경우 AnsibleJob 사용자 정의 리소스 spec.tower_auth_secret 으로 전송되고 AnsibleJob 은 Ansible Automation Platform에 액세스할 수 있습니다.

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

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

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 인스턴스에 연결할 수 있습니다.

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
  job_tags: "provision,install,configuration"
  skip_tags: "configuration,restart"

AnsibleJob 사용자 정의 리소스를 사용하여 Ansible Automation Platform 워크플로를 시작하려면 job_template_name 필드를 다음 예에 표시된 workflow_template_name 로 바꿉니다.

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 워크플로에 대한 자세한 내용은 워크플로를 참조하십시오.

구독할 때 리소스 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 에 의해 배포된 리소스는 자동으로 조정 되지 않습니다.

LeaderElection 을 구성하려면 다음 기본값을 변경합니다.

multicluster-operators-application,multicluster-operators-channel,multicluster-operators-standalone-subscription 또는 multicluster-operators-hub-subscription 컨트롤러를 변경하려면 다음 단계를 참조하십시오.

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

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

개발 환경에서 다음 연결 방법을 사용하여 사용자 정의 또는 자체 서명된 인증 기관에서 서명한 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

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

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

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

네임스페이스 범위가 지정된 리소스를 조사하도록 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"

관리 클러스터를 GitOps에 등록하려면 다음 단계를 완료합니다.

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

푸시 및 Pull 모델의 경우 hub 클러스터의 Argo CD ApplicationSet 컨트롤러가 조정되어 각 대상 관리 클러스터에 대한 애플리케이션 리소스를 생성합니다. 두 모델의 아키텍처에 대한 다음 정보를 참조하십시오.

Argo CD Pull 모델을 사용하려면 다음 사전 요구 사항을 참조하십시오.

Argo CD ApplicationSet 리소스는 관리 클러스터 목록을 가져오는 데 사용되는 generator 필드에서 Push 또는 Pull 모델을 사용하여 관리 클러스터에 애플리케이션을 배포하는 데 사용됩니다.

다음은 guestbook 애플리케이션의 MulticlusterApplicationSetReport YAML 파일의 예입니다.

apiVersion: apps.open-cluster-management.io/v1alpha1
kind: MulticlusterApplicationSetReport
metadata:
  labels:
    apps.open-cluster-management.io/hosting-applicationset: openshift-gitops.guestbook-allclusters-app-set
  name: guestbook-allclusters-app-set
  namespace: openshift-gitops
statuses:
  clusterConditions:
  - cluster: cluster1
    conditions:
    - message: 'Failed sync attempt: one or more objects failed to apply, reason: services is forbidden: User "system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller" cannot create resource "services" in API group "" in the namespace "guestbook",deployments.apps is forbidden: User <name> cannot create resource "deployments" in API group "apps" in the namespace "guestboo...'
      type: SyncError
    healthStatus: Missing
    syncStatus: OutOfSync
  - cluster: pcluster1
    healthStatus: Progressing
    syncStatus: Synced
  - cluster: pcluster2
    healthStatus: Progressing
    syncStatus: Synced
  summary:
    clusters: "3"
    healthy: "0"
    inProgress: "2"
    notHealthy: "3"
    notSynced: "1"
    synced: "2"

참고: 리소스를 배포하지 못하면 리소스가 리소스 목록에 포함되지 않습니다. 자세한 내용은 오류 메시지를 참조하십시오.

배포할 수 있는 애플리케이션 샘플은 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 리포지터리를 채널로 추상화합니다.

사용 중단 알림: 채널 ConfigMap 참조에 insecureSkipVerify: "true" 를 지정하여 Helm 리포지터리 SSL 인증서를 건너뛰는 것은 더 이상 사용되지 않습니다. 대신 채널에서 사용되는 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: Placement
  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: Placement
      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: 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"

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: Placement
          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