アプリケーション

チャネル (channel.apps.open-cluster-management.io) は、クラスターがサブスクリプションを使用してサブスクライブ可能なソースリポジトリーを定義します。許容タイプは、Git、Helm リリース、オブジェクトストレージリポジトリー、ハブクラスター上にあるリソーステンプレートです。

認可が必要なチャネルから Kubernetes リソースまたは Helm チャートを必要とするアプリケーション (例: エンタイトルメントのある Git リポジトリー) がある場合は、これらのチャネルにアクセスできるようにするシークレットを使用できます。お使いのサブスクリプションで、データセキュリティーを確保しつつも、これらのチャネルからデプロイメント用の Kubernetes リソースおよび Helm チャートにアクセスできます。

チャネルは、ハブクラスター内の namespace を使用して、リソースをデプロイメント用に保存する、物理的な場所を参照します。クラスターは、チャネルにサブスクライブすることで、クラスターごとにデプロイするリソースを特定できます。

注記: 一意の namespace に各チャネルを作成することを推奨します。ただし、Git チャネルは、Git、Helm、オブジェクトストレージなどの別のチャネルタイプで namespace を共有できます。

チャネル内のリソースには、そのチャネルにサブスクライブするクラスターのみがアクセスできます。

配置ルール (placementrule.apps.open-cluster-management.io) は、リソーステンプレートをデプロイ可能なターゲットクラスターを定義します。配置ルールを使用すると、deployable のマルチクラスターでのデプロイメントが容易になります。配置ルールは、ガバナンスポリシーおよびリスクポリシーにも使用されます。使用方法の詳細は、ガバナンス を参照してください。

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 アノテーションを使用してデプロイされたままのリソースは、namespace にバインドされます。そのため、残りのリソースを削除するまで namespace を削除することはできません。

以下のチャネル定義例では 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 は、サブスクリプションを削除した後、特定のデプロイされたリソースを保持するためのアノテーションを提供します。詳細については、Tell Helm Not To 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

以下の YAML の例で kind: PlacementRule および kind: Subscription added と表示されているため、引き続き他の 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

オブジェクトストレージリポジトリーを使用してサブスクリプションを作成する場合、do-not-delete アノテーションを追加して、サブスクリプションを削除した後も特定のデプロイ済みリソースを保持できます。do-not-delete アノテーションは、最上位のデプロイリソースでのみ機能します。do-not-delete アノテーションを追加するには、次の手順を実行します。

サブスクリプションを削除した後、do-not-delete アノテーションを持つリソースは引き続き存在しますが、他のリソースは削除されます。

注記: do-not-delete アノテーションを使用してデプロイされたままのリソースは、namespace にバインドされます。そのため、残りのリソースを削除するまで namespace を削除することはできません。

アプリケーションサブスクリプションコントローラーは、プリフックフォルダー内のすべての kind:AnsibleJob CR をプリフックの AnsibleJob オブジェクトとして検索し、新しいプリフックの AnsibleJob インスタンスを生成します。新しいインスタンス名はプリフックの AnsibleJob オブジェクト名とランダムな接尾辞文字列です。

インスタンス名の例 database-sync-1-2913063 を参照してください。

アプリケーションサブスクリプションコントローラーは、調整要求を 1 分間のループで再度キューに追加します。プリフックの AnsibleJob status.AnsibleJobResult をチェックします。プリフックステータスが successful の場合、アプリケーションサブスクリプションは主要なサブスクリプションを引き続きデプロイします。

アプリケーションのサブスクリプションステータスが更新されると、サブスクリプションのステータスが Subscribed か、ステータスが Subscribed の全ターゲットクラスターに伝播された場合に、アプリケーションのサブスクリプションコントローラーは posthook AnsibleJob オブジェクトとして、posthook フォルダーの全 AnsibleJob kind CR を検索します。次に、posthook AnsibleJob インスタンスを新たに生成します。新しいインスタンス名には、posthook AnsibleJob のオブジェクト名、その後に無作為に指定した接尾辞の文字列を指定します。

