Red Hat Summit Red Hat Summitサポートコンソール開発者トライアルの開始お問い合わせ

1.6. アプリケーションの詳細設定

Red Hat Advanced Cluster Management for Kubernetes では、アプリケーションは複数のアプリケーションリソースで設定されています。チャネル、サブスクリプション、配置、および配置ルールリソースを使用すると、アプリケーション全体のデプロイ、更新、および管理に役立ちます。

単一クラスターアプリケーションもマルチクラスターアプリケーションも同じ Kubernetes 仕様を使用しますが、マルチクラスターアプリケーションでは、デプロイメントおよびアプリケーション管理ライフサイクルがさらに自動化されます。

Red Hat Advanced Cluster Management for Kubernetes アプリケーションのアプリケーションコンポーネントリソースはすべて、YAML ファイルの仕様セクションで定義します。アプリケーションコンポーネントリソースを作成または更新する必要がある場合は、適切な仕様セクションを作成してリソースを定義するラベルを追加する必要があります。

以下のアプリケーション詳細設定のトピックを確認してください。

1.6.1. Git リソースのサブスクライブ
リンクのコピー

デフォルトでは、サブスクリプションを使用してサブスクライプされているアプリケーションをターゲットクラスターにデプロイすると、アプリケーションリソースが別の namespace に関連付けられている場合でも、このアプリケーションはこのサブスクリプション namespace にデプロイされます。サブスクリプションの管理権限の付与 で説明されているように、サブスクリプション管理者 はデフォルトの動作を変更できます。

また、アプリケーションリソースがクラスターに存在しており、サブスクリプションを使用して作成されていない場合、このサブスクリプションではその既存リソースに対して新しいリソースを適用できません。サブスクリプション管理者としてデフォルト設定を変更するには、以下のプロセスを参照してください。

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

1.6.1.1. Git でのアプリケーションリソースの作成
リンクのコピー

サブスクライブ時に、リソース 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'
Copy to Clipboard Toggle word wrap

次に、サブスクリプション管理者がデフォルト動作を変更する有用な例を確認します。

1.6.1.2. アプリケーション namespace の例
リンクのコピー

以下の例では、サブスクリプション管理者としてログインします。

1.6.1.2.1. アプリケーションと異なる namespace
リンクのコピー

サブスクリプションを作成して、サンプルのリソース YAML ファイルを Git リポジトリーからサブスクライブします。このサンプルファイルには、以下の異なる namespace にあるサブスクリプションが含まれます。

適用可能なチャネルタイプ: Git

  • ConfigMap test-configmap-1 は multins namespace に作成されます。
  • ConfigMap test-configmap-2 は default namespace に作成されます。

  • ConfigMap test-configmap-3 は subscription namespace に作成されます。 

    ---
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
    Copy to Clipboard Toggle word wrap

他のユーザーがサブスクリプションを作成した場合は、ConfigMap がすべて、サブスクリプションと同じ namespace に作成されます。

1.6.1.2.2. 同じ namespace へのアプリケーション
リンクのコピー

サブスクリプション管理者は、すべてのアプリケーションリソースを同じ namespace にデプロイする必要がある場合があります。

サブスクリプション管理者として許可リストと拒否リストを作成する ことにより、すべてのアプリケーションリソースをサブスクリプション namespace にデプロイできます。

apps.open-cluster-management.io/current-namespace-scoped: true アノテーションをサブスクリプション YAML に追加します。たとえば、サブスクリプション管理者が以下のサブスクリプションを作成すると、直前の例の 3 つの ConfigMap すべてが subscription-ns namespace に作成されます。 

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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

Git リポジトリーから、以下のリソース YAML ファイル例をサブスクライブして、既存の ConfigMap を置き換えます。data 仕様の変更を参照してください。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  age: 20
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、以下の例のように既存の ConfigMap をマージします。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  name: user1
  age: 20
Copy to Clipboard Toggle word wrap

merge オプションを使用すると、サブスクライブしているリソースのエントリーが、既存のリソースで作成または更新されます。既存のリソースからエントリーは削除されません。

重要: サブスクリプションで上書きする既存のリソースが自動的に別の Operator またはコントローラーで調整されると、リソース設定はサブスクリプションとコントローラーの両方、または Operator により更新されます。このような場合は、この方法を使用しないでください。

1.6.1.3.2. mergeAndOwn オプション
リンクのコピー

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
Copy to Clipboard Toggle word wrap

サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで 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
Copy to Clipboard Toggle word wrap

前述のように、mergeAndOwn オプションを使用すると、サブスクライブしているリソースのエントリーが既存のリソースで作成または更新されます。既存のリソースからエントリーは削除されません。また、apps.open-cluster-management.io/hosting-subscription アノテーションを追加して、リソースがサブスクリプションによって所有されていることを示します。サブスクリプションを削除すると、ConfigMap が削除されます。

1.6.1.3.3. replace オプション
リンクのコピー

サブスクリプション管理者としてログインして、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
Copy to Clipboard Toggle word wrap

サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、既存の ConfigMap を以下に置き換えます。 

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  age: 20
Copy to Clipboard Toggle word wrap

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>
Copy to Clipboard Toggle word wrap
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
Copy to Clipboard Toggle word wrap

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
Copy to Clipboard Toggle word wrap

注記: Git のコミットとタグアノテーションの両方が指定された場合は、タグが無視されます。

git-clone-depth アノテーションは任意で、デフォルトでは 20 に設定されます。この値は、サブスクリプションコントローラーが Git リポジトリーから最新のコミット履歴 20 回分を取得するという意味です。随分前の git-tag を指定する場合は、必要なタグのコミットに合った git-clone-depth を指定する必要があります。

1.6.2. サブスクリプション管理者権限の付与
リンクのコピー

サブスクリプションの管理者権限を付与する方法を説明します。サブスクリプション 管理者は、デフォルトの動作を変更できます。詳細は、以下のプロセスを参照してください。

  1. コンソールから OpenShift Container Platform クラスターにログインします。

  2. ユーザーを 1 つ以上作成します。ユーザー作成に関する詳細は、ユーザー向けの準備 を参照してください。グループまたはサービスアカウントを用意することもできます。

    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
    Copy to Clipboard Toggle word wrap

  5. 以下のコマンドで、次のサブジェクトを open-cluster-management:subscription-admin ClusterRoleBinding に追加します。 

    oc edit clusterrolebinding open-cluster-management:subscription-admin
    Copy to Clipboard Toggle word wrap

    注記: 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'
    Copy to Clipboard Toggle word wrap

Service Account は、ユーザーサブジェクトとして使用できます。

1.6.3. サブスクリプション管理者としての許可リストの作成および拒否リストの作成
リンクのコピー

サブスクリプション管理者は、Git リポジトリーアプリケーションのサブスクリプションからアプリケーションを作成し、allow リストを使用して、指定された Kubernetes kind リソースのみのデプロイメントを可能にします。アプリケーションサブスクリプションに deny list を作成して、特定の Kubernetes kind リソースのデプロイメントを拒否することもできます。

デフォルトでは、policy.open-cluster-management.io/v1 リソースはアプリケーションサブスクリプションによってデプロイされません。このデフォルトの動作を回避するには、サブスクリプション管理者がアプリケーションサブスクリプションをデプロイする必要があります。

以下の allow および deny 仕様の例を参照してください。 

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
Copy to Clipboard Toggle word wrap

以下のアプリケーションサブスクリプション 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
Copy to Clipboard Toggle word wrap

このアプリケーションのサブスクリプション YAML は、v1/Service および v1/ConfigMap リソース以外のすべての有効なリソースのデプロイを指定します。API グループ内に個別のリソースの種類をリスト表示する代わりに、"*" を追加して、API グループのすべてのリソースの種類を許可または拒否できます。

1.6.4. 調整オプションの追加
リンクのコピー

