1.4. アプリケーションの詳細設定
Red Hat Advanced Cluster Management for Kubernetes では、アプリケーションは複数のアプリケーションリソースで設定されています。チャネル、サブスクリプション、および配置ルールリソースを使用すると、アプリケーション全体のデプロイ、更新、および管理に役立ちます。
単一クラスターアプリケーションもマルチクラスターアプリケーションも同じ Kubernetes 仕様を使用しますが、マルチクラスターアプリケーションでは、デプロイメントおよびアプリケーション管理ライフサイクルがさらに自動化されます。
Red Hat Advanced Cluster Management for Kubernetes アプリケーションのアプリケーションコンポーネントリソースはすべて、YAML ファイルの仕様セクションで定義します。アプリケーションコンポーネントリソースを作成または更新する必要がある場合は、適切な仕様セクションを作成してリソースを定義するラベルを追加する必要があります。
以下のアプリケーション詳細設定のトピックを確認してください。
1.4.1. Git リソースのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、サブスクリプションを使用してサブスクライプされているアプリケーションをターゲットクラスターにデプロイすると、アプリケーションリソースが別の namespace に関連付けられている場合でも、このアプリケーションはこのサブスクリプション namespace にデプロイされます。サブスクリプションの管理権限の付与 で説明されているように、サブスクリプション管理者はデフォルトの動作を変更できます。
また、アプリケーションリソースがクラスターに存在しており、サブスクリプションを使用して作成されていない場合、このサブスクリプションではその既存リソースに対して新しいリソースを適用できません。サブスクリプション管理者としてデフォルト設定を変更するには、以下のプロセスを参照してください。
必要なアクセス権限: クラスターの管理者
1.4.1.1. Git でのアプリケーションリソースの作成 リンクのコピーリンクがクリップボードにコピーされました!
サブスクライブ時に、リソース YAML で apiVersion
の完全グループおよびバージョンを指定する必要があります。たとえば、apiVersion: v1
にサブスクライブすると、サブスクリプションコントローラーがサブスクリプションの検証に失敗し、エラーメッセージ Resource /v1, Kind=ImageStream is not supported
が表示されます。
以下の例にあるように、apiVersion
を image.openshift.io/v1
に変更すると、サブスクリプションコントローラーの検証を渡し、リソースが正常に適用されます。
次に、サブスクリプション管理者がデフォルト動作を変更する有用な例を確認します。
1.4.1.2. アプリケーション namespace の例 リンクのコピーリンクがクリップボードにコピーされました!
以下の例では、サブスクリプション管理者としてログインします。
1.4.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 に作成されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
他のユーザーがサブスクリプションを作成した場合は、ConfigMap がすべて、サブスクリプションと同じ namespace に作成されます。
1.4.1.2.2. 同じ namespace へのアプリケーション リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプション管理者は、すべてのアプリケーションリソースを同じ namespace にデプロイする必要がある場合があります。
一覧をサブスクリプション管理者として作成、拒否リストを作成して、すべてのアプリケーションリソースをサブスクリプション namespace にデプロイできます。
apps.open-cluster-management.io/current-namespace-scoped: true
アノテーションをサブスクリプション YAML に追加します。たとえば、サブスクリプション管理者が以下のサブスクリプションを作成すると、直前の例の 3 つの ConfigMap すべてが subscription-ns
namespace に作成されます。
1.4.1.3. リソース上書きの例 リンクのコピーリンクがクリップボードにコピーされました!
適用可能なチャネルタイプ: Git、ObjectBucket (コンソールのオブジェクトストレージ)
注記: helm
チャートリソースが Helm で管理されているため、リソースの上書きオプションは Git リポジトリーから helm
チャートには適用されません。
この例では、以下の ConfigMap はすでにターゲットクラスターにあります。
Git リポジトリーから、以下のリソース YAML ファイル例をサブスクライブして、既存の ConfigMap を置き換えます。data
仕様の変更を参照してください。
1.4.1.3.1. デフォルトのマージオプション リンクのコピーリンクがクリップボードにコピーされました!
デフォルトの apps.open-cluster-management.io/reconcile-option: merge
アノテーションを使用して、Git リポジトリーから以下のサンプルリソースの YAML ファイルを表示します。以下の例を参照してください。
サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、以下の例のように既存の ConfigMap をマージします。
merge
オプションを使用すると、サブスクライブしているリソースのエントリーが、既存のリソースで作成または更新されます。既存のリソースからエントリーは削除されません。
重要: サブスクリプションで上書きする既存のリソースが自動的に別の Operator またはコントローラーで調整されると、リソース設定はサブスクリプションとコントローラーの両方、または Operator により更新されます。このような場合は、この方法を使用しないでください。
1.4.1.3.2. replace オプション リンクのコピーリンクがクリップボードにコピーされました!
サブスクリプション管理者としてログインして、apps.open-cluster-management.io/reconcile-option: replace
アノテーションを付けてサブスクリプションを作成します。以下の例を参照してください。
サブスクリプション管理者がこのサブスクリプションを作成し、そのサブスクリプションで ConfigMap リソースをサブスクライブする場合は、既存の ConfigMap を以下に置き換えます。
1.4.1.4. 特定の Git 要素のサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
特定の Git ブランチ、コミット、またはタグをサブスクライブできます。
1.4.1.4.1. 特定のブランチへのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
multicloud-operators-subscription
リポジトリーに含まれるサブスクリプション operator は、デフォルトで Git リポジトリーのデフォルトのブランチにサブスクライブします。別のブランチにサブスクライブする場合は、そのサブスクリプションにブランチ名のアノテーションを指定する必要があります。
以下の YAML ファイルの例では apps.open-cluster-management.io/git-branch: <branch1>
で異なるブランチを指定する方法を示しています。
1.4.1.4.2. 特定のコミットのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
multicloud-operators-subscription
リポジトリーに含まれるサブスクリプション operator は、デフォルトで Git リポジトリーの指定のブランチに対する最新のコミットにサブスクライブします。特定のコミットにサブスクライブする場合は、サブスクリプションのコミットハッシュで、必要なコミットアノテーションを指定する必要があります。
以下の YAML ファイルの例では apps.open-cluster-management.io/git-desired-commit: <full commit number>
で異なるコミットを指定する方法を示しています。
git-clone-depth
アノテーションは任意で、デフォルトでは 20
に設定されます。この値は、サブスクリプションコントローラーが Git リポジトリーから最新のコミット履歴 20 回分を取得するという意味です。随分前の git-desired-commit
を指定する場合は、必要なコミットに合った git-clone-depth
を指定する必要があります。
1.4.1.4.3. 特定のタグへのサブスクライブ リンクのコピーリンクがクリップボードにコピーされました!
multicloud-operators-subscription
リポジトリーに含まれるサブスクリプション operator は、デフォルトで Git リポジトリーの指定のブランチに対する最新のコミットにサブスクライブします。特定のタグをサブスクライブする場合は、サブスクリプションにタグのアノテーションを指定する必要があります。
以下の YAML ファイルの例では apps.open-cluster-management.io/git-tag: <v1.0>
で異なるタグを指定する方法を示しています。
注記: Git のコミットとタグアノテーションの両方が指定された場合は、タグが無視されます。
git-clone-depth
アノテーションは任意で、デフォルトでは 20
に設定されます。この値は、サブスクリプションコントローラーが Git リポジトリーから最新のコミット履歴 20
回分を取得するという意味です。随分前の git-tag
を指定する場合は、必要なタグのコミットに合った git-clone-depth
を指定する必要があります。