インスタンス名の例 service-ticket-1-2913849 を参照してください。

有効なプリフックの AnsibleJob では、サブスクリプションは配置ルールの決定事項に関係なく、プリフックの AnsibleJob を起動します。

たとえば、配置ルールサブスクリプションの伝播に失敗したプリフックの AnsibleJob を起動できます。配置ルールの意思決定が変更すると、新しいプリフックおよびポストフックの AnsibleJob インスタンスが作成されます。

{aap_short} を有効にするには、次のトピックを参照してください。

その後、コンソールの Credentials ページから認証情報を作成できます。Add credential をクリックするか、ナビゲーションからページにアクセスします。認証情報については、Ansible Automation Platform の認証情報の作成 を参照してください。

Ansible Automation Platform シークレットカスタムリソースを同じサブスクリプション namespace に作成する必要があります。Ansible Automation Platform シークレットは、同じサブスクリプション namespace に制限されています。

アプリケーションサブスクリプションコントローラーがプリフックおよびポストフックの Ansible ジョブを作成する際、サブスクリプション spec.hooksecretref からのシークレットが利用可能な場合、それは AnsibleJob カスタムリソース spec.tower_auth_secret に送信され、AnsibleJob は Ansible Automation Platform にアクセスできます。

プリフックおよびポストフックの AnsibleJob を使用するメインのサブサブスクリプションの場合、すべてのプリフックおよびポストフックの AnsibleJob またはメインのサブスクリプションが Git リポジトリーで更新された後、メイン/サブのサブスクリプションを調整する必要があります。

プリフックの AnsibleJob とメインのサブスクリプションは新しいプリフックの AnsibleJob インスタンスを継続的に調整および再起動します。

AnsibleJob カスタムリソースが作成されると、ターゲットの Ansible Automation Platform と通信することによって、Ansible Automation Platform ジョブを起動するために、Kubernetes ジョブのカスタムリソースが作成されます。ジョブが完了すると、ジョブの最終ステータスが AnsibleJob status.AnsibleJob Result に戻ります。

注記:

AnsibleJob status.conditions は、Kubernetes ジョブの結果の作成を保存するために、Ansible Automation Platform Job Operator によって予約されています。status.conditions は実際の Ansible Automation Platform ジョブのステータスを反映していません。

サブスクリプションコントローラーは、AnsibleJob.status.conditions ではなく、AnsibleJob.status.AnsibleJob.Result によって、Ansible Automation Platform ジョブのステータスをチェックします。

プリフックおよびポストフックの AnsibleJob ワークフローで前述したように、メインのサブスクリプションが Git リポジトリーで更新されると、新しいプリフックおよびポストフックの AnsibleJob インスタンスが作成されます。その結果、1 つのメインサブスクリプションが複数の AnsibleJob インスタンスにリンクできます。

subscription.status.ansiblejobs には、4 つのフィールドが定義されています。

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 および posthook フォルダー内の Workflow 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 is not supported が表示されます。

以下の例にあるように、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 を置き換えます。data 仕様の変更を参照してください。

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) を選択できるようになりました。これにより、サブスクリプション Operator のオーバーロードを防ぐことができます。

必要なアクセス: 管理者およびクラスター管理者である必要があります。

settings:attribute:<value> に関する以下の定義を参照してください。

これは、サブスクリプションによって参照されるチャネルカスタムリソースの apps.open-cluster-management.io/reconcile-rate アノテーションを使用して設定できます。

name: 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 を使用するすべてのサブスクリプションの調整頻度は low に割り当てられます。

チャネルの reconcile-rate 設定に関係なく、サブスクリプションは、Subscription カスタムリソースの apps.open-cluster-management.io/reconcile-rate: off アノテーションを指定して、自動調整を off に設定できます。