個々のリソースで apps.open-cluster-management.io/reconcile-option アノテーションを使用して、サブスクリプションレベルの調整オプションを上書きできます。

たとえば、apps.open-cluster-management.io/reconcile-option: replace アノテーションをサブスクリプションに追加し、サブスクライブされた Git リポジトリーのリソース YAML に apps.open-cluster-management.io/reconcile-option: merge アノテーションを追加すると、そのリソースはターゲットクラスターにマージされます。その他のリソースは置き換えられます。

1.6.4.1. 調整頻度の Git チャネル
リンクのコピー

チャネル設定で、不要なリソースの調整を回避するために調整頻度オプション (high、medium、low、および off) を選択できるようになりました。これにより、サブスクリプション Operator のオーバーロードを防ぐことができます。

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

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

  • Off: デプロイされたリソースは自動的に調整されません。Subscription カスタムリソースを変更すると、調整がトリガーされます。ラベルまたはアノテーションを追加または更新できます。
  • Low: ソースの Git リポジトリーに変更がない場合でも、デプロイされたリソースは 1 時間ごとに自動調整されます。
  • Medium: これはデフォルトの設定です。サブスクリプション Operator は、3 分ごとに現在デプロイされているコミット ID をソースリポジトリーの最新コミット ID と比較し、ターゲットクラスターに変更を適用します。リポジトリーに変更がない場合でも、すべてのリソースは 15 分ごとにソース Git リポジトリーからターゲットクラスターに再適用されます。
  • High: ソースの Git リポジトリーに変更がない場合でも、デプロイされたリソースは 2 分ごとに自動調整されます。

これは、サブスクリプションによって参照されるチャネルカスタムリソースの 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
Copy to Clipboard Toggle word wrap

上記の例では、sample/git-channel を使用するすべてのサブスクリプションの調整頻度は low に割り当てられます。

  1. サブスクリプションの調整速度を low に設定すると、サブスクライブしているアプリケーションリソースの調整に最大 1 時間かかる場合があります。単一アプリケーションビューのカードで、Sync をクリックして手動で調整します。off に設定すると、調整はありません。

チャネルの 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
Copy to Clipboard Toggle word wrap

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

1.6.4.2. Helm チャネルの調整頻度
リンクのコピー

サブスクリプション Operator は 15 分ごとに、Helm チャートで現在デプロイされているハッシュを、ソースリポジトリーからのハッシュと比較します。変更がターゲットクラスターに適用されます。リソース調整の頻度は、他のアプリケーションのデプロイメントおよび更新のパフォーマンスに影響します。

たとえば、数百のアプリケーションサブスクリプションがあり、すべてのサブスクリプションを頻繁に調整する場合は、調整の応答時間は遅くなります。

アプリケーションの Kubernetes リソースによっては、適切な調整頻度でパフォーマンスを向上できます。

  • Off: デプロイされたリソースは自動的に調整されません。サブスクリプションカスタムリソースを変更すると、調整がトリガーされます。ラベルまたはアノテーションを追加または更新できます。
  • Low: サブスクリプション Operator は、1 時間ごとに現在デプロイされているハッシュと、ソースリポジトリーのハッシュと比較し、変更がある場合はターゲットクラスターに変更を適用します。
  • Medium: これはデフォルトの設定です。サブスクリプション Operator は、15 分ごとに現在デプロイされているハッシュと、ソースリポジトリーのハッシュと比較し、変更がある場合はターゲットクラスターに変更を適用します。
  • High: サブスクリプション 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
Copy to Clipboard Toggle word wrap

この例では、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
Copy to Clipboard Toggle word wrap

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

1.6.5. リーダー選択の設定
リンクのコピー

LeaderElection を使用すると、障害が発生した場合にコントローラーが新しいリーダーを選択するようにリクエストする方法を変更できます。これにより、一度に 1 つのリーダーインスタンスのみが調整を処理することが保証されます。コントローラーが LeaderElection を取得するのにかかる時間を増減できます。時間が短縮されると、障害時に新しいリーダーがより迅速に選択されます。

注記: コントローラーのデフォルト値を変更すると、そのタスク中のシステムパフォーマンスに影響を与える可能性があります。コントローラーの leaseDuration、renewDeadline、または retryPeriod のデフォルト値を変更することで、etcd の負荷を減らすことができます。

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

1.6.5.1. コントローラーフラグの編集
リンクのコピー

LeaderElection を設定するには、次のデフォルト値を変更します。

  • leader-election-lease-duration: 137 seconds
  • renew-deadline: 107 seconds
  • retry-period: 26 seconds

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
    Copy to Clipboard Toggle word wrap

  2. コントローラー名を oc edit コマンドに追加して、deployment ファイルを編集します。次のコマンド例を参照してください。 

    oc edit deployment -n open-cluster-management multicluster-operators-hub-subscription
    Copy to Clipboard Toggle word wrap
  3. -command を検索して、コントローラーコマンドフラグを見つけます。
  4. コントローラーのコンテナーセクションから、-command フラグを挿入します。たとえば、RetryPeriod を挿入します。
  5. ファイルを保存します。コントローラーは自動的に再起動してフラグを適用します。
  6. 変更するコントローラーごとに、この手順を繰り返します。
  7. 次のコマンドを実行して、multiclusterhub を再開します。 
oc annotate mch -n open-cluster-management multiclusterhub mch-pause=false --overwrite=true
Copy to Clipboard Toggle word wrap

-command の編集が成功した場合の次の出力例を参照してください。ここで、retryPeriod フラグは前述のデフォルト時間を 2 倍にして、52 にします。この値は leaderElection の取得を再試行するために割り当てられます。 

command:
- /usr/local/bin/multicluster-operators-subscription
- --sync-interval=60
- --retry-period=52
Copy to Clipboard Toggle word wrap

1.6.6. セキュアな Git 接続用のアプリケーションチャネルおよびサブスクリプションの設定
リンクのコピー

Git チャネルおよびサブスクリプションは、HTTPS または SSH を使用して指定された Git リポジトリーに接続します。以下のアプリケーションチャネル設定は、セキュアな Git 接続に使用できます。

1.6.6.1. ユーザーおよびアクセストークンを使用したプライベートリポジトリーへの接続
リンクのコピー

チャネルおよびサブスクリプションを使用して Git サーバーに接続できます。ユーザーおよびアクセストークンを使用してプライベートリポジトリーに接続するには、以下の手順を参照してください。

  1. チャネルと同じ namespace にシークレットを作成します。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
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

1.6.6.2. Git サーバーへのセキュアではない HTTPS 接続の設定
リンクのコピー

開発環境で以下の接続方法を使用し、カスタム署名または自己署名の認証局による SSL 証明書を使用して、プライベートにホストされている Git サーバーに接続できます。ただし、このソリューションは実稼働では推奨されません。

チャネルの仕様で insecureSkipVerify: true を指定します。それ以外の場合は、Git サーバーへの接続が失敗し、以下のようなエラーが表示されます。 

x509: certificate is valid for localhost.com, not localhost
Copy to Clipboard Toggle word wrap

この方法のチャネル仕様が追加された以下の例を参照してください。 

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
Copy to Clipboard Toggle word wrap

1.6.6.3. セキュアな HTTPS 接続でのカスタム CA 証明書の使用
リンクのコピー

この接続方法を使用し、カスタム署名または自己署名の認証局による SSL 証明書を使用して、プライベートにホストされている Git サーバーに安全に接続できます。

  1. Git サーバーの root および中間 CA 証明書を PEM 形式で含む ConfigMap を作成します。ConfigMap はチャネル CR と同じ namespace にある必要があります。フィールド名は caCerts で、| を使用する必要があります。以下の例で、caCerts には root や中間 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-----
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

