ダウンストリームクラスターへのマッピング

マルチクラスター専用: このアプローチは、SUSE® Rancher Prime Continuous Deliveryをマルチクラスター方式で実行している場合にのみ適用されます。ターゲットが指定されていない場合、つまりシングルクラスターを使用している場合、バンドルはデフォルトのクラスターグループを対象とします。

`GitRepos`をダウンストリームクラスターにデプロイする際には、クラスターをターゲットにマッピングする必要があります。

ターゲットの定義

`GitRepo`のデプロイメントターゲットは、クラスターまたはクラスターグループと一致させるために`spec.targets`フィールドを使用して行います。YAML仕様は以下の通りです。

kind: GitRepo
apiVersion: fleet.cattle.io/v1alpha1
metadata:
  name: myrepo
  namespace: clusters
spec:
  repo: https://github.com/rancher/fleet-examples
  paths:
  - simple

  # Targets are evaluated in order and the first one to match is used. If
  # no targets match then the evaluated cluster will not be deployed to.
  targets:
  # The name of target. This value is largely for display and logging.
  # If not specified a default name of the format "target000" will be used
  - name: prod
    # A selector used to match clusters.  The structure is the standard
    # metav1.LabelSelector format. If clusterGroupSelector or clusterGroup is specified,
    # clusterSelector will be used only to further refine the selection after
    # clusterGroupSelector and clusterGroup is evaluated.
    clusterSelector:
      matchLabels:
        env: prod
    # A selector used to match cluster groups.
    clusterGroupSelector:
      matchLabels:
        region: us-east
    # A specific clusterGroup by name that will be selected
    clusterGroup: group1
    # A specific cluster by name that will be selected
    clusterName: cluster1

ターゲットの一致

`GitRepo`と同じ名前空間内のすべてのクラスターおよびクラスターグループは、すべてのターゲットに対して評価されます。 ターゲットのいずれかがクラスターと一致する場合、`GitRepo`はダウンストリームクラスターにデプロイされます。一致がない場合、`GitRepo`はそのクラスターにデプロイされません。

クラスターを一致させるためのアプローチは3つあります。 クラスターセレクター、クラスターグループセレクター、または明示的なクラスターグループ名を使用できます。 すべての基準は加算的であり、最終的な一致は「clusterSelector && clusterGroupSelector && clusterGroup」として評価されます。 3つのうちのいずれかがデフォルト値を持っている場合、それは基準から除外されます。 デフォルト値はnullまたは""です。 セレクターの値`{}`は「すべてに一致する」を意味することを理解することが重要です。

targets:
  # Match everything
  - clusterSelector: {}
  # Selector ignored
  - clusterSelector: null

名前でクラスターを一致させることもできます:

targets:
  - clusterName: fleetname

RancherでSUSE® Rancher Prime Continuous Deliveryを使用する際は、`clusters.fleet.cattle.io`リソースの名前を入力してください。

デフォルトターゲット

`GitRepo`にターゲットが設定されていない場合、デフォルトターゲットの値が適用されます。 デフォルトターゲットの値は以下の通りです。

targets:
- name: default
  clusterGroup: default

これは、デフォルトの場所をセットアップしたい場合、未設定のGitReposが向かうクラスターグループをdefaultと呼び、そこにクラスターを追加するだけで済むことを意味します。

クラスターごとのカスタマイズ

`targets:`リソース内の`GitRepo`は、デプロイするクラスターを選択します。`targetCustomizations:`の`fleet.yaml`は、Helmの値のみを上書きし、ターゲティングは変更しません。

SUSE® Rancher Prime Continuous Deliveryを使用して異なるクラスターにKubernetesマニフェストをカスタマイズしてデプロイする方法を示すために、 multi-cluster/helm/fleet.yamlを使用します。

*状況:*ユーザーは、env=devenv=test、`env=prod`という3つの異なるラベルを持つ3つのクラスターを持っています。ユーザーは、これらのクラスターにフロントエンドアプリケーションとバックエンドデータベースをデプロイしたいと考えています。

期待される動作:

  • `dev`クラスターにデプロイした後、データベースのレプリケーションは有効になっていません。

  • `test`クラスターにデプロイした後、データベースのレプリケーションは有効になっています。

  • `prod`クラスターにデプロイした後、データベースのレプリケーションが有効になり、ロードバランサーサービスが公開されます。

の利点:SUSE® Rancher Prime Continuous Delivery

各クラスターにアプリをデプロイする代わりに、SUSE® Rancher Prime Continuous Deliveryを使用すると、次の手順に従ってすべてのクラスターにデプロイできます:

  1. gitRepo `https://github.com/rancher/fleet-examples.git`をデプロイし、パス`multi-cluster/helm`を指定します。

  2. `multi-cluster/helm`の下で、Helmチャートがフロントエンドアプリサービスとバックエンドデータベースサービスをデプロイします。

  3. 次のルールが`fleet.yaml`に定義されます:

targetCustomizations:
- name: dev
  helm:
    values:
      replication: false
  clusterSelector:
    matchLabels:
      env: dev

- name: test
  helm:
    values:
      replicas: 3
  clusterSelector:
    matchLabels:
      env: test

- name: prod
  helm:
    values:
      serviceType: LoadBalancer
      replicas: 3
  clusterSelector:
    matchLabels:
      env: prod

結果:

SUSE® Rancher Prime Continuous Deliveryは、カスタマイズされた`values.yaml`を使って、異なるクラスターにHelmチャートをデプロイします。

構成管理はデプロイメントに限定されず、一般的な構成管理に拡張できます。SUSE® Rancher Prime Continuous Deliveryは、任意のクラスターセット間でのカスタマイズを通じて、自動的に構成管理を適用できます。

targetCustomizations を使用して Helm チャート設定を上書きする際の制限

helm.charthelm.repo、および helm.versiontargetCustomizations で指定できますが、これらのフィールドを上書きすることには重要な制限があります。

SUSE® Rancher Prime Continuous Deliveryは、最初のバンドル作成フェーズ中に、トップレベルの`helm`設定を使用してHelmチャートを取得します。この取得は、targetCustomizations`が処理される前にFleetツールチェーン(`GitJob)によって実行されます。

この段階でチャートがダウンロードされるため、`targetCustomizations`は次の場所から異なるチャートを動的に取得することはできません:

  • ローカルディレクトリ

  • 別の Helm リポジトリ

  • 別のOCIレジストリ(例:ファイアウォールの背後にあるもの)

これらのフィールドを上書きしようとすると、チャート取得中に上書きが無視される可能性があります。場合によっては、Fleet が同じバンドルに複数のチャートバージョンを含めようとすることがあり、これによりバンドルサイズが大幅に増加し、etcd サイズ制限を超える可能性があります。

異なる環境が異なるチャートやレジストリを必要とする場合は、次のアプローチのいずれかを使用してください:

  • 各チャート構成のために別々の fleet.yaml ファイルを定義します。

  • 各環境のために別々の GitRepo リソースを作成します。

追加の例

生の Kubernetes YAML、Helm チャート、Kustomize、およびその三者の組み合わせを使用した例は、 SUSE® Rancher Prime Continuous Delivery Examples リポジトリ にあります。