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'
次に、サブスクリプション管理者がデフォルト動作を変更する有用な例を確認します。
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
他のユーザーがサブスクリプションを作成した場合は、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
1.6.1.3. リソース上書きの例
適用可能なチャネルタイプ: Git、ObjectBucket (コンソールのオブジェクトストレージ)
注記: helm
チャートリソースが Helm で管理されているため、リソースの上書きオプションは Git リポジトリーから helm
チャートには適用されません。
この例では、以下の ConfigMap はすでにターゲットクラスターにあります。
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: name: user1 age: 19
Git リポジトリーから、以下のリソース YAML ファイル例をサブスクライブして、既存の ConfigMap を置き換えます。data
仕様の変更を参照してください。
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: age: 20
1.6.1.3.1. デフォルトのマージオプション
デフォルトの apps.open-cluster-management.io/reconcile-option: merge
アノテーションを使用して、Git リポジトリーから以下のサンプルリソースの YAML ファイルを表示します。以下の例を参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: subscription-example namespace: sub-ns annotations: apps.open-cluster-management.io/git-path: sample-resources apps.open-cluster-management.io/reconcile-option: merge spec: channel: channel-ns/somechannel placement: placementRef: name: dev-clusters
サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、以下の例のように既存の ConfigMap をマージします。
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: name: user1 age: 20
merge
オプションを使用すると、サブスクライブしているリソースのエントリーが、既存のリソースで作成または更新されます。既存のリソースからエントリーは削除されません。
重要: サブスクリプションで上書きする既存のリソースが自動的に別の Operator またはコントローラーで調整されると、リソース設定はサブスクリプションとコントローラーの両方、または Operator により更新されます。このような場合は、この方法を使用しないでください。
1.6.1.3.2. mergeAndOwn オプション
mergeAndOwn
では、サブスクライブしているリソースのエントリーが既存のリソースで作成または更新されます。サブスクリプション管理者としてログインして、apps.open-cluster-management.io/reconcile-option: mergeAndOwn
アノテーションを付けてサブスクリプションを作成します。以下の例を参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: subscription-example namespace: sub-ns annotations: apps.open-cluster-management.io/git-path: sample-resources apps.open-cluster-management.io/reconcile-option: mergeAndOwn spec: channel: channel-ns/somechannel placement: placementRef: name: dev-clusters
サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、以下の例のように既存の ConfigMap をマージします。
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns annotations: apps.open-cluster-management.io/hosting-subscription: sub-ns/subscription-example data: name: user1 age: 20
前述のように、mergeAndOwn
オプションを使用すると、サブスクライブしているリソースのエントリーが既存のリソースで作成または更新されます。既存のリソースからエントリーは削除されません。また、apps.open-cluster-management.io/hosting-subscription
アノテーションを追加して、リソースがサブスクリプションによって所有されていることを示します。サブスクリプションを削除すると、ConfigMap が削除されます。
1.6.1.3.3. 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
サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、既存の ConfigMap を以下に置き換えます。
apiVersion: v1 kind: ConfigMap metadata: name: test-configmap-1 namespace: sub-ns data: age: 20
1.6.1.4. 特定の Git 要素のサブスクライブ
特定の Git ブランチ、コミット、またはタグをサブスクライブできます。
1.6.1.4.1. 特定のブランチへのサブスクライブ
multicloud-operators-subscription
リポジトリーに含まれるサブスクリプション operator は、デフォルトで Git リポジトリーのデフォルトのブランチにサブスクライブします。別のブランチにサブスクライブする場合は、そのサブスクリプションにブランチ名のアノテーションを指定する必要があります。
以下の YAML ファイルの例では apps.open-cluster-management.io/git-branch: <branch1>
で異なるブランチを指定する方法を示しています。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-mongodb-subscription annotations: apps.open-cluster-management.io/git-path: stable/ibm-mongodb-dev apps.open-cluster-management.io/git-branch: <branch1>
1.6.1.4.2. 特定のコミットのサブスクライブ
multicloud-operators-subscription
リポジトリーに含まれるサブスクリプション operator は、デフォルトで Git リポジトリーの指定のブランチに対する最新のコミットにサブスクライブします。特定のコミットにサブスクライブする場合は、サブスクリプションのコミットハッシュで、必要なコミットアノテーションを指定する必要があります。
以下の YAML ファイルの例では apps.open-cluster-management.io/git-desired-commit: <full commit number>
で異なるコミットを指定する方法を示しています。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-mongodb-subscription annotations: apps.open-cluster-management.io/git-path: stable/ibm-mongodb-dev apps.open-cluster-management.io/git-desired-commit: <full commit number> apps.open-cluster-management.io/git-clone-depth: 100
git-clone-depth
アノテーションは任意で、デフォルトでは 20
に設定されます。この値は、サブスクリプションコントローラーが Git リポジトリーから最新のコミット履歴 20 回分を取得するという意味です。随分前の git-desired-commit
を指定する場合は、必要なコミットに合った git-clone-depth
を指定する必要があります。
1.6.1.4.3. 特定のタグへのサブスクライブ
multicloud-operators-subscription
リポジトリーに含まれるサブスクリプション operator は、デフォルトで Git リポジトリーの指定のブランチに対する最新のコミットにサブスクライブします。特定のタグをサブスクライブする場合は、サブスクリプションにタグのアノテーションを指定する必要があります。
以下の YAML ファイルの例では apps.open-cluster-management.io/git-tag: <v1.0>
で異なるタグを指定する方法を示しています。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: git-mongodb-subscription annotations: apps.open-cluster-management.io/git-path: stable/ibm-mongodb-dev apps.open-cluster-management.io/git-tag: <v1.0> apps.open-cluster-management.io/git-clone-depth: 100
注記: Git のコミットとタグアノテーションの両方が指定された場合は、タグが無視されます。
git-clone-depth
アノテーションは任意で、デフォルトでは 20
に設定されます。この値は、サブスクリプションコントローラーが Git リポジトリーから最新のコミット履歴 20
回分を取得するという意味です。随分前の git-tag
を指定する場合は、必要なタグのコミットに合った git-clone-depth
を指定する必要があります。
1.6.2. サブスクリプション管理者権限の付与
サブスクリプションの管理者権限を付与する方法について説明します。サブスクリプション 管理者は、デフォルトの動作を変更できます。詳細は、以下のプロセスを参照してください。
- コンソールから OpenShift Container Platform クラスターにログインします。
ユーザーを 1 つ以上作成します。ユーザー作成に関する詳細は、ユーザー向けの準備 を参照してください。グループまたはサービスアカウントを用意することもできます。
app.open-cluster-management.io/subscription
アプリケーションの管理者として、ユーザーを作成します。OpenShift Container Platform では、サブスクリプション 管理者はデフォルトの動作を変更できます。これらのユーザーをグループ化してサブスクリプション管理グループを表すことができます。これについては、後ほど例説します。- ターミナルから、Red Hat Advanced Cluster Management クラスターにログインします。
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
以下のコマンドで、次のサブジェクトを
open-cluster-management:subscription-admin
ClusterRoleBinding に追加します。oc edit clusterrolebinding open-cluster-management:subscription-admin
注記:
open-cluster-management:subscription-admin
ClusterRoleBinding にはサブジェクトは初期設定されていません。サブジェクトは以下の例のように表示されます。
subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: example-name - apiGroup: rbac.authorization.k8s.io kind: Group name: example-group-name - kind: ServiceAccount name: my-service-account namespace: my-service-account-namespace - apiGroup: rbac.authorization.k8s.io kind: User name: 'system:serviceaccount:my-service-account-namespace:my-service-account'
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
以下のアプリケーションサブスクリプション YAML は、ソースリポジトリーの myapplication
ディレクトリーからアプリケーションがデプロイされると、ソースリポジトリーに他のリソースがある場合でも v1/Deployment
リソースのみをデプロイすることを指定します。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: annotations: apps.open-cluster-management.io/github-path: myapplication name: demo-subscription namespace: demo-ns spec: channel: demo-ns/somechannel deny: - apiVersion: v1 kinds: - Service - ConfigMap placement: placementRef: name: demo-placement kind: Placement
このアプリケーションのサブスクリプション YAML は、v1/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
上記の例では、sample/git-channel
を使用するすべてのサブスクリプションの調整頻度は low
に割り当てられます。
-
サブスクリプションの調整速度を
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
チャネルで 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
この例では、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
によってデプロイされたリソースが自動調整されないことを確認します。
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
コントローラーを変更するには、次の手順を参照してください。
次のコマンドを実行して、
multiclusterhub
を一時停止します。oc annotate mch -n open-cluster-management multiclusterhub mch-pause=true --overwrite=true
コントローラー名を
oc edit
コマンドに追加して、deployment
ファイルを編集します。次のコマンド例を参照してください。oc edit deployment -n open-cluster-management multicluster-operators-hub-subscription
-
-command
を検索して、コントローラーコマンドフラグを見つけます。 -
コントローラーのコンテナーセクションから、
-command
フラグを挿入します。たとえば、RetryPeriod
を挿入します。 - ファイルを保存します。コントローラーは自動的に再起動してフラグを適用します。
- 変更するコントローラーごとに、この手順を繰り返します。
-
次のコマンドを実行して、
multiclusterhub
を再開します。
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
1.6.6. セキュアな Git 接続用のアプリケーションチャネルおよびサブスクリプションの設定
Git チャネルおよびサブスクリプションは、HTTPS または SSH を使用して指定された Git リポジトリーに接続します。以下のアプリケーションチャネル設定は、セキュアな Git 接続に使用できます。
1.6.6.1. ユーザーおよびアクセストークンを使用したプライベートリポジトリーへの接続
チャネルおよびサブスクリプションを使用して Git サーバーに接続できます。ユーザーおよびアクセストークンを使用してプライベートリポジトリーに接続するには、以下の手順を参照してください。
チャネルと同じ 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
シークレットでチャネルを設定します。
secretRef
が設定された以下の例を参照してください。apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: sample-channel namespace: channel-ns spec: type: Git pathname: <Git HTTPS URL> secretRef: name: my-git-secret
1.6.6.2. Git サーバーへのセキュアではない HTTPS 接続の設定
開発環境で以下の接続方法を使用し、カスタム署名または自己署名の認証局による SSL 証明書を使用して、プライベートにホストされている Git サーバーに接続できます。ただし、このソリューションは実稼働では推奨されません。
チャネルの仕様で insecureSkipVerify: true
を指定します。それ以外の場合は、Git サーバーへの接続が失敗し、以下のようなエラーが表示されます。
x509: certificate is valid for localhost.com, not localhost
この方法のチャネル仕様が追加された以下の例を参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: labels: name: sample-channel namespace: sample spec: type: GitHub pathname: <Git HTTPS URL> insecureSkipVerify: true
1.6.6.3. セキュアな HTTPS 接続でのカスタム CA 証明書の使用
この接続方法を使用し、カスタム署名または自己署名の認証局による SSL 証明書を使用して、プライベートにホストされている Git サーバーに安全に接続できます。
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-----
この ConfigMap でチャネルを設定します。直前の手順の
git-ca
名を使用した以下の例を参照してください。apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: my-channel namespace: channel-ns spec: configMapRef: name: git-ca pathname: <Git HTTPS URL> type: Git
1.6.6.4. Git サーバーへの SSH 接続の設定
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
シークレットでチャネルを設定します。以下のサンプルを参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: my-channel namespace: channel-ns spec: secretRef: name: git-ssh-key pathname: <Git SSH URL> type: Git
サブスクリプションコントローラーは、提供される Git ホスト名で
ssh-keyscan
を行い、SSH 接続での MITM (Man-in-the-middle: 中間者) 攻撃を防ぐためにknown_hosts
リストを構築します。これを省略して非セキュアな接続を確立する場合は、チャネル設定でinsecureSkipVerify: true
を使用します。これは、特に実稼働環境でのベストプラクティスではありません。apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: my-channel namespace: channel-ns spec: secretRef: name: git-ssh-key pathname: <Git SSH URL> type: Git insecureSkipVerify: true
1.6.6.5. 証明書および SSH キーの更新
Git チャネル接続設定で CA 証明書、認証情報、または SSH キーなどの更新が必要な場合は、同じ 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"
1.6.8. デプロイメントのスケジュール
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.9. パッケージの上書きの設定
パッケージが、サブスクリプションに登録されている Helm チャートまたは Kubernetes リソースのサブスクリプション上書き値より優先されるように設定します。
パッケージの上書きを設定するには、path
フィールドの値として上書きするように、Kubernetes リソース spec
のフィールドを指定します。value
フィールドの値として、置き換える値を指定します。
たとえば、サブスクライブしている Helm チャートの Helm リリース spec
内の値フィールドを上書きする必要がある場合は、サブスクリプション定義の path
フィールドを spec
に設定する必要があります。
packageOverrides:
- packageName: nginx-ingress
packageOverrides:
- path: spec
value: my-override-values 1
- 1
value
フィールドの内容は、Helm
仕様のspec
フィールドの値を上書きするのに使用します。-
Helm リリースの場合は、
spec
フィールドの上書き値が Helm リリースのvalues.yaml
ファイルにマージされ、既存の値を上書きします。このファイルを使用して、Helm リリースの設定可能な変数を取得します。 Helm リリースのリリース名を上書きする必要がある場合は、定義に
packageOverride
セクションを追加します。以下のフィールドを追加して、Helm リリースのpackageAlias
を定義します。-
packageName
(Helm チャートを特定) -
packageAlias
(リリース名を上書きすることを指定)
デフォルトでは、Helm リリース名が指定されていない場合は、Helm チャート名を使用してリリースを特定します。同じチャートに複数のリリースがサブスクライブされている場合など、競合が発生する可能性があります。リリース名は、namespace 内の全サブスクリプションで一意である必要があります。作成するサブスクリプションのリリース名が一意でない場合は、エラーが発生します。
packageOverride
を定義して、サブスクリプションに異なるリリース名を設定する必要があります。既存のサブスクリプション内の名前を変更する場合は、先にサブスクリプションを削除してから、希望のリリース名でサブスクリプションを作り直す必要があります。-
packageOverrides: - packageName: nginx-ingress packageAlias: my-helm-release-name
-
Helm リリースの場合は、
1.6.10. チャネルサンプルの概要
ファイルの構築に使用できる例および YAML 定義を確認します。チャネル (channel.apps.open-cluster-management.io
) では、Red Hat Advanced Cluster Management for Kubernetes アプリケーションを作成して管理するための、向上された継続的インテグレーション/継続的デリバリー機能 (CICD) を提供します。
OpenShift CLI ツールを使用するには、以下の手順を参照します。
- 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。
以下のコマンドを実行してファイルを API サーバーに適用します。
filename
は、使用するファイル名に置き換えます。oc apply -f filename.yaml
以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。
oc get application.app
1.6.10.1. チャネル YAML の構造
デプロイできるアプリケーションサンプルについては、lstolostron
リポジトリーを参照してください。
以下の YAML 構造は、チャネルの必須フィールドと、一般的な任意のフィールドの一部を示しています。YAML 構造には、必須なフィールドおよび値を追加する必要があります。アプリケーション管理要件によっては、他の任意のフィールドおよび値を追加しないといけない場合があります。独自の YAML コンテンツは、任意のツールや、製品コンソールで作成できます。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: namespace: # Each channel needs a unique namespace, except Git channel. spec: sourceNamespaces: type: pathname: secretRef: name: gates: annotations: labels:
1.6.10.2. チャネル YAML 表
フィールド | 任意または必須 | 説明 |
---|---|---|
apiVersion | 必須 |
この値は |
kind | 必須 |
この値は |
metadata.name | 必須 | チャネルの名前。 |
metadata.namespace | 必須 | チャネルの namespace。各チャネルには Git チャネルを除き、一意の namespace が必要です。 |
spec.sourceNamespaces | 任意 | チャネルコントローラーが取得してチャネルにプロモートする新規または更新された deployable がないかを監視する namespace を指定してします。 |
spec.type | 必須 |
チャネルタイプ。サポート対象のタイプは、 |
spec.pathname |
|
|
spec.secretRef.name | 任意 |
リポジトリーまたはチャートへのアクセスなど、認証に使用する Kubernetes Secret リソースを指定します。シークレットは、 |
spec.gates | 任意 |
チャネル内での deployable のプロモート要件を定義します。要件が設定されていない場合は、チャネルの namespace またはソースに追加された deployable がそのチャネルにプロモートされます。 |
spec.gates.annotations | 任意 | チャネルのアノテーション。チャネル内では deployable に同じアノテーションを追加する必要があります。 |
metadata.labels | 任意 | チャネルのラベル。 |
spec.insecureSkipVerify | 任意 |
デフォルト値は |
チャネルの定義構造は、以下の YAML コンテンツのようになります。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: predev-ch namespace: ns-ch labels: app: nginx-app-details spec: type: HelmRepo pathname: https://kubernetes-charts.storage.googleapis.com/
1.6.10.3. オブジェクトストレージバケット (ObjectBucket) チャネル
以下のチャネル定義例では、オブジェクトストレージバケットをチャネルとして抽象化します。
apiVersion: apps.open-cluster-management.io/v1 kind: Channel metadata: name: dev namespace: ch-obj spec: type: ObjectBucket pathname: [http://9.28.236.243:xxxx/dev] # URL is appended with the valid bucket name, which matches the channel name. secretRef: name: miniosecret gates: annotations: dev-ready: true
1.6.10.4. Helm リポジトリー (HelmRepo
) チャネル
以下のチャネル定義例では Helm リポジトリーをチャネルとして抽象化します。
非推奨に関する注記: 2.9 では、チャネルの 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/
1.6.10.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
1.6.11. サブスクリプションの例の概要
ファイルの構築に使用できる例および YAML 定義を確認します。チャネルと同様に、サブスクリプション (subscription.apps.open-cluster-management.io
) は、アプリケーション管理用に、向上された継続的インテグレーション/継続的デリバリー (CICD) 機能を提供します。
OpenShift CLI ツールを使用するには、以下の手順を参照します。
- 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。
以下のコマンドを実行してファイルを API サーバーに適用します。
filename
は、使用するファイル名に置き換えます。oc apply -f filename.yaml
以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。
oc get application.app
1.6.11.1. サブスクリプションの YAML 構造
以下の YAML 構造は、サブスクリプションの必須フィールドと、一般的な任意のフィールドの一部を示しています。YAML 構造には、特定の必須フィールドおよび値を追加する必要があります。
アプリケーション管理要件によっては、他の任意のフィールドおよび値を追加しないといけない場合があります。独自の YAML コンテンツは、どのツールでも作成できます。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: namespace: labels: spec: sourceNamespace: source: channel: name: packageFilter: version: labelSelector: matchLabels: package: component: annotations: packageOverrides: - packageName: packageAlias: - path: value: placement: local: clusters: name: clusterSelector: placementRef: name: kind: Placement overrides: clusterName: clusterOverrides: path: value:
1.6.11.2. サブスクリプションの YAML 表
フィールド | 必須またはオプション | 説明 |
---|---|---|
apiVersion | 必須 |
この値は |
kind | 必須 |
この値は |
metadata.name | 必須 | サブスクリプションを識別する名前。 |
metadata.namespace | 必須 | サブスクリプションに使用する namespace リソース。 |
metadata.labels | 任意 | サブスクリプションのラベル。 |
spec.channel | 任意 |
サブスクリプションのチャネルを定義する namespace 名 ("Namespace/Name")。 |
spec.sourceNamespace | 任意 |
Deployable を保存するハブクラスター上のソース namespace。このフィールドは namespace チャネルにのみ使用してください。 |
spec.source | 任意 |
deployable の保存先である Helm リポジトリーのパス名 ("URL")。このフィールドは、Helm リポジトリーチャネルにだけ使用します。 |
spec.name |
|
チャネル内にあるターゲットの Helm チャートまたは deployable の固有名。任意のフィールドである |
spec.packageFilter | 任意 | ターゲットの deployable または deployable のサブセットを検索するのに使用するパラメーターを定義します。複数のフィルター条件が定義されている場合、deployable はすべてのフィルター条件を満たす必要があります。 |
spec.packageFilter.version | 任意 |
deployable のバージョン。バージョンの範囲には |
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 を配置する必要のあるサブスクライブクラスター、またはクラスターを定義する配置ルールを特定します。配置設定を使用して、マルチクラスターデプロイメントの値を定義します。 |
spec.placement.local | 任意ですが、スタンドアロンクラスターまたは直接管理するクラスターには必須です。 | サブスクリプションをローカルにデプロイする必要があるかどうかを定義します。
サブスクリプションと、指定のチャネルを同期させるには、値を
指定のチャネルからリソースをサブスクライブしないようにするには、この値を
クラスターがスタンドアロンクラスターの場合や、このクラスターを直接管理している場合は、このフィールドを使用します。クラスターがマルチクラスターに含まれており、クラスターを直接管理する必要がない場合は、 |
spec.placement.clusters | 任意 |
サブスクリプションを配置するクラスターを定義します。 |
spec.placement.clusters.name | 任意ですが、サブスクライブするクラスターを定義するには必須です。 | サブスクライブするクラスターの名前です。 |
spec.placement.clusterSelector | 任意 |
サブスクリプションを配置するクラスターを識別するために使用するラベルセレクターを定義します。 |
spec.placement.placementRef | 任意 |
サブスクリプションに使用する配置ルールを定義します。 |
spec.placement.placementRef.name | 任意ですが、配置ルールを使用するには必須です。 | サブスクリプションの配置ルールの名前です。 |
spec.placement.placementRef.kind | 任意ですが、配置ルールを使用するには必須です。 |
この値を |
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 | 任意ですが、期間の設定には必須 |
期間の作成時に時間の範囲を適用する場合は、曜日を指定します。 |
spec.timeWindow.hours | 任意ですが、期間の設定には必須 | 期間の範囲を定義します。期間ごとに、開始時間と終了時間 (時間単位) を定義する必要があります。サブスクリプションには複数の期間を定義する必要があります。 |
spec.timeWindow.hours.start | 任意ですが、期間の設定には必須 |
期間の開始を定義するタイムスタンプです。タイムスタンプには、Go プログラミング言語の Kitchen 形式 |
spec.timeWindow.hours.end | 任意ですが、期間の設定には必須 |
期間の終了を定義するタイムスタンプです。タイムスタンプには、Go プログラミング言語の Kitchen 形式 |
注記:
-
YAML の定義時には、サブスクリプションは
packageFilters
を使用して複数の Helm ダート、deployable、またはその他の Kubernetes リソースを参照できます。ただし、サブスクリプションは、チャート、deployable、その他のリソースの最新バージョンのみをデプロイします。 -
期間の範囲を定義する場合には、開始時間は、終了時間より前に設定する必要があります。サブスクリプションに複数の期間を定義する場合は、期間の範囲を重複させることができません。実際の時間の範囲は、
subscription-controller
のコンテナーの時間をもとにしていますが、作業環境とは異なる時間および場所を設定することができます。 - サブスクリプション仕様では、サブスクリプションの定義の一部として Helm リリースの配置を定義することもできます。サブスクリプションごとに、既存の配置ルールを参照するか、サブスクリプション定義内に直接配置ルールを定義できます。
-
spec.placement
セクションに、サブスクリプションの配置先を定義する時には、マルチクラスター環境のclusters
、clusterSelector
、またはplacementRef
の 1 つだけを使用します。 複数の配置設定を追加した場合は、1 つの設定が使用され、他の設定は無視されます。サブスクリプション Operator が使用する設定を決定するために、以下の優先順位で使用されます。
-
placementRef
-
clusters
-
clusterSelector
-
サブスクリプションは、以下の YAML コンテンツのようになります。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch name: nginx-ingress packageFilter: version: "1.36.x" placement: placementRef: kind: Placement name: towhichcluster overrides: - clusterName: "/" clusterOverrides: - path: "metadata.namespace" value: default
1.6.11.3. サブスクリプションファイルの例
デプロイできるアプリケーションサンプルについては、lstolostron
リポジトリーを参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch name: nginx-ingress
1.6.11.4. セカンダリーチャネルの例
ミラーリングされたチャネル (アプリケーションソースリポジトリー) がある場合は、サブスクリプション YAML に secondaryChannel
を指定できます。アプリケーションサブスクリプションがプライマリーチャネルを使用してリポジトリーサーバーへの接続に失敗した場合、セカンダリーチャネルを使用してリポジトリーサーバーに接続します。セカンダリーチャネルに保存されるアプリケーションマニフェストがプライマリーチャネルと同期されていることを確認します。secondaryChannel
の以下のサブスクリプション YAML のサンプルを参照してください。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: nginx namespace: ns-sub-1 labels: app: nginx-app-details spec: channel: ns-ch/predev-ch secondaryChannel: ns-ch-2/predev-ch-2 name: nginx-ingress
1.6.11.4.1. サブスクリプションの時間枠の例
以下のサブスクリプションの例には、設定された時間枠が複数含まれています。指定の時間枠は、毎週月曜、水曜、金曜の午前 10 時 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"
timewindow
には、タイプの目的に応じて、active
または blocked
を入力します。
1.6.11.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
1.6.11.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
1.6.11.4.4. Git リポジトリーのサブスクリプションの例
1.6.11.4.4.1. Git リポジトリーの特定ブランチおよびディレクトリーのサブスクライブ
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: sample-subscription namespace: default annotations: apps.open-cluster-management.io/git-path: sample_app_1/dir1 apps.open-cluster-management.io/git-branch: branch1 spec: channel: default/sample-channel placement: placementRef: kind: Placement name: dev-clusters
このサブスクリプションの例では、apps.open-cluster-management.io/git-path
のアノテーションは、チャネルに指定されている Git リポジトリーの sample_app_1/dir1
ディレクトリーにある Helm チャートおよび Kubernetes リソースのすべてをサブスクリプションがサブスクライブするように指定します。サブスクリプションは、デフォルトで master
ブランチにサブスクライブします。このサブスクリプションの例では、apps.open-cluster-management.io/git-branch: branch1
のアノテーションを指定して、リポジトリーの branch1
ブランチをサブスクライブしています。
注意: Helm チャートにサブスクライブする Git チャネルサブスクリプションを使用している場合には、リソーストポロジービューには追加の Helmrelease
リソースが表示される可能性があります。このリソースは内部アプリケーションの管理リソースであるため、無視しても問題はありません。
1.6.11.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/github-path
ディレクトリーで .kubernetesignore
ファイルを検索します。サブスクリプションは、他のディレクトリーでは .kubernetesignore
ファイルの検索は行いません。
1.6.11.4.4.3. Kustomize の適用
サブスクライブする Git のフォルダーに kustomization.yaml
ファイルまたは kustomization.yml
ファイルがある場合は、kustomize が適用されます。spec.packageOverrides
を使用して、サブスクリプションのデプロイメント時に kustomization
を上書きできます。
apiVersion: apps.open-cluster-management.io/v1 kind: Subscription metadata: name: example-subscription namespace: default spec: channel: some/channel packageOverrides: - packageName: kustomization packageOverrides: - value: | patchesStrategicMerge: - patch.yaml
kustomization.yaml
ファイルを上書きするには、packageOverrides
に packageName: kustomization
が必要です。上書きは、新規エントリーを追加するか、既存のエントリーを更新します。既存のエントリーは削除されません。
1.6.11.4.4.4. GitHub Webhook の有効化
デフォルトでは、Git チャネルのサブスクリプションは、チャネルで指定されている GitHub リポジトリーを 1 分ごとにクローンし、コミット ID が変更されたら、変更が適用されます。または、リポジトリーのプッシュまたはプルの Webhook イベント通知を Git リポジトリーが送信する場合にのみ、変更を適用するようにサブスクリプションを設定できます。
Git リポジトリーで Webhook を設定するには、ターゲット Webhook ペイロード URL と、シークレット (任意) が必要です。
1.6.11.4.4.4.1. ペイロード URL
ハブクラスターでルート (ingress) を作成し、サブスクリプション Operator の Webhook イベントリスナーサービスを公開します。
oc create route passthrough --service=multicluster-operators-subscription -n open-cluster-management
次に、oc get route multicluster-operators-subscription -n open-cluster-management
コマンドを使用して、外部からアクセスできるホスト名を見つけます。
webhook のペイロード URL は https://<externally-reachable hostname>/webhook
です。
1.6.11.4.4.4.2. Webhook シークレット
Webhook シークレットは任意です。チャネル namespace に Kubernetes Secret を作成します。シークレットには data.secret
を含める必要があります。
以下の例を参照してください。
apiVersion: v1 kind: Secret metadata: name: my-github-webhook-secret data: secret: BASE64_ENCODED_SECRET
data.secret
の値は、使用する base-64 でエンコードされた WebHook シークレットに置き換えます。
ベストプラクティス: Git リポジトリーごとに一意のシークレットを使用してください。
1.6.11.4.4.4.3. Git リポジトリーでの Webhook の設定
ペイロード URL および Webhook シークレットを使用して Git リポジトリーで Webhook を設定します。
1.6.11.4.4.4.4. チャネルでの Webhook イベント通知の有効化
サブスクリプションチャネルにアノテーションを追加します。以下の例を参照してください。
oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-enabled="true"
WebHook の設定にシークレットを使用した場合は、これについても、チャネルにアノテーションを付けます。<the_secret_name>
は Webhook シークレットを含む Kubernetes Secret 名に置き換えます。
oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-secret="<the_secret_name>"
サブスクリプションには Webhook 固有の設定は必要ありません。
1.6.12. Placement ルールのサンプルの概要 (非推奨)
非推奨: PlacementRules
は非推奨になりました。代わりに Placement
を使用してください。
配置ルール (placementrule.apps.open-cluster-management.io
) は、deployable をデプロイ可能なターゲットクラスターを定義します。配置ルールを使用すると、deployable のマルチクラスターでのデプロイメントが容易になります。
OpenShift CLI ツールを使用するには、以下の手順を参照します。
- 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。
以下のコマンドを実行してファイルを API サーバーに適用します。
filename
は、使用するファイル名に置き換えます。oc apply -f filename.yaml
以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。
oc get application.app
1.6.12.1. 配置ルールの YAML 構造
以下の YAML 構造は、配置ルールの必須フィールドと、一般的な任意のフィールドの一部を示しています。YAML 構造には、必須なフィールドおよび値を追加する必要があります。アプリケーション管理要件によっては、他の任意のフィールドおよび値を追加しないといけない場合があります。独自の YAML コンテンツは、任意のツールや、製品コンソールで作成できます。
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: namespace: resourceVersion: labels: app: chart: release: heritage: selfLink: uid: spec: clusterSelector: matchLabels: datacenter: environment: clusterReplicas: clusterConditions: ResourceHint: type: order: Policies:
1.6.12.2. 配置ルールの YAML 値の表
フィールド | 必須またはオプション | 説明 |
---|---|---|
apiVersion | 必須 |
この値は |
kind | 必須 |
この値は |
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 | 任意 |
この値を |
spec.ResourceHint.order | 任意 |
この値は、昇順の場合は |
spec.Policies | 任意 | 配置ルールのポリシーフィルター。 |
1.6.12.3. 配置ルールファイルの例
デプロイできるアプリケーションサンプルについては、lstolostron
リポジトリーを参照してください。
既存の配置ルールに、以下のフィールドを追加して、配置ルールのステータスを指定することができます。このステータスのセクションは、ルールの YAML 構造の spec
セクションの後に追加できます。
status: decisions: clusterName: clusterNamespace:
フィールド | 説明 |
---|---|
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
- 例 2
apiVersion: apps.open-cluster-management.io/v1 kind: PlacementRule metadata: name: towhichcluster namespace: ns-sub-1 labels: app: nginx-app-details spec: clusterReplicas: 1 clusterConditions: - type: ManagedClusterConditionAvailable status: "True" clusterSelector: matchExpressions: - key: environment operator: In values: - dev
1.6.13. アプリケーションの例
ファイルの構築に使用できる例および YAML 定義を確認します。Red Hat Advanced Cluster Management for Kubernetes のアプリケーション (Application.app.k8s.io
) は、アプリケーションコンポーネントの表示に使用します。
OpenShift CLI ツールを使用するには、以下の手順を参照します。
- 任意の編集ツールで、アプリケーションの YAML ファイルを作成して保存します。
以下のコマンドを実行してファイルを API サーバーに適用します。
filename
は、使用するファイル名に置き換えます。oc apply -f filename.yaml
以下のコマンドを実行して、アプリケーションリソースが作成されていることを確認します。
oc get application.app
1.6.13.1. アプリケーションの YAML 構造
アプリケーション定義 YAML コンテンツを作成して、アプリケーションリソースを作成または更新するには、YAML 構造に、必須のフィールドおよび値を追加する必要があります。アプリケーション要件やアプリケーション管理の要件によっては、他の任意のフィールドや値を追加しないといけない場合があります。
以下の YAML 構造は、アプリケーションの必須フィールドと、一般的な任意のフィールドの一部を示しています。
apiVersion: app.k8s.io/v1beta1 kind: Application metadata: name: namespace: spec: selector: matchLabels: label_name: label_value
1.6.13.2. アプリケーションの YAML 表
フィールド | 値 | 説明 |
---|---|---|
apiVersion |
| 必須 |
kind |
| 必須 |
metadata | ||
| 必須 | |
| ||
spec | ||
selector.matchLabels |
このアプリケーションを関連付けるサブスクリプションにある Kubernetes ラベルと値の | 必須 |
これらのアプリケーションの定義仕様は、Kubernetes Special Interest Group (SIG) が提供するアプリケーションメタデータ記述子のカスタムリソース定義が基になっています。テーブルに表示される値のみが必要です。
この定義を使用すると、独自のアプリケーションの YAML コンテンツ作成に役立ちます。この定義の詳細は、Kubernetes SIG Application CRD community specification を参照してください。
1.6.13.3. アプリケーションファイルの例
デプロイできるアプリケーションサンプルについては、lstolostron
リポジトリーを参照してください。
アプリケーションの定義構造は、以下の YAML コンテンツの例のようになります。
apiVersion: app.k8s.io/v1beta1 kind: Application metadata: name: my-application namespace: my-namespace spec: selector: matchLabels: my-label: my-label-value