1.6.6.4. Git サーバーへの SSH 接続の設定
リンクのコピー

  1. data の sshKey フィールドに SSH 秘密キーを追加するシークレットを作成します。キーがパスフレーズで保護されている場合は、passphrase フィールドにパスワードを指定します。このシークレットは、チャネル CR と同じ namespace にある必要があります。oc コマンドを使用してこのシークレットを作成し、generic のシークレット git-ssh-key --from-file=sshKey=./.ssh/id_rsa を作成してから、base64 でエンコードされた passphrase を追加します。以下のサンプルを参照してください。 

    apiVersion: v1
kind: Secret
metadata:
  name: git-ssh-key
  namespace: channel-ns
data:
  sshKey: LS0tLS1CRUdJTiBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0KYjNCbGJuTnphQzFyWlhrdGRqRUFBQUFBQ21GbGN6STFOaTFqZEhJQUFBQUdZbU55ZVhCMEFBQUFHQUFBQUJDK3YySHhWSIwCm8zejh1endzV3NWODMvSFVkOEtGeVBmWk5OeE5TQUgcFA3Yk1yR2tlRFFPd3J6MGIKOUlRM0tKVXQzWEE0Zmd6NVlrVFVhcTJsZWxxVk1HcXI2WHF2UVJ5Mkc0NkRlRVlYUGpabVZMcGVuaGtRYU5HYmpaMmZOdQpWUGpiOVhZRmd4bTNnYUpJU3BNeTFLWjQ5MzJvOFByaDZEdzRYVUF1a28wZGdBaDdndVpPaE53b0pVYnNmYlZRc0xMS1RrCnQwblZ1anRvd2NEVGx4TlpIUjcwbGVUSHdGQTYwekM0elpMNkRPc3RMYjV2LzZhMjFHRlMwVmVXQ3YvMlpMOE1sbjVUZWwKSytoUWtxRnJBL3BUc1ozVXNjSG1GUi9PV25FPQotLS0tLUVORCBPUEVOU1NIIFBSSVZBVEUgS0VZLS0tLS0K
  passphrase: cGFzc3cwcmQK
type: Opaque
    Copy to Clipboard Toggle word wrap

  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
    Copy to Clipboard Toggle word wrap

    サブスクリプションコントローラーは、提供される 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
    Copy to Clipboard Toggle word wrap

1.6.6.5. 証明書および SSH キーの更新
リンクのコピー

Git チャネル接続設定で CA 証明書、認証情報、または SSH キーなどの更新が必要な場合は、同じ namespace に新規のシークレットおよび ConfigMap を作成し、そのチャネルを更新して新規のシークレットおよび ConfigMap を参照する必要があります。詳細は、セキュアな HTTPS 接続でのカスタム CA 証明書の使用 を参照してください。

1.6.7. namespace リソースを監視するように Helm を設定する
リンクのコピー

デフォルトでは、サブスクリプションがサブスクライブされた Helm リソースをターゲットクラスターにデプロイするときに、アプリケーションリソースが監視されます。namespace スコープのリソースを監視するように Helm チャネルタイプを設定できます。有効にすると、監視対象の namespace スコープのリソースに対する手動の変更が元に戻されます。

1.6.7.1. 設定
リンクのコピー

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

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"
Copy to Clipboard Toggle word wrap

GitOps を設定するには、1 つ以上の Red Hat Advanced Cluster Management for Kubernetes マネージドクラスターのセットを Red Hat OpenShift Container Platform GitOps Operator のインスタンスに登録できます。登録後、アプリケーションをこれらのクラスターにデプロイできます。継続的な GitOps 環境を設定して、開発環境、ステージング、および実稼働環境のクラスター全体でアプリケーションの整合性を自動化します。

1.6.8.1. 前提条件
リンクのコピー

  1. Red Hat Advanced Cluster Management for Kubernetes に Red Hat OpenShift GitOps Operator をインストールする必要がある。
  2. 1 つ以上のマネージドクラスターをインポートする。

1.6.8.2. マネージドクラスターの GitOps への登録
リンクのコピー

マネージドクラスターを GitOps に登録するには、次の手順を実行します。

  1. マネージドクラスターセットを作成し、マネージドクラスターをこれらのマネージドクラスターセットに追加します。multicloud-integrations managedclusterset のマネージドクラスターセットの例を参照してください。

    詳細は、ManagedClusterSet の作成 ドキュメントを参照してください。

  2. Red Hat OpenShift GitOps がデプロイされている namespace にバインドするマネージドクラスターセットを作成します。マネージドクラスターを openshift-gitops namespace にバインドする例は、multicloud-integrations マネージドクラスターセットバインディングの例を参照してください。ManagedClusterSetBinding の作成に関する一般的な情報は、追加リソース セクションの ManagedClusterSetBinding リソースの作成 を参照してください。配置の詳細は、ManagedClusterSets からの ManagedClusters のフィルタリング を参照してください。

  3. マネージドクラスターセットバインディングで使用される namespace で、Placement カスタムリソースを作成し、OpenShift Container Platform GitOps Operator インスタンスに登録するマネージドクラスターのセットを選択します。multicloud-integration 配置例をテンプレートとして使用します。配置情報は、配置での ManagedClusterSets の使用 を参照してください。

    注記:

    • 他の Kubernetes クラスターではなく、Red Hat OpenShift Container Platform GitOps Operator インスタンスに登録されるのは、OpenShift Container Platform クラスターのみです。
    • 一部の不安定なネットワークシナリオでは、マネージドクラスターが一時的に使用 unavailable または unreachable 状態になることがあります。詳細は、Red Hat Advanced Cluster Management および OpenShift GitOps の配置許容範囲の設定 を参照してください。

  4. GitOpsCluster カスタムリソースを作成し、配置決定から OpenShift GitOps の指定されたインスタンスにマネージドクラスターのセットを登録します。これにより、OpenShift GitOps インスタンスは、これらの Red Hat Advanced Cluster Management マネージドクラスターのいずれかにアプリケーションをデプロイできます。multicloud-integrations GitOps クラスターの例を使用します。

    注記: 参照される Placement リソースは、GitOpsCluster リソースと同じ namespace に配置されている必要があります。以下の例を参照してください。 

    apiVersion: apps.open-cluster-management.io/v1beta1
kind: GitOpsCluster
metadata:
  name: gitops-cluster-sample
  namespace: dev
spec:
  argoServer:
    cluster: local-cluster
    argoNamespace: openshift-gitops
  placementRef:
    kind: Placement
    apiVersion: cluster.open-cluster-management.io/v1beta1
    name: all-openshift-clusters
    1
    Copy to Clipboard Toggle word wrap
    1
    placementRef.name の値は all-openshift-clusters で、argoNamespace: openshift-gitops にインストールされている GitOps インスタンスのターゲットクラスターとして指定されます。argoServer.cluster 仕様には local-cluster の値が必要です。
  5. 変更を保存します。次に、GitOps ワークフローに従って、アプリケーションを管理できます。

1.6.8.3. 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
Copy to Clipboard Toggle word wrap

1.6.8.4. 関連情報
リンクのコピー

1.6.9. Red Hat Advanced Cluster Management および OpenShift GitOps のアプリケーション配置許容の設定
リンクのコピー

Red Hat Advanced Cluster Management は、アプリケーションを Red Hat OpenShift GitOps にデプロイするマネージドクラスターを登録する方法を提供します。

一部の不安定なネットワークシナリオでは、マネージドクラスターが一時的に使用 Unavailable 状態になることがあります。アプリケーションのデプロイを容易にするために Placement リソースが使用されている場合は、使用できないクラスターを引き続き含めるために、Placement リソースに次の許容範囲を追加します。次の例は、許容範囲を含む Placement リソースを示しています。 

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: Placement
metadata:
  name: placement
  namespace: ns1
spec:
  tolerations:
    - key: cluster.open-cluster-management.io/unreachable
      operator: Exists
    - key: cluster.open-cluster-management.io/unavailable
      operator: Exists