以下の git-channel の例を参照してください。

apiVersion: apps.open-cluster-management.io/v1
kind: Channel
metadata:
  name: git-channel
  namespace: sample
  annotations:
    apps.open-cluster-management.io/reconcile-rate: high
spec:
  type: GitHub
  pathname: <Git URL>
---
apiVersion: apps.open-cluster-management.io/v1
kind: Subscription
metadata:
  name: git-subscription
  annotations:
    apps.open-cluster-management.io/git-path: application1
    apps.open-cluster-management.io/git-branch: branch1
    apps.open-cluster-management.io/reconcile-rate: "off"
spec:
  channel: sample/git-channel
  placement:
    local: true

チャネルで reconcile-rate が high に設定されている場合でも、git-subscription によってデプロイされたリソースが自動調整されないことを確認します。

サブスクリプション Operator は 15 分ごとに、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 を使用するすべてのサブスクリプションの調整頻度は low になります。

チャネルの reconcile-rate 設定に関係なく、サブスクリプションは、Subscription カスタムリソースの apps.open-cluster-management.io/reconcile-rate: off アノテーションを指定して、自動調整を 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

この例では、チャネルで reconcile-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 フラグは前述のデフォルト時間を 2 倍にして、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 キーなどの更新が必要な場合は、同じ namespace に新規のシークレットおよび ConfigMap を作成し、そのチャネルを更新して新規のシークレットおよび ConfigMap を参照する必要があります。詳細は、セキュアな HTTPS 接続でのカスタム CA 証明書の使用 を参照してください。

必要なアクセス権限: クラスターの管理者

namespace スコープのリソースを監視するように 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 に登録するには、次の手順を実行します。

配置および ManagedClusterSetBinding カスタムリソースを使用して GitOps namespace にバインドされているすべてのマネージドクラスターの GitOps Operator と統合すると、ManagedCluster にアクセスするためのトークンが含まれるシークレットがその namespace に作成されます。これは、GitOps コントローラーがリソースをマネージドクラスターと同期するために必要です。ユーザーに GitOps namespace への管理者アクセス権が付与され、アプリケーションのライフサイクル操作を実行すると、ユーザーはこのシークレットへのアクセス権と、マネージドクラスターへの admin レベルのアクセス権が付与されます。

これが望ましくない場合は、ユーザーをこの namespace の範囲の 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

Push および Pull モデルの両方で、ハブクラスター上の Argo CD ApplicationSet コントローラー が調整して、ターゲットのマネージドクラスターごとにアプリケーションリソースを作成します。両方のモデルのアーキテクチャーに関する以下の情報を参照してください。

Argo CD Pull モデルを使用するには、以下の前提条件を確認してください。

Argo CD ApplicationSet リソースは、マネージドクラスターのリストを取得するために使用されるジェネレーターフィールド内の placement リソースを含むプッシュまたはプルモデルを使用して、マネージドクラスターにアプリケーションをデプロイするために使用されます。

以下は、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"

Note: リソースがデプロイに失敗した場合、リソースはリソース一覧に含まれません。詳細は、エラーメッセージを参照してください。

デプロイできるアプリケーションサンプルについては、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/

以下のチャネル定義例では、オブジェクトストレージバケットをチャネルとして抽象化します。

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.8 では、チャネルの 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 の場合は、アプリケーショントポロジーが正しく表示されるように、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 は、pathname で指定されている 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 Special Interest Group (SIG) が提供するアプリケーションメタデータ記述子のカスタムリソース定義が基になっています。テーブルに表示される値のみが必要です。

この定義を使用すると、独自のアプリケーションの YAML コンテンツ作成に役立ちます。この定義の詳細は、Kubernetes SIG Application CRD community specification を参照してください。

デプロイできるアプリケーションサンプルについては、stolostron リポジトリーを参照してください。

アプリケーションの定義構造は、以下の YAML コンテンツの例のようになります。

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