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

サブスクライブ時に、リソース 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'

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

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

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

適用可能なチャネルタイプ: 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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  name: user1
  age: 20

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

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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: test-configmap-1
  namespace: sub-ns
data:
  age: 20

特定の Git ブランチ、コミット、またはタグをサブスクライブできます。

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>

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

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

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

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

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

これは、サブスクリプションによって参照されるチャネルカスタムリソースの 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 に割り当てられます。

チャネルの 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 によってデプロイされたリソースが自動調整されないことを確認します。

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

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

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

これは、サブスクリプションによって参照される 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 によってデプロイされたリソースが自動調整されないことを確認します。

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

multicluster-operators-application、multicluster-operators-channel、multicluster-operators-standalone-subscription、または multicluster-operators-hub-subscription コントローラーを変更するには、次の手順を参照してください。

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

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

開発環境で以下の接続方法を使用し、カスタム署名または自己署名の認証局による 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

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

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

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

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"

マネージドクラスターを 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

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

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

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

以下は、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"

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

デプロイできるアプリケーションサンプルについては、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:

チャネルの定義構造は、以下の 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/

以下のチャネル定義例では、オブジェクトストレージバケットをチャネルとして抽象化します。

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

以下のチャネル定義例では 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

以下のチャネル定義は、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/

以下のチャネル定義例は、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

以下の 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:

注記:

サブスクリプションは、以下の 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

デプロイできるアプリケーションサンプルについては、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

ミラーリングされたチャネル (アプリケーションソースリポジトリー) がある場合は、サブスクリプション 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

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"

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

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

    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

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

oc create route passthrough --service=multicluster-operators-subscription -n open-cluster-management

apiVersion: v1
kind: Secret
metadata:
  name: my-github-webhook-secret
data:
  secret: BASE64_ENCODED_SECRET

oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-enabled="true"

oc annotate channel.apps.open-cluster-management.io <channel name> apps.open-cluster-management.io/webhook-secret="<the_secret_name>"

以下の 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:

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

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

status:
  decisions:
    clusterName:
    clusterNamespace:

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

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

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

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

apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  name:
  namespace:
spec:
  selector:
    matchLabels:
      label_name: label_value

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

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

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

アプリケーションの定義構造は、以下の YAML コンテンツの例のようになります。

apiVersion: app.k8s.io/v1beta1
kind: Application
metadata:
  name: my-application
  namespace: my-namespace
spec:
  selector:
    matchLabels:
      my-label: my-label-value