Copy to Clipboard Toggle word wrap

1.6.9.1. 関連情報
リンクのコピー

1.6.10. プッシュアンドプルモデルを使用した Argo CD の導入
リンクのコピー

Push モデル 使用して、ハブクラスター上の Argo CD サーバーは、マネージドクラスターにアプリケーションリソースをデプロイします。Pull モデル の場合、アプリケーションリソースは manifestWork を使用して Propagation controller によってマネージドクラスターに伝播されます。

テクノロジープレビュー: プルモデルはテクノロジープレビューステータスにあり、このリリースではサポートが制限されています。

どちらのモデルでも、同じ ApplicationSet CRD を使用してアプリケーションをマネージドクラスターにデプロイします。

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

重要: openshift-gitops-ArgoCD-application-controller サービスアカウントがクラスター管理者として割り当てられてい ない 場合、GitOps アプリケーションコントローラーはリソースをデプロイしない可能性があります。アプリケーションのステータスによって、次のようなエラーが送信される場合があります。 

cannot create resource "services" in API group "" in the namespace
"mortgage",deployments.apps is forbidden: User
"system:serviceaccount:openshift-gitops:openshift-gitops-Argo CD-application-controller"
Copy to Clipboard Toggle word wrap

クラスター管理者ではなく、この問題を解決する必要がある場合は、次の手順を実行してください。

  1. Argo CD アプリケーションがデプロイされる各マネージドクラスター上にすべての namespace を作成します。

  2. managed-by ラベルを各 namespace に追加します。Argo CD アプリケーションが複数の namespace にデプロイされている場合、各 namespace は Argo CD によって管理される必要があります。

    managed-by ラベルを使用した次の例を参照してください。 

    apiVersion: v1
kind: Namespace
metadata:
  name: mortgage2
  labels:
    argocd.argoproj.io/managed-by: openshift-gitops
    Copy to Clipboard Toggle word wrap
  3. すべてのアプリケーション宛先 namespace をアプリケーションのリポジトリー内で宣言し、namespace に managed ラベルを含める必要があります。namespace を宣言する方法については、Additional resources を参照してください。

1.6.10.1. Argo CD の Push および Pull モデルのアーキテクチャー
リンクのコピー

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

1.6.10.1.1. Push モデルのアーキテクチャー
リンクのコピー
  • Push モデルの実装には、マネージドクラスターの認証情報を持つハブクラスター上の Argo CD アプリケーションのみが含まれます。ハブクラスター上の Argo CD アプリケーションは、アプリケーションをマネージドクラスターにデプロイできます。
  • 重要: リソースアプリケーションを必要とする多数のマネージドクラスターでは、OpenShift Container Platform GitOps コントローラーのメモリーと CPU 使用率に負荷がかかる可能性があることを検討してください。リソース管理を最適化するには、リソースクォータまたは要求の設定 を参照してください。
  • デフォルトでは、apps.open-cluster-management.io/ocm-managed-cluster および apps.open-cluster-management.io/pull-to-ocm-managed-cluster を追加しない限り、アプリケーションのデプロイには Push モデルが使用されます。ApplicationSet のテンプレートセクションに cluster アノテーションを追加します。
1.6.10.1.2. Pull モデルのアーキテクチャー
リンクのコピー
  • Pull モデルの実装では、OpenShift Cluster Manager の登録、配置、manifestWork API が適用され、ハブクラスターがハブクラスターとマネージドクラスター間の安全な通信チャネルを使用してリソースをデプロイできるようになります。
  • Pull モデルの場合、Argo CD サーバーが各ターゲットのマネージドクラスターで実行されている必要があります。Argo CD アプリケーションリソースはマネージドクラスター上に複製され、ローカルの Argo CD サーバーによってデプロイされます。マネージドクラスター上の分散 Argo CD アプリケーションは、ハブクラスター上の単一の Argo CD ApplicationSet リソースを使用して作成されます。
  • マネージドクラスターは、ocm-managed-cluster アノテーションの値によって決定されます。
  • Pull モデルを正常に実装するには、Argo CD アプリケーションコントローラーは、ApplicationSet のテンプレートセクションにある argocd.argoproj.io/skip-reconcile アノテーションを持つプッシュモデルアプリケーションリソースを無視する必要があります。
  • Pull モデルの場合、マネージドクラスター上の Argo CD アプリケーションコントローラー が調整してアプリケーションをデプロイします。
  • ハブクラスター上の Pull モデル Resource sync controller は、各マネージドクラスター上の OpenShift Cluster Manager 検索 V2 コンポーネントに定期的にクエリーを実行し、各 Argo CD アプリケーションのリソースリストとエラーメッセージを取得します。
  • ハブクラスターの Aggregation controller はリソース同期コントローラーからのデータと、manifestWork からのステータス情報を使用して、クラスター全体から MulticlusterApplicationSetReport を作成および更新します。

1.6.10.2. 前提条件
リンクのコピー

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

  • GitOps Operator はハブクラスターに、ターゲットのマネージドクラスターを openshift-gitops namespace にインストールする必要があります。
  • 必要なハブクラスター OpenShift Container Platform GitOps operator はバージョン 1.9.0 以降である必要があります。
  • 必要なマネージドクラスター OpenShift Container Platform GitOps Operator はハブクラスターと同じバージョンである必要があります。
  • マネージドクラスターの Argo CD アプリケーションテンプレートを伝播するには、ApplicationSet コントローラー が必要です。

  • すべてのマネージドクラスターは、ハブクラスター上の Argo CD サーバー namespace にクラスターシークレットを持っている必要があります。これは、ArgoCD アプリケーションセットコントローラーがマネージドクラスターの Argo CD アプリケーションテンプレートを伝播するために必要です。

    クラスターシークレットを作成するには、placement リソースへの参照が含まれる gitOpsCluster リソースを作成します。placement リソースは、プルモデルをサポートする必要があるすべてのマネージドクラスターを選択します。GitOps クラスターコントローラーが調整すると、Argo CD サーバーの namespace にマネージドクラスターのクラスターシークレットが作成されます。

1.6.10.3. ApplicationSet カスタムリソースの作成
リンクのコピー

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

  1. プルモデルの場合、次の例に示すように、アプリケーションの宛先をデフォルトのローカル Kubernetes サーバーに設定します。アプリケーションは、マネージドクラスター上のアプリケーションコントローラーによってローカルにデプロイされます。

  2. 以下の ApplicationSet YAML の例に示されるように、デフォルトの Push モデルを上書きするために必要なアノテーションを追加します。これは、テンプレートアノテーションで Pull モデルを使用します。 

    apiVersion: argoproj.io/v1alpha1
kind: `ApplicationSet`
metadata:
  name: guestbook-allclusters-app-set
  namespace: openshift-gitops
spec:
  generators:
  - clusterDecisionResource:
      configMapRef: ocm-placement-generator
      labelSelector:
        matchLabels:
          cluster.open-cluster-management.io/placement: aws-app-placement
      requeueAfterSeconds: 30
  template:
    metadata:
      annotations:
        apps.open-cluster-management.io/ocm-managed-cluster: '{{name}}'
    1 
    
        apps.open-cluster-management.io/ocm-managed-cluster-app-namespace: openshift-gitops
        argocd.argoproj.io/skip-reconcile: "true"
    2 
    
      labels:
        apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true"
    3 
    
      name: '{{name}}-guestbook-app'
    spec:
      destination:
        namespace: guestbook
        server: https://kubernetes.default.svc
      project: default
      source:
        path: guestbook
        repoURL: https://github.com/argoproj/argocd-example-apps.git
      syncPolicy:
        automated: {}
        syncOptions:
        - CreateNamespace=true
    Copy to Clipboard Toggle word wrap
    1
    Pull モデルには apps.open-cluster-management.io/ocm-managed-cluster が必要です。
    2
    Push モデルリソースを無視するには、argocd.argoproj.io/skip-reconcile が必要です。
    3
    apps.open-cluster-management.io/pull-to-ocm-managed-cluster: "true" も Pull モデルに必要です。

