第1章 アプリケーションの管理
アプリケーションの作成、デプロイ、および管理に関する詳細は、以下のトピックを参照してください。このガイドでは、Kubernetes の概念および用語に精通していることを前提としています。主要な Kubernetes の用語はコンポーネントについては、定義しません。Kubernetes の概念に関する情報は、Kubernetes ドキュメント を参照してください。
アプリケーション管理機能では、アプリケーションや、アプリケーションの更新を構築してデプロイするオプションが統一、簡素化されています。開発者および DevOps 担当者は、このアプリケーション管理機能を使用することで、チャネルおよびサブスクリプションベースの自動化を使用し、環境全体でアプリケーションを作成して管理できます。
重要: アプリケーション名は 37 文字を超えることができません。
以下のトピックを参照してください。
1.1. アプリケーションモデルおよび定義
アプリケーションモデルは、マネージドクラスターにデプロイされるリソースが含まれる 1 つまたは複数の Kubernetes リソースリポジトリー (チャネル リソース) にサブスクライブすることをベースとしています。単一クラスターアプリケーションもマルチクラスターアプリケーションも同じ Kubernetes 仕様を使用しますが、マルチクラスターアプリケーションでは、デプロイメントおよびアプリケーション管理ライフサイクルがさらに自動化されます。
アプリケーションモデルの詳細を理解するには、以下のイメージを参照してください。
以下のアプリケーションリソースセクションを確認します。
1.1.1. アプリケーション
Red Hat Advanced Cluster Management for Kubernetes のアプリケーション (application.app.k8s.io
) は、アプリケーションを設定する Kubernetes リソースのグループ化に使用します。
Red Hat Advanced Cluster Management for Kubernetes アプリケーションのアプリケーションコンポーネントリソースはすべて、YAML ファイルの仕様セクションで定義します。アプリケーションコンポーネントリソースを作成または更新する必要がある場合は、適切な仕様セクションを作成してリソースを定義するラベルを追加する必要があります。
OpenShift Container Platform GitOps またはクラスターにインストールされている Argo CD Operator によって検出されるアプリケーションである Discovered アプリケーションと連携することもできます。同じリポジトリーを共有するアプリケーションは、このビューでグループ化されます。
1.1.2. サブスクリプション
サブスクリプション (subscription.apps.open-cluster-management.io
) により、クラスターは Git リポジトリー、Helm リリースリポジトリー、またはオブジェクトストレージリポジトリーなどのソースリポジトリー (チャネル) にサブスクライブできます。
ハブクラスターが自己管理の場合には、サブスクリプションはハブクラスターにローカルでアプリケーションリソースをデプロイできます。トポロジーで local-cluster
(自己管理のハブクラスター) サブスクリプションを表示できます。リソース要件は、ハブクラスターのパフォーマンスに悪影響を与える可能性があります。
サブスクリプションは、チャネルまたはストレージの場所を参照して、新規または更新したリソーステンプレートを特定できます。次に、サブスクリプション operator は、先にハブクラスターを確認しなくても、直接ストレージの場所からターゲットのマネージドクラスターにダウンロードしてデプロイできます。サブスクリプションを使用すると、サブスクリプション operator は、ハブクラスターの代わりに、新規または更新されたリソースがないか、チャネルを監視できます。
以下のサブスクリプションアーキテクチャーイメージを参照してください。
1.1.2.1. チャネル
チャネル (channel.apps.open-cluster-management.io
) は、クラスターがサブスクリプションを使用してサブスクライブ可能なソースリポジトリーを定義します。許容タイプは、Git、Helm リリース、オブジェクトストレージリポジトリー、ハブクラスター上にあるリソーステンプレートです。
認可が必要なチャネルから Kubernetes リソースまたは Helm チャートを必要とするアプリケーション (例: エンタイトルメントのある Git リポジトリー) がある場合は、これらのチャネルにアクセスできるようにするシークレットを使用できます。お使いのサブスクリプションで、データセキュリティーを確保しつつも、これらのチャネルからデプロイメント用の Kubernetes リソースおよび Helm チャートにアクセスできます。
チャネルは、ハブクラスター内の namespace を使用して、リソースをデプロイメント用に保存する、物理的な場所を参照します。クラスターは、チャネルにサブスクライブすることで、クラスターごとにデプロイするリソースを特定できます。
注記: 一意の namespace に各チャネルを作成することを推奨します。ただし、Git チャネルは、Git、Helm、オブジェクトストレージなどの別のチャネルタイプで namespace を共有できます。
チャネル内のリソースには、そのチャネルにサブスクライブするクラスターのみがアクセスできます。
1.1.2.1.1. サポート対象の Git リポジトリーサーバー
- GitHub
- GitLab
- Bitbucket
- Gogs
1.1.2.2. 配置ルール
配置ルール (placementrule.apps.open-cluster-management.io
) は、リソーステンプレートをデプロイ可能なターゲットクラスターを定義します。配置ルールを使用すると、deployable のマルチクラスターでのデプロイメントが容易になります。配置ルールは、ガバナンスポリシーおよびリスクポリシーにも使用されます。使用方法の詳細は、ガバナンス を参照してください。
1.1.3. ApplicationSet
ApplicationSet
は Argo CD のサブプロジェクトで、GitOps Operator によりサポートされています。ApplicationSet
は Argo CD アプリケーションのマルチクラスターサポートを追加します。Red Hat Advanced Cluster Management コンソールからアプリケーションを作成できます。
注記: ApplicationSet
をデプロイするための前提条件の詳細については、マネージドクラスターの GitOps への登録 を参照してください。
OpenShift Container Platform GitOps は Argo CD を使用してクラスターリソースを維持します。Argo CD は、アプリケーションの継続的インテグレーションおよび継続的デプロイメント (CI/CD) のオープンソースの宣言型ツールです。OpenShift Container Platform GitOps は Argo CD をコントローラー (OpenShift Container Platform GitOps Operator) として実装し、Git リポジトリーで定義されるアプリケーション定義および設定を継続的に監視できるようにします。次に、Argo CD は、これらの設定の指定された状態をクラスターのライブ状態と比較します。
ApplicationSet
コントローラーは、GitOps Operator インスタンスを使用してクラスターにインストールされ、cluster-administrator に焦点を当てたシナリオをサポートする機能を追加することでクラスターを補完します。ApplicationSet
コントローラーは以下の機能を提供します。
- 単一の Kubernetes マニフェストを使用して、GitOps Operator で複数の Kubernetes クラスターをターゲットにする機能。
- 単一の Kubernetes マニフェストを使用して、GitOps Operator を含む 1 つまたは複数の Git リポジトリーから複数のアプリケーションをデプロイする機能。
- monorepo のサポートの改善。これは単一の Git リポジトリー内で定義されている複数の Argo CD アプリケーションリソースである Argo CD のコンテキストに含まれます。
- マルチクラスター内での個別クラスターテナントの機能の向上。特権のあるクラスター管理者を使用して宛先のクラスター/namespace を有効にする必要なく、Argo CD でアプリケーションをデプロイできます。
ApplicationSet
Operator はクラスターデシジョンジェネレーターを使用して、カスタムリソース固有のロジックでデプロイするマネージドクラスターを決定する Kubernetes カスタムリソースをインターフェイスします。クラスターデシジョンリソースは、マネージドクラスターのリストを生成し、これを ApplicationSet
リソースの template フィールドにレンダリングします。これは、参照される Kubernetes リソースの完全な形状に関する知識を必要としないダックタイピングを使用して行われます。
ApplicationSet
内の generators.clusterDecisionResource
値の例を参照してください。
apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: sample-application-set namespace: sample-gitops-namespace spec: generators: - clusterDecisionResource: configMapRef: acm-placement labelSelector: matchLabels: cluster.open-cluster-management.io/placement: sample-application-placement requeueAfterSeconds: 180 template: metadata: name: sample-application-{{name}} spec: project: default source: repoURL: https://github.com/sampleapp/apprepo.git targetRevision: main path: sample-application destination: namespace: sample-application server: "{{server}}" syncPolicy: syncOptions: - CreateNamespace=true - PruneLast=true - Replace=true - ApplyOutOfSyncOnly=true - Validate=false automated: prune: true allowEmpty: true selfHeal: true
以下の Placement
を参照してください。
apiVersion: cluster.open-cluster-management.io/v1beta1 kind: Placement metadata: name: sample-application-placement namespace: sample-gitops-namespace spec: clusterSets: - sampleclusterset
ApplicationSets
の詳細は、Cluster Decision Resource Generator を参照してください。
1.1.4. アプリケーションドキュメント
詳細情報は、以下のドキュメントを参照してください。