1.6.10.4. MulticlusterApplicationSetReport
リンクのコピー

  • Pull モデルの場合、MulticlusterApplicationSetReport はマネージドクラスター全体からアプリケーションステータスを集約します。
  • レポートには、リソースのリストと、各マネージドクラスターからのアプリケーションの全体的なステータスが含まれます。
  • Argo CD ApplicationSet リソースごとに個別のレポートリソースが作成されます。レポートは ApplicationSet と同じ namespace に作成されます。

  • レポートには次の項目が含まれます。

    1. Argo CD アプリケーションのリソースのリスト
    2. 各 Argo CD アプリケーションの全体的な同期およびヘルスステータス
    3. 全体的なステータスが out of sync、または unhealthy 各クラスターのエラーメッセージ
    4. 管理対象クラスタのすべての状態を示すサマリーステータス
  • Resource sync controller と Aggregation controller は両方とも 10 秒ごとに実行され、レポートを作成します。

  • 次の出力例に示すように、2 つのコントローラーと Propagation コントローラーは、同じ multicluster-integrations Pod 内の別々のコンテナーで実行されます。 

    NAMESPACE               NAME                                       READY   STATUS
open-cluster-management multicluster-integrations-7c46498d9-fqbq4  3/3     Running
    Copy to Clipboard Toggle word wrap

以下は、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"
Copy to Clipboard Toggle word wrap

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

1.6.10.5. 関連情報
リンクのコピー

1.6.11. デプロイメントのスケジュール
リンクのコピー

Helm チャートやその他のリソースを特定の時間にだけデプロイしたり、変更したりする必要がある場合は、このようなリソースにサブスクリプションを定義して、特定の時間にだけ、デプロイメントを開始することができます。あるいは、デプロイメントを制限することもできます。

たとえば、金曜の午後 10 時から午後 11 時の時間帯を、クラスターにパッチや他のアプリケーションの更新を適用する予定メンテナンス枠として定義できます。

ピークの営業時間に想定外のデプロイメントが実行されないように、特定の時間帯にデプロイメントが開始しないように制限またはブロックできます。たとえば、午前 8 時から午後 8 時までデプロイメントを開始しないように、サブスクリプションに時間帯を定義してピーク時を回避できます。

サブスクリプションに期間を定義することで、すべてのアプリケーションおよびクラスターの更新を調整できます。たとえば、午後 6 時 1 分から午後 11 時 59 分までの間に新しいアプリケーションリソースのみをデプロイするようにサブスクリプションを定義し、また別のサブスクリプションに対して、午前 12 時から午前 7 時 59 分までの間に既存のリソースの更新版のみをデプロイするように定義できます。

サブスクリプションに期間を定義すると、サブスクリプションがアクティブな期間が変わります。期間の定義の一部として、期間内のサブスクリプションを active または blocked に定義できます。

サブスクリプションがアクティブな場合にだけ、新規リソースまたは変更リソースのデプロイメントが開始されます。サブスクリプションがアクティブであるか、ブロックされているかに関わらず、サブスクリプションは引き続き、新規リソースや変更リソースがないかどうかを監視します。Active または Blocked の設定は、デプロイメントにだけ影響があります。

新しいリソースまたは変更されたリソースが検出されると、期間の定義をもとに、サブスクリプションの次のアクションが決まります。

  • HelmRepo、ObjectBucket、および Git タイプのチャネルに対するサブスクリプションの場合:
  • サブスクリプションが アクティブ な期間にリソースが検出されると、リソースのデプロイメントが開始されます。
  • サブスクリプションでのデプロイメントの実行がブロックされている期間外にリソースが検出された場合は、リソースのデプロイ要求がキャッシュされます。次回サブスクリプションがアクティブになると、キャッシュされた要求が適用され、関連のデプロイメントが開始されます。
  • 期間が ブロック されると、アプリケーションサブスクリプションで以前にデプロイされたすべてのリソースが残ります。新しい更新は、期間が再度アクティブになるまでブロックされます。

アプリケーションの準期間がブロックされていると、デプロイされたリソースがすべて削除されるとエンドユーザーが誤って判断する場合があります。また、アプリの準期間が再度アクティブになると、元に戻ります。

定義された期間にデプロイメントが開始され、その定義期間終了時を超えてもデプロイメントが実行されている場合は、デプロイメントが完了するまで継続されます。

サブスクリプションの期間を定義するには、必要なフィールドおよび値をサブスクリプションリソース定義 YAML に追加する必要があります。

  • 期間の定義では、日付と時間を定義できます。
  • 期間タイプも定義できます。このタイプにより、指定の期間中または期間外にデプロイメントを開始できる期間かどうかが決定します。
  • 期間タイプが active の場合、デプロイメントは、定義した期間中にのみ開始できます。特定のメンテナンス期間にデプロイメントを行う場合に限り、この設定を使用できます。
  • 期間タイプが block の場合、デプロイメントは、定義した期間中に開始できませんが、それ以外の時間であればいつでも開始できます。この設定は、特定の時間帯のデプロイメントは回避しつつも、必須の重要な更新がある場合に、使用できます。たとえば、セキュリティー関連の更新を午前 10 時から午後 2 時の時間帯以外に実行できるように、期間を定義する場合に、このタイプを使用できます。
  • 毎週月曜と水曜に期間を定義するなど、サブスクリプションの期間を複数定義できます。

1.6.12. パッケージの上書きの設定
リンクのコピー

パッケージが、サブスクリプションに登録されている Helm チャートまたは Kubernetes リソースのサブスクリプション上書き値より優先されるように設定します。

パッケージの上書きを設定するには、path フィールドの値として上書きするように、Kubernetes リソース spec のフィールドを指定します。value フィールドの値として、置き換える値を指定します。

たとえば、サブスクライブしている Helm チャートの Helm リリース spec 内の値フィールドを上書きする必要がある場合は、サブスクリプション定義の path フィールドを spec に設定する必要があります。 

packageOverrides:
- packageName: nginx-ingress
  packageOverrides:
  - path: spec
    value: my-override-values
1
Copy to Clipboard Toggle word wrap
1
value フィールドの内容は、Helm 仕様の spec フィールドの値を上書きするのに使用します。
  • Helm リリースの場合は、spec フィールドの上書き値が Helm リリースの values.yaml ファイルにマージされ、既存の値を上書きします。このファイルを使用して、Helm リリースの設定可能な変数を取得します。

  • Helm リリースのリリース名を上書きする必要がある場合は、定義に packageOverride セクションを追加します。以下のフィールドを追加して、Helm リリースの packageAlias を定義します。

    • packageName (Helm チャートを特定)
    • packageAlias (リリース名を上書きすることを指定)

    デフォルトでは、Helm リリース名が指定されていない場合は、Helm チャート名を使用してリリースを特定します。同じチャートに複数のリリースがサブスクライブされている場合など、競合が発生する可能性があります。リリース名は、namespace 内の全サブスクリプションで一意である必要があります。作成するサブスクリプションのリリース名が一意でない場合は、エラーが発生します。packageOverride を定義して、サブスクリプションに異なるリリース名を設定する必要があります。既存のサブスクリプション内の名前を変更する場合は、先にサブスクリプションを削除してから、希望のリリース名でサブスクリプションを作り直す必要があります。 

packageOverrides:
- packageName: nginx-ingress
  packageAlias: my-helm-release-name
Copy to Clipboard Toggle word wrap

1.6.13. チャネルサンプルの概要
リンクのコピー

ファイルの構築に使用できる例および YAML 定義を確認します。チャネル (channel.apps.open-cluster-management.io) では、Red Hat Advanced Cluster Management for Kubernetes アプリケーションを作成して管理するための、向上された継続的インテグレーション/継続的デリバリー機能 (CICD) を提供します。

OpenShift CLI ツールを使用するには、以下の手順を参照します。

  1. 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。

  2. 以下のコマンドを実行してファイルを API サーバーに適用します。filename は、使用するファイル名に置き換えます。 

    oc apply -f filename.yaml
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。 

    oc get application.app
    Copy to Clipboard Toggle word wrap

1.6.13.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:
Copy to Clipboard Toggle word wrap

1.6.13.2. チャネル YAML 表
リンクのコピー

Expand
フィールド任意または必須詳細

apiVersion

必須

この値は apps.open-cluster-management.io/v1 に設定します。

kind

必須

この値は Channel に設定して、リソースがチャネルであることを指定します。

metadata.name

必須

チャネルの名前。

metadata.namespace

必須

チャネルの namespace。各チャネルには Git チャネルを除き、一意の namespace が必要です。

spec.sourceNamespaces

任意

チャネルコントローラーが取得してチャネルにプロモートする新規または更新された deployable がないかを監視する namespace を指定してします。

spec.type

必須

チャネルタイプ。サポート対象のタイプは、HelmRepo、Git、および ObjectBucket (コンソールのオブジェクトストレージ) です。

spec.pathname

HelmRepo、Git、ObjectBucket チャネルには必須。

HelmRepo チャネルの場合は、値を Helm リポジトリーの URL に設定します。ObjectBucket チャネルの場合は、値をオブジェクトストレージの URL に設定します。Git チャネルの場合は、値を Git リポジトリーの HTTPS URL に設定します。

spec.secretRef.name

任意

リポジトリーまたはチャートへのアクセスなど、認証に使用する Kubernetes Secret リソースを指定します。シークレットは、HelmRepo、ObjectBucket、および Git タイプのチャネルでのみ認証に使用できます。

spec.gates

任意

チャネル内での deployable のプロモート要件を定義します。要件が設定されていない場合は、チャネルの namespace またはソースに追加された deployable がそのチャネルにプロモートされます。gates は、ObjectBucket チャネルタイプだけに適用され、HelmRepo や Git チャネルタイプには適用されません。

spec.gates.annotations

任意

チャネルのアノテーション。チャネル内では deployable に同じアノテーションを追加する必要があります。

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/
Copy to Clipboard Toggle word wrap

1.6.13.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
Copy to Clipboard Toggle word wrap

1.6.13.4. Helm リポジトリー (HelmRepo) チャネル
リンクのコピー

以下のチャネル定義例では 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
Copy to Clipboard Toggle word wrap

以下のチャネル定義は、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/
Copy to Clipboard Toggle word wrap

1.6.13.5. Git (Git) リポジトリーチャネル
リンクのコピー

以下のチャネル定義例は、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
Copy to Clipboard Toggle word wrap

1.6.14. サブスクリプションの例の概要
リンクのコピー

ファイルの構築に使用できる例および YAML 定義を確認します。チャネルと同様に、サブスクリプション (subscription.apps.open-cluster-management.io) は、アプリケーション管理用に、向上された継続的インテグレーション/継続的デリバリー (CICD) 機能を提供します。

OpenShift CLI ツールを使用するには、以下の手順を参照します。

  1. 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。

  2. 以下のコマンドを実行してファイルを API サーバーに適用します。filename は、使用するファイル名に置き換えます。 

    oc apply -f filename.yaml
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。 

    oc get application.app
    Copy to Clipboard Toggle word wrap

1.6.14.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:
Copy to Clipboard Toggle word wrap

1.6.14.2. サブスクリプションの YAML 表
リンクのコピー

Expand
フィールド必須またはオプション詳細

apiVersion

必須

この値は apps.open-cluster-management.io/v1 に設定します。

kind

必須

この値は Subscription に設定して、リソースがチャネルであることを指定します。

metadata.name

必須

サブスクリプションを識別する名前。

metadata.namespace

必須

サブスクリプションに使用する namespace リソース。

metadata.labels

任意

サブスクリプションのラベル。

spec.channel

任意

サブスクリプションのチャネルを定義する namespace 名 ("Namespace/Name")。channel フィールド、source フィールド、または sourceNamespace フィールドを定義します。通常、source フィールドまたは sourceNamespace フィールドを使用する代わりに、channel フィールドを使用してチャネルを参照します。複数のフィールドが定義されている場合は、定義されている最初のフィールドが使用されます。

spec.sourceNamespace

任意

deployable を保存するハブクラスター上のソース namespace。このフィールドは namespace チャネルにのみ使用してください。channel フィールド、source フィールド、または sourceNamespace フィールドを定義します。通常、source フィールドまたは sourceNamespace フィールドを使用する代わりに、channel フィールドを使用してチャネルを参照します。

spec.source

任意

deployable の保存先である Helm リポジトリーのパス名 ("URL")。このフィールドは、Helm リポジトリーチャネルにだけ使用します。channel フィールド、source フィールド、または sourceNamespace フィールドを定義します。通常、source フィールドまたは sourceNamespace フィールドを使用する代わりに、channel フィールドを使用してチャネルを参照します。

spec.name

HelmRepo タイプのチャネルには必須ですが、ObjectBucket タイプのチャネルには任意です。

チャネル内にあるターゲットの Helm チャートまたは deployable の固有名。任意のフィールドである name や packageFilter が定義されていない場合には、すべての deployables が検出され、各 deployable の最新バージョンが取得されます。

spec.packageFilter

任意

ターゲットの deployable または deployable のサブセットを検索するのに使用するパラメーターを定義します。複数のフィルター条件が定義されている場合、deployable はすべてのフィルター条件を満たす必要があります。

spec.packageFilter.version

任意

deployable のバージョン。バージョンの範囲には >1.0 または <3.0 の形式を使用できます。デフォルトでは、"creationTimestamp" の値が最新のバージョンが使用されます。

spec.packageFilter.annotations

任意

deployable のアノテーション。

spec.packageOverrides

任意

チャネル内の Helm チャート、deployable、他の Kubernetes リソースなど、サブスクリプションで取得する Kubernetes リソースの上書きを定義するセクションです。

spec.packageOverrides.packageName

任意ですが、オーバーライドの設定には必須です。

上書きされる Kubernetes リソースを特定します。

spec.packageOverrides.packageAlias

任意

上書きされる Kubernetes リソースにエイリアスを指定します。

spec.packageOverrides.packageOverrides

任意

Kubernetes リソースの上書きに使用するパラメーターおよび代替値の設定。

spec.placement

必須

deployable を配置する必要のあるサブスクライブクラスター、またはクラスターを定義する配置ルールを特定します。配置設定を使用して、マルチクラスターデプロイメントの値を定義します。非推奨: PlacementRule は非推奨になりました。代わりに Placement を使用してください。

spec.placement.local

任意ですが、スタンドアロンクラスターまたは直接管理するクラスターには必須です。

サブスクリプションをローカルにデプロイする必要があるかどうかを定義します。

サブスクリプションと、指定のチャネルを同期させるには、値を true に設定します。

指定のチャネルからリソースをサブスクライブしないようにするには、この値を false に設定します。

クラスターがスタンドアロンクラスターの場合や、このクラスターを直接管理している場合は、このフィールドを使用します。クラスターがマルチクラスターに含まれており、クラスターを直接管理する必要がない場合は、clusters、clusterSelector、または placementRef の 1 つだけを使用してサブスクリプションの配置先を定義します。クラスターがマルチクラスターのハブで、クラスターを直接管理する必要がある場合は、サブスクリプション Operator がローカルのリソースにサブスクライブする前に、ハブをマネージドクラスターとして登録しておく必要があります。

spec.placement.clusters

任意

サブスクリプションを配置するクラスターを定義します。clusters、clusterSelector、または placementRef の 1 つだけを使用して、サブスクリプションをマルチクラスターのどの部分に配置するかを定義します。クラスターが、ハブクラスターではないスタンドアロンクラスターの場合は、local cluster も使用できます。

spec.placement.clusters.name

任意ですが、サブスクライブするクラスターを定義するには必須です。

サブスクライブするクラスターの名前です。

spec.placement.clusterSelector

任意

サブスクリプションを配置するクラスターを識別するために使用するラベルセレクターを定義します。clusters、clusterSelector、または placementRef の 1 つだけを使用して、サブスクリプションをマルチクラスターのどの部分に配置するかを定義します。クラスターが、ハブクラスターではないスタンドアロンクラスターの場合は、local cluster も使用できます。

spec.placement.placementRef

任意

サブスクリプションに使用する配置ルールを定義します。clusters、clusterSelector、または placementRef の 1 つだけを使用して、サブスクリプションをマルチクラスターのどの部分に配置するかを定義します。クラスターが、ハブクラスターではないスタンドアロンクラスターの場合は、local cluster も使用できます。

spec.placement.placementRef.name

任意ですが、配置ルールを使用するには必須です。

サブスクリプションの配置ルールの名前です。

spec.placement.placementRef.kind

任意ですが、配置ルールを使用するには必須です。

この値を Placement に設定して、サブスクリプションでのデプロイメントに使用する配置ルールを指定します。非推奨: PlacementRule は非推奨になりました。

spec.overrides

任意

クラスター固有の設定など、上書きする必要のあるパラメーターおよび値。

spec.overrides.clusterName

任意

パラメーターおよび値を上書するクラスターの名前。

spec.overrides.clusterOverrides

任意

上書きするパラメーターおよび値の設定。

spec.timeWindow

任意

サブスクリプションがアクティブな期間、またはブロックされる期間の設定を定義します。

spec.timeWindow.type

任意ですが、期間の設定には必須

設定した期間中に、サブスクリプションがアクティブであるか、ブロックされるかを指定します。サブスクリプションのデプロイメントは、サブスクリプションがアクティブな場合にのみ行われます。

spec.timeWindow.location

任意ですが、期間の設定には必須

設定した期間のタイムゾーン。タイムゾーンはすべて Time Zone (tz) データベース名の形式を使用する必要があります。詳細は、Time Zone Database を参照します。

spec.timeWindow.daysofweek

任意ですが、期間の設定には必須

期間の作成時に時間の範囲を適用する場合は、曜日を指定します。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 ダート、deployable、またはその他の Kubernetes リソースを参照できます。ただし、サブスクリプションは、チャート、deployable、その他のリソースの最新バージョンのみをデプロイします。
  • 期間の範囲を定義する場合には、開始時間は、終了時間より前に設定する必要があります。サブスクリプションに複数の期間を定義する場合は、期間の範囲を重複させることができません。実際の時間の範囲は、subscription-controller のコンテナーの時間をもとにしていますが、作業環境とは異なる時間および場所を設定することができます。
  • サブスクリプション仕様では、サブスクリプションの定義の一部として Helm リリースの配置を定義することもできます。サブスクリプションごとに、既存の配置ルールを参照するか、サブスクリプション定義内に直接配置ルールを定義できます。
  • spec.placement セクションに、サブスクリプションの配置先を定義する時には、マルチクラスター環境の clusters、clusterSelector、または placementRef の 1 つだけを使用します。

  • 複数の配置設定を追加した場合は、1 つの設定が使用され、他の設定は無視されます。サブスクリプション Operator が使用する設定を決定するために、以下の優先順位で使用されます。

    1. placementRef
    2. clusters
    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
Copy to Clipboard Toggle word wrap

1.6.14.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
Copy to Clipboard Toggle word wrap

1.6.14.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
Copy to Clipboard Toggle word wrap
1.6.14.4.1. サブスクリプションの時間枠の例
リンクのコピー

以下のサブスクリプションの例には、設定された時間枠が複数含まれています。指定の時間枠は、毎週月曜、水曜、金曜の午前 10 時 20 分から午前 10 時半の間と、毎週月曜、水曜、金曜の午後 12 時 40 分から午後 1 時 40 分の間です。1 週間でこの 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"
Copy to Clipboard Toggle word wrap

timewindow には、タイプの目的に応じて、active または blocked を入力します。

1.6.14.4.2. 上書きを使用したサブスクリプションの例
リンクのコピー

以下の例には、パッケージの上書きが含まれており、Helm チャートの Helm リリースに異なるリリース名を定義します。パッケージの上書き設定は、nginx-ingress Helm リリースの別のリリース名として、my-nginx-ingress-releaseName の名前を設定するために使用します。 

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
Copy to Clipboard Toggle word wrap
1.6.14.4.3. Helm リポジトリーのサブスクリプションの例
リンクのコピー

以下のサブスクリプションは、バージョンが 1.36.x の最新の nginx Helm リリースを自動的にプルします。ソースの Helm リポジトリーで新規バージョンが利用できる場合、Helm リリースの deployable は my-development-cluster-1 クラスターに配置されます。

spec.packageOverrides セクションでは、Helm リリースの上書き値の任意パラメーターを指定します。上書き値は、Helm リリースの values.yaml ファイルにマージされ、このファイルを使用して Helm リリースの設定可能な値を取得します。 

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
Copy to Clipboard Toggle word wrap
1.6.14.4.4. Git リポジトリーのサブスクリプションの例
リンクのコピー
1.6.14.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
Copy to Clipboard Toggle word wrap

このサブスクリプションの例では、apps.open-cluster-management.io/git-path のアノテーションは、チャネルに指定されている Git リポジトリーの sample_app_1/dir1 ディレクトリーにある Helm チャートおよび Kubernetes リソースのすべてをサブスクリプションがサブスクライブするように指定します。サブスクリプションは、デフォルトで master ブランチにサブスクライブします。このサブスクリプションの例では、apps.open-cluster-management.io/git-branch: branch1 のアノテーションを指定して、リポジトリーの branch1 ブランチをサブスクライブしています。

注意: Helm チャートにサブスクライブする Git チャネルサブスクリプションを使用している場合には、リソーストポロジービューには追加の Helmrelease リソースが表示される可能性があります。このリソースは内部アプリケーションの管理リソースであるため、無視しても問題はありません。

1.6.14.4.4.2. .kubernetesignore ファイルの追加
リンクのコピー

Git リポジトリーの root ディレクトリー、またはサブスクリプションのアノテーションで指定した apps.open-cluster-management.io/git-path ディレクトリーに .kubernetesignore ファイルを追加できます。

この .kubernetesignore ファイルを使用して、サブスクリプションが、そのリポジトリーから Kubernetes リソースまたは Helm チャートをデプロイするときに無視するファイルまたはサブディレクトリー、もしくはその両方を指定することができます。

また、.kubernetesignore ファイルを使用して、詳細に絞り込み、選択した Kubernetes リソースだけを適用することもできます。.kubernetesignore ファイルのパターン形式は、.gitignore ファイルと同じです。

apps.open-cluster-management.io/git-path アノテーションが定義されていないと、サブスクリプションは、リポジトリーの root ディレクトリーで .kubernetesignore ファイルを検索します。apps.open-cluster-management.io/git-path フィールドが定義されていると、サブスクリプションは apps.open-cluster-management.io/git-path ディレクトリーで .kubernetesignore ファイルを検索します。サブスクリプションは、他のディレクトリーでは .kubernetesignore ファイルの検索は行いません。

1.6.14.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
Copy to Clipboard Toggle word wrap

kustomization.yaml ファイルを上書きするには、packageOverrides に packageName: kustomization が必要です。上書きは、新規エントリーを追加するか、既存のエントリーを更新します。既存のエントリーは削除されません。

1.6.14.4.4.4. Git WebHook の有効化
リンクのコピー

デフォルトでは、Git チャネルのサブスクリプションは、チャネルで指定されている Git リポジトリーを 1 分ごとにクローンし、コミット ID が変更されたら、変更が適用されます。または、リポジトリーのプッシュまたはプルの Webhook イベント通知を Git リポジトリーが送信する場合にのみ、変更を適用するようにサブスクリプションを設定できます。

Git リポジトリーで Webhook を設定するには、ターゲット Webhook ペイロード URL と、シークレット (任意) が必要です。

1.6.14.4.4.4.1. ペイロード URL
リンクのコピー

ハブクラスターでルート (Ingress) を作成し、サブスクリプション Operator の Webhook イベントリスナーサービスを公開します。 

oc create route passthrough --service=multicluster-operators-subscription -n open-cluster-management
Copy to Clipboard Toggle word wrap

次に、oc get route multicluster-operators-subscription -n open-cluster-management コマンドを使用して、外部からアクセスできるホスト名を見つけます。

webhook のペイロード URL は https://<externally-reachable hostname>/webhook です。

1.6.14.4.4.4.2. Webhook シークレット
リンクのコピー

Webhook シークレットは任意です。チャネル namespace に Kubernetes Secret を作成します。シークレットには data.secret を含める必要があります。

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

apiVersion: v1
kind: Secret
metadata:
  name: my-github-webhook-secret
data:
  secret: BASE64_ENCODED_SECRET
Copy to Clipboard Toggle word wrap

data.secret の値は、使用する base-64 でエンコードされた WebHook シークレットに置き換えます。

ベストプラクティス: Git リポジトリーごとに一意のシークレットを使用してください。

1.6.14.4.4.4.3. Git リポジトリーでの Webhook の設定
リンクのコピー

ペイロード URL および Webhook シークレットを使用して Git リポジトリーで Webhook を設定します。

1.6.14.4.4.4.4. チャネルでの Webhook イベント通知の有効化
リンクのコピー

サブスクリプションチャネルにアノテーションを追加します。以下の例を参照してください。 

oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-enabled="true"
Copy to Clipboard Toggle word wrap

WebHook の設定にシークレットを使用した場合は、これにも、チャネルにアノテーションを付けます。<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>"
Copy to Clipboard Toggle word wrap

サブスクリプションには Webhook 固有の設定は必要ありません。

1.6.15. Placement ルールのサンプルの概要 (非推奨)
リンクのコピー

非推奨: PlacementRules は非推奨になりました。代わりに Placement を使用してください。

配置ルール (placementrule.apps.open-cluster-management.io) は、deployable をデプロイ可能なターゲットクラスターを定義します。配置ルールを使用すると、deployable のマルチクラスターでのデプロイメントが容易になります。

OpenShift CLI ツールを使用するには、以下の手順を参照します。

  1. 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。

  2. 以下のコマンドを実行してファイルを API サーバーに適用します。filename は、使用するファイル名に置き換えます。 

    oc apply -f filename.yaml
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。 

    oc get application.app
    Copy to Clipboard Toggle word wrap

1.6.15.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:
Copy to Clipboard Toggle word wrap

1.6.15.2. 配置ルールの YAML 値の表
リンクのコピー

Expand
フィールド必須またはオプション詳細

apiVersion

必須

この値は apps.open-cluster-management.io/v1 に設定します。

kind

必須

この値は PlacementRule に設定して、リソースが配置ルールであることを指定します。

metadata.name

必須

配置ルールを識別する名前。

metadata.namespace

必須

配置ルールに使用する namespace リソース。

metadata.resourceVersion

任意

配置ルールのリソースのバージョン。

metadata.labels

任意

配置ルールのラベル。

spec.clusterSelector

任意

ターゲットクラスターを特定するラベル。

spec.clusterSelector.matchLabels

任意

ターゲットクラスターに含める必要があるラベル。

spec.clusterSelector.matchExpressions

任意

ターゲットクラスターに含める必要があるラベル。

status.decisions

任意

deployable を配置するターゲットクラスターを定義します。

status.decisions.clusterName

任意

ターゲットクラスターの名前。

status.decisions.clusterNamespace

任意

ターゲットクラスターの namespace。

spec.clusterReplicas

任意

作成するレプリカの数。

spec.clusterConditions

任意

クラスターの条件を定義します。

spec.ResourceHint

任意

以前のフィールドで指定したラベルと値に複数のクラスターが一致した場合は、リソース固有の基準を指定してクラスターを選択することができます。たとえば、利用可能な CPU コアの最大数で、クラスターを選択できます。

spec.ResourceHint.type

任意

この値を cpu に設定して、利用可能な CPU コア数をもとにクラスターを選択するか、memory に設定して、利用可能なメモリーリソースをもとにクラスターを選択することができます。

spec.ResourceHint.order

任意

この値は、昇順の場合は asc に、または降順の場合は desc に設定します。

spec.Policies

任意

配置ルールのポリシーフィルター。

1.6.15.3. 配置ルールファイルの例
リンクのコピー

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

既存の配置ルールに、以下のフィールドを追加して、配置ルールのステータスを指定することができます。このステータスのセクションは、ルールの YAML 構造の spec セクションの後に追加できます。 

status:
  decisions:
    clusterName:
    clusterNamespace:
Copy to Clipboard Toggle word wrap
Expand
フィールド詳細

status

配置ルールのステータス情報。

status.decisions

deployable を配置するターゲットクラスターを定義します。

status.decisions.clusterName

ターゲットクラスターの名前。

status.decisions.clusterNamespace

ターゲットクラスターの namespace。

  • 例 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
Copy to Clipboard Toggle word wrap
  • 例 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
Copy to Clipboard Toggle word wrap

1.6.16. アプリケーションの例
リンクのコピー

ファイルの構築に使用できる例および YAML 定義を確認します。Red Hat Advanced Cluster Management for Kubernetes のアプリケーション (Application.app.k8s.io) は、アプリケーションコンポーネントの表示に使用します。

OpenShift CLI ツールを使用するには、以下の手順を参照します。

  1. 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。

  2. 以下のコマンドを実行してファイルを API サーバーに適用します。filename は、使用するファイル名に置き換えます。 

    oc apply -f filename.yaml
    Copy to Clipboard Toggle word wrap

  3. 以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。 

    oc get application.app
    Copy to Clipboard Toggle word wrap

1.6.16.1. アプリケーションの YAML 構造
リンクのコピー

アプリケーション定義 YAML コンテンツを作成して、アプリケーションリソースを作成または更新するには、YAML 構造に、必須のフィールドおよび値を追加する必要があります。アプリケーション要件やアプリケーション管理の要件によっては、他の任意のフィールドや値を追加しないといけない場合があります。

以下の YAML 構造は、アプリケーションの必須フィールドと、一般的な任意のフィールドの一部を示しています。 

apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  name:
  namespace:
spec:
  selector:
    matchLabels:
      label_name: label_value
Copy to Clipboard Toggle word wrap

1.6.16.2. アプリケーションの YAML 表
リンクのコピー

Expand
フィールド値詳細

apiVersion

app.k8s.io/v1beta1

必須

kind

アプリケーション

必須

metadata

  
 

name: アプリケーションリソースを識別する名前

必須

 

namespace: アプリケーションに使用する namespace リソース

 

spec

  

selector.matchLabels

このアプリケーションを関連付けるサブスクリプションにある Kubernetes ラベルと値の key:value ペア。ラベルを使用すると、ラベル名と値を照合させることで、アプリケーションリソースは関連のあるサブスクリプションを検索できます。

必須

これらのアプリケーションの定義仕様は、Kubernetes Special Interest Group (SIG) が提供するアプリケーションメタデータ記述子のカスタムリソース定義が基になっています。テーブルに表示される値のみが必要です。

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

1.6.16.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
Copy to Clipboard Toggle word wrap
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat