15.2. シングルノード OpenShift クラスターのイメージベースアップグレードの準備

15.2.1. イメージベースアップグレード用の共有コンテナーパーティションの設定

イメージベースアップグレードを行うには、シングルノード OpenShift クラスターに共有 var/lib/containers パーティションが必要です。これはインストール時に行うことができます。

15.2.1.1. ostree stateroot 間の共有コンテナーパーティションの設定

インストール時にシードクラスターとターゲットクラスターの両方に MachineConfig を適用して、個別のパーティションを作成し、アップグレードプロセス中に使用される 2 つの ostree stateroot 間で /var/lib/containers パーティションを共有します。

重要

インストール時にこの手順を完了する必要があります。

手順

MachineConfig を適用して個別のパーティションを作成します。

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: master
  name: 98-var-lib-containers-partitioned
spec:
  config:
    ignition:
      version: 3.2.0
    storage:
      disks:
        - device: /dev/disk/by-path/pci-<root_disk> 1
          partitions:
            - label: varlibcontainers
              startMiB: <start_of_partition> 2
              sizeMiB: <partition_size> 3
      filesystems:
        - device: /dev/disk/by-partlabel/varlibcontainers
          format: xfs
          mountOptions:
            - defaults
            - prjquota
          path: /var/lib/containers
          wipeFilesystem: true
    systemd:
      units:
        - contents: |-
            # Generated by Butane
            [Unit]
            Before=local-fs.target
            Requires=systemd-fsck@dev-disk-by\x2dpartlabel-varlibcontainers.service
            After=systemd-fsck@dev-disk-by\x2dpartlabel-varlibcontainers.service

            [Mount]
            Where=/var/lib/containers
            What=/dev/disk/by-partlabel/varlibcontainers
            Type=xfs
            Options=defaults,prjquota

            [Install]
            RequiredBy=local-fs.target
          enabled: true
          name: var-lib-containers.mount

1: ルートディスクを指定します。
2: パーティションの開始を MiB 単位で指定します。値が小さすぎるとインストールは失敗します。
3: 事前キャッシュされたイメージに十分なディスク領域を確保するために、パーティションの最小サイズを 500 GB に指定します。値が小さすぎると、インストール後のデプロイメントが失敗します。

15.2.1.2. GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定

GitOps Zero Touch Provisioning (ZTP) ワークフローを使用している場合は、次の手順を実行して、シードクラスターとターゲットクラスターの両方に個別のディスクパーティションを作成し、/var/lib/containers パーティションを共有します。

重要

インストール時にこの手順を完了する必要があります。

前提条件

Butane をインストールしている。詳細は、「Butane のインストール」を参照してください。

手順

storage.bu ファイルを作成します。

variant: fcos
version: 1.3.0
storage:
  disks:
  - device: /dev/disk/by-path/pci-<root_disk> 1
    wipe_table: false
    partitions:
    - label: var-lib-containers
      start_mib: <start_of_partition> 2
      size_mib: <partition_size> 3
  filesystems:
    - path: /var/lib/containers
      device: /dev/disk/by-partlabel/var-lib-containers
      format: xfs
      wipe_filesystem: true
      with_mount_unit: true
      mount_options:
        - defaults
        - prjquota

1: ルートディスクを指定します。
2: パーティションの開始を MiB 単位で指定します。値が小さすぎるとインストールは失敗します。
3: 事前キャッシュされたイメージに十分なディスク領域を確保するために、パーティションの最小サイズを 500 GB に指定します。値が小さすぎると、インストール後のデプロイメントが失敗します。

次のコマンドを実行して、storage.bu を Ignition ファイルに変換します。

$ butane storage.bu

出力例

{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:00:17.0-ata-1.0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}

出力を SiteConfig CR の .spec.clusters.nodes.ignitionConfigOverride フィールドにコピーします。

[...]
spec:
  clusters:
    - nodes:
        - hostName: <name>
          ignitionConfigOverride: '{"ignition":{"version":"3.2.0"},"storage":{"disks":[{"device":"/dev/disk/by-path/pci-0000:00:17.0-ata-1.0","partitions":[{"label":"var-lib-containers","sizeMiB":0,"startMiB":250000}],"wipeTable":false}],"filesystems":[{"device":"/dev/disk/by-partlabel/var-lib-containers","format":"xfs","mountOptions":["defaults","prjquota"],"path":"/var/lib/containers","wipeFilesystem":true}]},"systemd":{"units":[{"contents":"# Generated by Butane\n[Unit]\nRequires=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\nAfter=systemd-fsck@dev-disk-by\\x2dpartlabel-var\\x2dlib\\x2dcontainers.service\n\n[Mount]\nWhere=/var/lib/containers\nWhat=/dev/disk/by-partlabel/var-lib-containers\nType=xfs\nOptions=defaults,prjquota\n\n[Install]\nRequiredBy=local-fs.target","enabled":true,"name":"var-lib-containers.mount"}]}}'
[...]

検証

インストール中またはインストール後に、次のコマンドを実行して、ハブクラスターで BareMetalHost オブジェクトにアノテーションが表示されていることを確認します。

$ oc get bmh -n my-sno-ns my-sno -ojson | jq '.metadata.annotations["bmac.agent-install.openshift.io/ignition-config-overrides"]'

出力例

"{\"ignition\":{\"version\":\"3.2.0\"},\"storage\":{\"disks\":[{\"device\":\"/dev/disk/by-path/pci-0000:00:17.0-ata-1.0\",\"partitions\":[{\"label\":\"var-lib-containers\",\"sizeMiB\":0,\"startMiB\":250000}],\"wipeTable\":false}],\"filesystems\":[{\"device\":\"/dev/disk/by-partlabel/var-lib-containers\",\"format\":\"xfs\",\"mountOptions\":[\"defaults\",\"prjquota\"],\"path\":\"/var/lib/containers\",\"wipeFilesystem\":true}]},\"systemd\":{\"units\":[{\"contents\":\"# Generated by Butane\\n[Unit]\\nRequires=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\nAfter=systemd-fsck@dev-disk-by\\\\x2dpartlabel-var\\\\x2dlib\\\\x2dcontainers.service\\n\\n[Mount]\\nWhere=/var/lib/containers\\nWhat=/dev/disk/by-partlabel/var-lib-containers\\nType=xfs\\nOptions=defaults,prjquota\\n\\n[Install]\\nRequiredBy=local-fs.target\",\"enabled\":true,\"name\":\"var-lib-containers.mount\"}]}}"

インストール後、次のコマンドを実行して、シングルノード OpenShift ディスクのステータスを確認します。

# lsblk

出力例

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda      8:0    0 446.6G  0 disk
├─sda1   8:1    0     1M  0 part
├─sda2   8:2    0   127M  0 part
├─sda3   8:3    0   384M  0 part /boot
├─sda4   8:4    0 243.6G  0 part /var
│                                /sysroot/ostree/deploy/rhcos/var
│                                /usr
│                                /etc
│                                /
│                                /sysroot
└─sda5   8:5    0 202.5G  0 part /var/lib/containers

# df -h

出力例

Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        4.0M     0  4.0M   0% /dev
tmpfs           126G   84K  126G   1% /dev/shm
tmpfs            51G   93M   51G   1% /run
/dev/sda4       244G  5.2G  239G   3% /sysroot
tmpfs           126G  4.0K  126G   1% /tmp
/dev/sda5       203G  119G   85G  59% /var/lib/containers
/dev/sda3       350M  110M  218M  34% /boot
tmpfs            26G     0   26G   0% /run/user/1000

関連情報

Butane のインストール

15.2.2. イメージベースアップグレード用の Operator のインストール

Lifecycle Agent と OADP Operator をインストールして、アップグレードに向けてクラスターを準備します。

GitOps 以外の方法で OADP Operator をインストールするには、「OADP Operator のインストール」を参照してください。

関連情報

15.2.2.1. CLI を使用した Lifecycle Agent のインストール

OpenShift CLI (oc) を使用して Lifecycle Agent をインストールできます。

前提条件

OpenShift CLI (oc) がインストールされている。
cluster-admin 権限を持つユーザーとしてログインしている。

手順

Lifecycle Agent の Namespace オブジェクト YAML ファイル (例: lcao-namespace.yaml) を作成します。
```
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-lifecycle-agent
  annotations:
    workload.openshift.io/allowed: management
```
1. 以下のコマンドを実行して Namespace CR を作成します。
```
$ oc create -f lcao-namespace.yaml
```

Lifecycle Agent の OperatorGroup オブジェクト YAML ファイル (例: lcao-operatorgroup.yaml) を作成します。

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-lifecycle-agent
  namespace: openshift-lifecycle-agent
spec:
  targetNamespaces:
  - openshift-lifecycle-agent

以下のコマンドを実行して OperatorGroup CR を作成します。
```
$ oc create -f lcao-operatorgroup.yaml
```

Subscription CR (例: lcao-subscription.yaml) を作成します。

apiVersion: operators.coreos.com/v1
kind: Subscription
metadata:
  name: openshift-lifecycle-agent-subscription
  namespace: openshift-lifecycle-agent
spec:
  channel: "stable"
  name: lifecycle-agent
  source: redhat-operators
  sourceNamespace: openshift-marketplace

以下のコマンドを実行して Subscription CR を作成します。
```
$ oc create -f lcao-subscription.yaml
```

検証

インストールが成功したことを確認するには、次のコマンドを実行して CSV リソースを調べます。

$ oc get csv -n openshift-lifecycle-agent

出力例

NAME                              DISPLAY                     VERSION               REPLACES                           PHASE
lifecycle-agent.v4.16.0           Openshift Lifecycle Agent   4.16.0                Succeeded

次のコマンドを実行して、Lifecycle Agent が起動して実行されていることを確認します。

$ oc get deploy -n openshift-lifecycle-agent

出力例

NAME                                 READY   UP-TO-DATE   AVAILABLE   AGE
lifecycle-agent-controller-manager   1/1     1            1           14s

15.2.2.2. Web コンソールを使用した Lifecycle Agent のインストール

OpenShift Container Platform Web コンソールを使用して、Lifecycle Agent をインストールできます。

前提条件

cluster-admin 権限を持つユーザーとしてログインしている。

手順

OpenShift Container Platform Web コンソールで、Operators OperatorHub ページに移動します。
利用可能な Operator のリストから Lifecycle Agent を検索し、Install をクリックします。
Install Operator ページの A specific namespace on the cluster の下で openshift-lifecycle-agent を選択します。
Install をクリックします。

検証

インストールが正常に行われたことを確認するには、以下を実行します。
1. Operators Installed Operators をクリックします。
2. Lifecycle Agent が、InstallSucceeded ステータス で openshift-lifecycle-agent プロジェクトにリストされていることを確認します。
  注記
  インストール時に、Operator は Failed ステータスを表示する可能性があります。インストールが後に InstallSucceeded メッセージを出して正常に実行される場合は、Failed メッセージを無視できます。

Operator が正常にインストールされていない場合、以下を実行します。

Operators Installed Operators をクリックし、Operator Subscriptions タブおよび Install Plans タブの ステータス で障害やエラーがないか検査します。
Workloads Pods をクリックし、openshift-lifecycle-agent プロジェクト内の Pod のログを確認します。

15.2.2.3. GitOps ZTP を使用した Lifecycle Agent のインストール

イメージベースアップグレードを実行するには、GitOps Zero Touch Provisioning (ZTP) を使用して Lifecycle Agent をインストールします。

手順

ztp-site-generate コンテナーイメージから次の CR を抽出し、source-cr ディレクトリーにプッシュします。

LcaSubscriptionNS.yaml ファイルの例

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-lifecycle-agent
  annotations:
    workload.openshift.io/allowed: management
    ran.openshift.io/ztp-deploy-wave: "2"
  labels:
    kubernetes.io/metadata.name: openshift-lifecycle-agent

LcaSubscriptionOperGroup.yaml ファイルの例

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: lifecycle-agent-operatorgroup
  namespace: openshift-lifecycle-agent
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
spec:
  targetNamespaces:
    - openshift-lifecycle-agent

LcaSubscription.yaml ファイルの例

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: lifecycle-agent
  namespace: openshift-lifecycle-agent
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
spec:
  channel: "stable"
  name: lifecycle-agent
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

ディレクトリー構造の例

├── kustomization.yaml
├── sno
│   ├── example-cnf.yaml
│   ├── common-ranGen.yaml
│   ├── group-du-sno-ranGen.yaml
│   ├── group-du-sno-validator-ranGen.yaml
│   └── ns.yaml
├── source-crs
│   ├── LcaSubscriptionNS.yaml
│   ├── LcaSubscriptionOperGroup.yaml
│   ├── LcaSubscription.yaml

共通の PolicyGenTemplate に CR を追加します。

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "example-common-latest"
  namespace: "ztp-common"
spec:
  bindingRules:
    common: "true"
    du-profile: "latest"
  sourceFiles:
    - fileName: LcaSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: LcaSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: LcaSubscription.yaml
      policyName: "subscriptions-policy"
[...]

15.2.2.4. GitOps ZTP を使用した OADP Operator のインストールと設定

アップグレードを開始する前に、GitOps ZTP を使用して OADP Operator をインストールして設定します。

手順

ztp-site-generate コンテナーイメージから次の CR を抽出し、source-cr ディレクトリーにプッシュします。

OadpSubscriptionNS.yaml ファイルの例

apiVersion: v1
kind: Namespace
metadata:
  name: openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
  labels:
    kubernetes.io/metadata.name: openshift-adp

OadpSubscriptionOperGroup.yaml ファイルの例

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: redhat-oadp-operator
  namespace: openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
spec:
  targetNamespaces:
  - openshift-adp

OadpSubscription.yaml ファイルの例

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: redhat-oadp-operator
  namespace: openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
spec:
  channel: stable-1.4
  name: redhat-oadp-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  installPlanApproval: Manual
status:
  state: AtLatestKnown

OadpOperatorStatus.yaml ファイルの例

apiVersion: operators.coreos.com/v1
kind: Operator
metadata:
  name: redhat-oadp-operator.openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "2"
status:
  components:
    refs:
    - kind: Subscription
      namespace: openshift-adp
      conditions:
      - type: CatalogSourcesUnhealthy
        status: "False"
    - kind: InstallPlan
      namespace: openshift-adp
      conditions:
      - type: Installed
        status: "True"
    - kind: ClusterServiceVersion
      namespace: openshift-adp
      conditions:
      - type: Succeeded
        status: "True"
        reason: InstallSucceeded

ディレクトリー構造の例

├── kustomization.yaml
├── sno
│   ├── example-cnf.yaml
│   ├── common-ranGen.yaml
│   ├── group-du-sno-ranGen.yaml
│   ├── group-du-sno-validator-ranGen.yaml
│   └── ns.yaml
├── source-crs
│   ├── OadpSubscriptionNS.yaml
│   ├── OadpSubscriptionOperGroup.yaml
│   ├── OadpSubscription.yaml
│   ├── OadpOperatorStatus.yaml

共通の PolicyGenTemplate に CR を追加します。

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "example-common-latest"
  namespace: "ztp-common"
spec:
  bindingRules:
    common: "true"
    du-profile: "latest"
  sourceFiles:
    - fileName: OadpSubscriptionNS.yaml
      policyName: "subscriptions-policy"
    - fileName: OadpSubscriptionOperGroup.yaml
      policyName: "subscriptions-policy"
    - fileName: OadpSubscription.yaml
      policyName: "subscriptions-policy"
    - fileName: OadpOperatorStatus.yaml
      policyName: "subscriptions-policy"
[...]

ターゲットクラスター専用の DataProtectionApplication CR と S3 シークレットを作成します。

ztp-site-generate コンテナーイメージから次の CR を抽出し、source-cr ディレクトリーにプッシュします。
DataProtectionApplication.yaml ファイルの例
```
apiVersion: oadp.openshift.io/v1alpha1
kind: DataProtectionApplication
metadata:
  name: dataprotectionapplication
  namespace: openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "100"
spec:
  configuration:
    restic:
      enable: false 1
    velero:
      defaultPlugins:
        - aws
        - openshift
      resourceTimeout: 10m
  backupLocations:
    - velero:
        config:
          profile: "default"
          region: minio
          s3Url: $url
          insecureSkipTLSVerify: "true"
          s3ForcePathStyle: "true"
        provider: aws
        default: true
        credential:
          key: cloud
          name: cloud-credentials
        objectStorage:
          bucket: $bucketName 2
          prefix: $prefixName 3
status:
  conditions:
  - reason: Complete
    status: "True"
    type: Reconciled
```
1
永続ボリュームの内容はアップグレード後に保持され、再利用されるため、イメージベースアップグレードでは spec.configuration.restic.enable フィールドを false に設定する必要があります。
2 3
バケットは、S3 バックエンドで作成されるバケット名を定義します。接頭辞は、バケット内に自動的に作成されるサブディレクトリーの名前を定義します。バケットと接頭辞の組み合わせは、それらの間の干渉を避けるために、各ターゲットクラスターごとに一意である必要があります。各ターゲットクラスターに一意のストレージディレクトリーを確保するには、RHACM ハブテンプレート関数を使用できます (例: prefix: {{hub .ManagedClusterName hub}})。
OadpSecret.yaml ファイルの例
```
apiVersion: v1
kind: Secret
metadata:
  name: cloud-credentials
  namespace: openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "100"
type: Opaque
```
OadpBackupStorageLocationStatus.yaml ファイルの例
```
apiVersion: velero.io/v1
kind: BackupStorageLocation
metadata:
  namespace: openshift-adp
  annotations:
    ran.openshift.io/ztp-deploy-wave: "100"
status:
  phase: Available
```
OadpBackupStorageLocationStatus.yaml CR は、OADP によって作成されたバックアップストレージの場所の可用性を確認します。

オーバーライドを使用して、サイトの PolicyGenTemplate に CR を追加します。

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: "example-cnf"
  namespace: "ztp-site"
spec:
  bindingRules:
    sites: "example-cnf"
    du-profile: "latest"
  mcp: "master"
  sourceFiles:
    ...
    - fileName: OadpSecret.yaml
      policyName: "config-policy"
      data:
        cloud: <your_credentials> 1
    - fileName: DataProtectionApplication.yaml
      policyName: "config-policy"
      spec:
        backupLocations:
          - velero:
              config:
                region: minio
                s3Url: <your_S3_URL> 2
                profile: "default"
                insecureSkipTLSVerify: "true"
                s3ForcePathStyle: "true"
              provider: aws
              default: true
              credential:
                key: cloud
                name: cloud-credentials
              objectStorage:
                bucket: <your_bucket_name> 3
                prefix: <cluster_name> 4
    - fileName: OadpBackupStorageLocationStatus.yaml
      policyName: "config-policy"

1: S3 ストレージバックエンドの認証情報を指定します。
2: S3 互換バケットの URL を指定します。
3 4: bucket は、S3 バックエンドで作成されるバケット名を定義します。prefix は、bucket 内に自動的に作成されるサブディレクトリーの名前を定義します。bucket と prefix の組み合わせは、それらの間の干渉を避けるために、各ターゲットクラスターごとに一意である必要があります。各ターゲットクラスターに一意のストレージディレクトリーを確保するには、RHACM ハブテンプレート関数を使用できます (例: prefix: {{hub .ManagedClusterName hub}})。

15.2.3. Lifecycle Agent を使用したイメージベースアップグレード用のシードイメージの生成

Lifecycle Agent を使用して、SeedGenerator カスタムリソース (CR) でシードイメージを生成します。

15.2.3.1. シードイメージの設定

シードイメージは、同じハードウェアと同様の設定を持つシングルノードの OpenShift クラスターのセットを対象とします。つまり、シードイメージには、シードクラスターがターゲットクラスターと共有するすべてのコンポーネントと設定が含まれている必要があります。したがって、シードクラスターから生成されたシードイメージには、クラスター固有の設定を含めることはできません。

次の表は、シードイメージに含めるべき、および含めるべきでないコンポーネント、リソース、設定を示しています。

表15.2 シードイメージの設定
Cluster configuration	シードイメージに含める
パフォーマンスプロファイル	はい
ターゲットクラスターの `MachineConfig` リソース	はい
IP バージョン ^[1]	はい
Lifecycle Agent と OADP Operator を含む Day 2 Operator のセット	はい
切断されたレジストリー設定 ^[2]	はい
有効なプロキシー設定 ^[3]	はい
FIPS 設定	はい
ターゲットクラスターのサイズに一致する、コンテナーストレージ用のプライマリーディスク上の専用パーティション	はい
ローカルボリューム LSO の `LocalVolume` で使用される `StorageClass` LSO の `LocalVolume` LVMS の `LVMCluster` CR	☓
OADP `DataProtectionApplication` CR	☓

このリリースではデュアルスタックネットワークはサポートされていません。
シードクラスターが非接続環境にインストールされている場合は、ターゲットクラスターも非接続環境にインストールする必要があります。
プロキシー設定は同じである必要はありません。

15.2.3.1.1. RAN DU プロファイルを使用したシードイメージの設定

次の表は、RAN DU プロファイルを使用する際にシードイメージに含めるべき、および含めるべきでないコンポーネント、リソース、設定を示しています。

表15.3 RAN DU プロファイルを使用したシードイメージの設定
リソース	シードイメージに含める
Day 0 インストールの一部として適用されるすべての追加マニフェスト	はい
すべての Day 2 Operator サブスクリプション	はい
`ClusterLogging.yaml`	はい
`DisableOLMPprof.yaml`	はい
`TunedPerformancePatch.yaml`	はい
`PerformanceProfile.yaml`	はい
`SriovOperatorConfig.yaml`	はい
`DisableSnoNetworkDiag.yaml`	はい
`StorageClass.yaml`	☓ (`StorageLV.yaml` で使用されている場合)
`StorageLV.yaml`	☓
`StorageLVMCluster.yaml`	☓

表15.4 追加のマニフェスト用の RAN DU プロファイルを使用したシードイメージ設定
リソース	追加マニフェストとして適用
`ClusterLogForwarder.yaml`	はい
`ReduceMonitoringFootprint.yaml`	はい
`SriovFecClusterConfig.yaml`	はい
`PtpOperatorConfigForEvent.yaml`	はい
`DefaultCatsrc.yaml`	はい
`PtpConfig.yaml`	ターゲットクラスターのインターフェイスがシードクラスターと共通である場合は、それらをシードイメージに含めることができます。それ以外の場合は、追加のマニフェストとして適用します。
`SriovNetwork.yamlSriovNetworkNodePolicy.yaml`	namespace を含む設定がシードクラスターとターゲットクラスターの両方でまったく同じである場合は、それらをシードイメージに含めることができます。それ以外の場合は、追加のマニフェストとして適用します。

15.2.3.2. Lifecycle Agent を使用したシードイメージの生成

Lifecycle Agent を使用して、SeedGenerator CR でシードイメージを生成します。Operator は、必要なシステム設定を確認し、シードイメージを生成する前に必要なシステムクリーンアップを実行して、イメージ生成を開始します。シードイメージの生成には、次のタスクが含まれます。

クラスター Operator の停止
シードイメージ設定の準備
シードイメージの生成および SeedGenerator CR で指定されたイメージリポジトリーへのシードイメージのプッシュ
クラスター Operator の復元
期限切れのシードクラスター証明書
シードクラスター用の新しい証明書の生成
シードクラスター上の SeedGenerator CR の復元と更新

前提条件

シードクラスターに共有コンテナーディレクトリーを設定している。
OADP Operator およびライフサイクルエージェントの最小バージョンをシードクラスターにインストールしました。
永続ボリュームがシードクラスターで設定されていないことを確認します。
ローカルストレージ Operator が使用される場合は、LocalVolume CR がシードクラスターに存在しないことを確認します。
LVM ストレージが使用されている場合は、LVMCluster CR がシードクラスターに存在しないことを確認します。
OADP が使用されている場合、DataProtectionApplication CR がシードクラスターに存在しないことを確認します。

手順

クラスターをハブからデタッチして、シードイメージに含まれてはならない RHACM 固有のリソースをシードクラスターから削除します。
1. 次のコマンドを実行してシードクラスターを手動でデタッチします。
```
$ oc delete managedcluster sno-worker-example
```
  1. ManagedCluster CR が削除されるまで待ちます。CR が削除されたら、適切な SeedGenerator CR を作成します。Lifecycle Agent は RHACM アーティファクトをクリーンアップします。
2. GitOps ZTP を使用している場合は、シードクラスターの SiteConfig CR を kustomization.yaml から削除してクラスターをデタッチします。
  1. 複数の SiteConfig CR を参照する kustomization.yaml ファイルがある場合は、シードクラスターの SiteConfig CR を kustomization.yaml から削除します。
    apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: #- example-seed-sno1.yaml - example-target-sno2.yaml - example-target-sno3.yaml
  2. 1 つの SiteConfig CR を参照する kustomization.yaml がある場合は、シードクラスターの SiteConfig CR を kustomization.yaml から削除し、generators: {} 行を追加します。
    apiVersion: kustomize.config.k8s.io/v1beta1 kind: Kustomization generators: {}
  3. Git リポジトリーで kustomization.yaml の変更をコミットし、変更をリポジトリーにプッシュします。
    ArgoCD パイプラインは変更を検出し、マネージドクラスターを削除します。
シードイメージをレジストリーにプッシュできるように、Secret オブジェクトを作成します。
1. 次のコマンドを実行して認証ファイルを作成します。
```
$ MY_USER=myuserid
$ AUTHFILE=/tmp/my-auth.json
$ podman login --authfile ${AUTHFILE} -u ${MY_USER} quay.io/${MY_USER}
```
```
$ base64 -w 0 ${AUTHFILE} ; echo
```
2. 出力を、openshift-lifecycle-agent namespace の seedgen という名前の Secret YAML ファイルの seedAuth フィールドにコピーします。
```
apiVersion: v1
kind: Secret
metadata:
  name: seedgen 1
  namespace: openshift-lifecycle-agent
type: Opaque
data:
  seedAuth: <encoded_AUTHFILE> 2
```
  1
  Secret リソースには、name: seedgen および namespace: openshift-lifecycle-agent フィールドが必要です。
  2
  生成されたシードイメージをプッシュするためのレジストリーへの書き込みアクセス用 base64 エンコードされた authfile を指定します。
3. 以下のコマンドを実行して Secret を適用します。
```
$ oc apply -f secretseedgenerator.yaml
```
SeedGenerator CR を作成します。
```
apiVersion: lca.openshift.io/v1
kind: SeedGenerator
metadata:
  name: seedimage 1
spec:
  seedImage: <seed_container_image> 2
```
1
SeedGenerator CR の名前は seedimage にする必要があります。
2
コンテナーイメージの URL を指定します (例: quay.io/example/seed-container-image:<tag>)。<seed_cluster_name>:<ocp_version> 形式を使用することを推奨します。
次のコマンドを実行してシードイメージを生成します。
```
$ oc apply -f seedgenerator.yaml
```
重要
Lifecycle Agent がシードイメージを生成している間、クラスターが再起動し、API 機能が失われます。SeedGenerator CR を適用すると、kubelet と CRI-O の操作が停止し、イメージ生成が開始されます。

より多くのシードイメージを生成する場合は、シードイメージを生成するバージョンで新しいシードクラスターをプロビジョニングする必要があります。

検証

クラスターが回復して使用可能になったら、次のコマンドを実行して SeedGenerator CR のステータスを確認できます。

$ oc get seedgenerator -o yaml

出力例

status:
  conditions:
  - lastTransitionTime: "2024-02-13T21:24:26Z"
    message: Seed Generation completed
    observedGeneration: 1
    reason: Completed
    status: "False"
    type: SeedGenInProgress
  - lastTransitionTime: "2024-02-13T21:24:26Z"
    message: Seed Generation completed
    observedGeneration: 1
    reason: Completed
    status: "True"
    type: SeedGenCompleted 1
  observedGeneration: 1

1: シードイメージの生成が完了しました。

関連情報

15.2.4. Lifecycle Agent を使用したイメージベースアップグレード用の ConfigMap オブジェクトの作成

Lifecycle Agent では、イメージベースアップグレード用に処理するために、すべての OADP リソース、追加のマニフェスト、およびカスタムカタログソースが ConfigMap オブジェクトにラップされている必要があります。

15.2.4.1. Lifecycle Agent を使用したイメージベースアップグレード用の OADP ConfigMap オブジェクトの作成

アップグレード中にリソースをバックアップおよび復元するために使用される OADP リソースを作成します。

前提条件

互換性のあるシードクラスターからシードイメージを生成している。
OADP バックアップおよび復元リソースを作成している。
stateroot 間で共有されるコンテナーイメージ用に、ターゲットクラスター上に個別のパーティションを作成している。詳細は、「イメージベースアップグレード用の共有コンテナーパーティションの設定」を参照してください。
シードイメージで使用されるバージョンと互換性のある Lifecycle Agent のバージョンをデプロイしている。
OADP Operator、DataProtectionApplication CR、およびそのシークレットをターゲットクラスターにインストールしている。
S3 互換のストレージソリューションと、適切な認証情報が設定されたすぐに使用できるバケットを作成している。詳細は、「OADP のインストールについて」を参照してください。

手順

OADP Operator がインストールされているのと同じ namespace (openshift-adp) に、プラットフォームアーティファクトの OADP Backup CR および Restore CR を作成します。

ターゲットクラスターが RHACM によって管理されている場合は、RHACM アーティファクトをバックアップおよび復元するために次の YAML ファイルを追加します。

RHACM 用の PlatformBackupRestore.yaml

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: acm-klusterlet
  annotations:
    lca.openshift.io/apply-label: "apps/v1/deployments/open-cluster-management-agent/klusterlet,v1/secrets/open-cluster-management-agent/bootstrap-hub-kubeconfig,rbac.authorization.k8s.io/v1/clusterroles/klusterlet,v1/serviceaccounts/open-cluster-management-agent/klusterlet,scheduling.k8s.io/v1/priorityclasses/klusterlet-critical,rbac.authorization.k8s.io/v1/clusterroles/open-cluster-management:klusterlet-admin-aggregate-clusterrole,rbac.authorization.k8s.io/v1/clusterrolebindings/klusterlet,operator.open-cluster-management.io/v1/klusterlets/klusterlet,apiextensions.k8s.io/v1/customresourcedefinitions/klusterlets.operator.open-cluster-management.io,v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials" 1
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  includedNamespaces:
  - open-cluster-management-agent
  includedClusterScopedResources:
  - klusterlets.operator.open-cluster-management.io
  - clusterroles.rbac.authorization.k8s.io
  - clusterrolebindings.rbac.authorization.k8s.io
  - priorityclasses.scheduling.k8s.io
  includedNamespaceScopedResources:
  - deployments
  - serviceaccounts
  - secrets
  excludedNamespaceScopedResources: []
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: acm-klusterlet
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "1"
spec:
  backupName:
    acm-klusterlet

1: multiclusterHub CR に .spec.imagePullSecret が定義されておらず、ハブクラスターの open-cluster-management-agent namespace にシークレットが存在しない場合は、v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials を削除します。

LVM Storage を介してクラスター上に永続ボリュームを作成した場合は、LVM Storage アーティファクトに次の YAML ファイルを追加します。

LVM Storage 用の PlatformBackupRestoreLvms.yaml

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: lvmcluster
  namespace: openshift-adp
spec:
  includedNamespaces:
    - openshift-storage
  includedNamespaceScopedResources:
    - lvmclusters
    - lvmvolumegroups
    - lvmvolumegroupnodestatuses
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: lvmcluster
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "2" 1
spec:
  backupName:
    lvmcluster

1: lca.openshift.io/apply-wave の値は、アプリケーションの Restore CR で指定された値よりも低くする必要があります。

アップグレード後にアプリケーションを復元する必要がある場合は、openshift-adp namespace にアプリケーションの OADP Backup CR および Restore CR を作成します。

openshift-adp namespace にクラスタースコープのアプリケーションアーティファクト用の OADP CR を作成します。

LSO および LVM Storage のクラスタースコープアプリケーションアーティファクトの OADP CR の例

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    lca.openshift.io/apply-label: "apiextensions.k8s.io/v1/customresourcedefinitions/test.example.com,security.openshift.io/v1/securitycontextconstraints/test,rbac.authorization.k8s.io/v1/clusterroles/test-role,rbac.authorization.k8s.io/v1/clusterrolebindings/system:openshift:scc:test" 1
  name: backup-app-cluster-resources
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  includedClusterScopedResources:
  - customresourcedefinitions
  - securitycontextconstraints
  - clusterrolebindings
  - clusterroles
  excludedClusterScopedResources:
  - Namespace
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: test-app-cluster-resources
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "3" 2
spec:
  backupName:
    backup-app-cluster-resources

1: サンプルのリソース名を実際のリソースに置き換えます。
2: lca.openshift.io/apply-wave の値は、プラットフォームの Restore CR の値よりも大きく、アプリケーションの namespace スコープの Restore CR の値よりも小さくする必要があります。

namespace スコープのアプリケーションアーティファクト用の OADP CR を作成します。

LSO が使用される場合の OADP CR の namespace スコープのアプリケーションアーティファクトの例

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: backup-app
  namespace: openshift-adp
spec:
  includedNamespaces:
  - test
  includedNamespaceScopedResources:
  - secrets
  - persistentvolumeclaims
  - deployments
  - statefulsets
  - configmaps
  - cronjobs
  - services
  - job
  - poddisruptionbudgets
  - <application_custom_resources> 1
  excludedClusterScopedResources:
  - persistentVolumes
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: test-app
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "4"
spec:
  backupName:
    backup-app

1: アプリケーションのカスタムリソースを定義します。

LVM Storage が使用されている場合の OADP CR namespace スコープのアプリケーションアーティファクトの例

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: backup-app
  namespace: openshift-adp
spec:
  includedNamespaces:
  - test
  includedNamespaceScopedResources:
  - secrets
  - persistentvolumeclaims
  - deployments
  - statefulsets
  - configmaps
  - cronjobs
  - services
  - job
  - poddisruptionbudgets
  - <application_custom_resources> 1
  includedClusterScopedResources:
  - persistentVolumes 2
  - logicalvolumes.topolvm.io 3
  - volumesnapshotcontents 4
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: test-app
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "4"
spec:
  backupName:
    backup-app
  restorePVs: true
  restoreStatus:
    includedResources:
    - logicalvolumes 5

1: アプリケーションのカスタムリソースを定義します。
2: 必須フィールド。
3: 必須フィールド
4: LVM Storage ボリュームスナップショットを使用する場合はオプションになります。
5: 必須フィールド。

重要

アプリケーションの同じバージョンが、OpenShift Container Platform の現在のリリースとターゲットリリースの両方で機能する必要があります。

次のコマンドを実行して、OADP CR の ConfigMap オブジェクトを作成します。

$ oc create configmap oadp-cm-example --from-file=example-oadp-resources.yaml=<path_to_oadp_crs> -n openshift-adp

次のコマンドを実行して、ImageBasedUpgrade CR にパッチを適用します。

$ oc patch imagebasedupgrades.lca.openshift.io upgrade \
  -p='{"spec": {"oadpContent": [{"name": "oadp-cm-example", "namespace": "openshift-adp"}]}}' \
  --type=merge -n openshift-lifecycle-agent

関連情報

15.2.4.2. Lifecycle Agent を使用したイメージベースアップグレード用の追加マニフェストの ConfigMap オブジェクトの作成

ターゲットクラスターに適用する追加のマニフェストを作成します。

手順

SR-IOV などの追加マニフェストを含む YAML ファイルを作成します。

SR-IOV リソースの例

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: "example-sriov-node-policy"
  namespace: openshift-sriov-network-operator
spec:
  deviceType: vfio-pci
  isRdma: false
  nicSelector:
    pfNames: [ens1f0]
  nodeSelector:
    node-role.kubernetes.io/master: ""
  mtu: 1500
  numVfs: 8
  priority: 99
  resourceName: example-sriov-node-policy
---
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: "example-sriov-network"
  namespace: openshift-sriov-network-operator
spec:
  ipam: |-
    {
    }
  linkState: auto
  networkNamespace: sriov-namespace
  resourceName: example-sriov-node-policy
  spoofChk: "on"
  trust: "off"

以下のコマンドを実行して ConfigMap オブジェクトを作成します。

$ oc create configmap example-extra-manifests-cm --from-file=example-extra-manifests.yaml=<path_to_extramanifest> -n openshift-lifecycle-agent

次のコマンドを実行して、ImageBasedUpgrade CR にパッチを適用します。

$ oc patch imagebasedupgrades.lca.openshift.io upgrade \
  -p='{"spec": {"extraManifests": [{"name": "example-extra-manifests-cm", "namespace": "openshift-lifecycle-agent"}]}}' \
  --type=merge -n openshift-lifecycle-agent

15.2.4.3. Lifecycle Agent を使用したイメージベースのアップグレード用のカスタムカタログソースの ConfigMap オブジェクトの作成

カタログソースの ConfigMap オブジェクトを生成し、それを ImageBasedUpgrade CR の spec.extraManifest フィールドに追加することで、アップグレード後もカスタムカタログソースを保持できます。カタログソースの詳細は、「カタログソース」を参照してください。

手順

CatalogSource CR を含む YAML ファイルを作成します。

apiVersion: operators.coreos.com/v1
kind: CatalogSource
metadata:
  name: example-catalogsources
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  displayName: disconnected-redhat-operators
  image: quay.io/example-org/example-catalog:v1

以下のコマンドを実行して ConfigMap オブジェクトを作成します。

$ oc create configmap example-catalogsources-cm --from-file=example-catalogsources.yaml=<path_to_catalogsource_cr> -n openshift-lifecycle-agent

次のコマンドを実行して、ImageBasedUpgrade CR にパッチを適用します。

$ oc patch imagebasedupgrades.lca.openshift.io upgrade \
  -p='{"spec": {"extraManifests": [{"name": "example-catalogsources-cm", "namespace": "openshift-lifecycle-agent"}]}}' \
  --type=merge -n openshift-lifecycle-agent

関連情報

15.2.5. GitOps ZTP を使用した Lifecycle Agent によるイメージベースアップグレード用の ConfigMap オブジェクトの作成

イメージベースアップグレードに備えて、ConfigMap オブジェクトにラップされた OADP リソース、追加のマニフェスト、カスタムカタログソースを作成します。

15.2.5.1. GitOps ZTP を使用したイメージベースアップグレード用の OADP リソースの作成

アップグレード後にアプリケーションを復元できるように OADP リソースを準備します。

前提条件

GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
cluster-admin 権限を持つユーザーとしてログインしている。
互換性のあるシードクラスターからシードイメージを生成している。
stateroot 間で共有されるコンテナーイメージ用に、ターゲットクラスター上に個別のパーティションを作成している。詳細は、「GitOps ZTP を使用した場合の ostree stateroot 間の共有コンテナーパーティションの設定」を参照してください。
シードイメージで使用されるバージョンと互換性のある Lifecycle Agent のバージョンをデプロイしている。
OADP Operator、DataProtectionApplication CR、およびそのシークレットをターゲットクラスターにインストールしている。
S3 互換のストレージソリューションと、適切な認証情報が設定されたすぐに使用できるバケットを作成している。詳細は、「GitOps ZTP を使用した OADP Operator のインストールと設定」を参照してください。

手順

ArgoCD ポリシーアプリケーションで使用する Git リポジトリーに次のディレクトリー構造が含まれていることを確認します。

├── source-crs/
│   ├── ibu/
│   │    ├── ImageBasedUpgrade.yaml
│   │    ├── PlatformBackupRestore.yaml
│   │    ├── PlatformBackupRestoreLvms.yaml
├── ...
├── ibu-upgrade-ranGen.yaml
├── kustomization.yaml

重要

ibu-upgrade-ranGen.yaml マニフェストを参照するには、kustomization.yaml ファイルを前に示したのと同じディレクトリー構造に配置する必要があります。

source-crs/ibu/PlatformBackupRestore.yaml ファイルは、ZTP コンテナーイメージで提供されます。

PlatformBackupRestore.yaml

apiVersion: velero.io/v1
kind: Backup
metadata:
  name: acm-klusterlet
  annotations:
    lca.openshift.io/apply-label: "apps/v1/deployments/open-cluster-management-agent/klusterlet,v1/secrets/open-cluster-management-agent/bootstrap-hub-kubeconfig,rbac.authorization.k8s.io/v1/clusterroles/klusterlet,v1/serviceaccounts/open-cluster-management-agent/klusterlet,scheduling.k8s.io/v1/priorityclasses/klusterlet-critical,rbac.authorization.k8s.io/v1/clusterroles/open-cluster-management:klusterlet-admin-aggregate-clusterrole,rbac.authorization.k8s.io/v1/clusterrolebindings/klusterlet,operator.open-cluster-management.io/v1/klusterlets/klusterlet,apiextensions.k8s.io/v1/customresourcedefinitions/klusterlets.operator.open-cluster-management.io,v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials" 1
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  includedNamespaces:
  - open-cluster-management-agent
  includedClusterScopedResources:
  - klusterlets.operator.open-cluster-management.io
  - clusterroles.rbac.authorization.k8s.io
  - clusterrolebindings.rbac.authorization.k8s.io
  - priorityclasses.scheduling.k8s.io
  includedNamespaceScopedResources:
  - deployments
  - serviceaccounts
  - secrets
  excludedNamespaceScopedResources: []
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: acm-klusterlet
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "1"
spec:
  backupName:
    acm-klusterlet

1: multiclusterHub CR に .spec.imagePullSecret が定義されておらず、ハブクラスターの open-cluster-management-agent namespace にシークレットが存在しない場合は、v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials を削除します。

LVM Storage を使用して永続ボリュームを作成する場合は、ZTP コンテナーイメージで提供される source-crs/ibu/PlatformBackupRestoreLvms.yaml を使用して、LVM Storage リソースをバックアップできます。

PlatformBackupRestoreLvms.yaml

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: lvmcluster
  namespace: openshift-adp
spec:
  includedNamespaces:
    - openshift-storage
  includedNamespaceScopedResources:
    - lvmclusters
    - lvmvolumegroups
    - lvmvolumegroupnodestatuses
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: lvmcluster
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "2" 1
spec:
  backupName:
    lvmcluster

1: lca.openshift.io/apply-wave の値は、アプリケーションの Restore CR で指定された値よりも低くする必要があります。

アップグレード後にアプリケーションを復元する必要がある場合は、openshift-adp namespace にアプリケーションの OADP Backup CR および Restore CR を作成します。

openshift-adp namespace にクラスタースコープのアプリケーションアーティファクト用の OADP CR を作成します。

LSO および LVM Storage のクラスタースコープアプリケーションアーティファクトの OADP CR の例

apiVersion: velero.io/v1
kind: Backup
metadata:
  annotations:
    lca.openshift.io/apply-label: "apiextensions.k8s.io/v1/customresourcedefinitions/test.example.com,security.openshift.io/v1/securitycontextconstraints/test,rbac.authorization.k8s.io/v1/clusterroles/test-role,rbac.authorization.k8s.io/v1/clusterrolebindings/system:openshift:scc:test" 1
  name: backup-app-cluster-resources
  labels:
    velero.io/storage-location: default
  namespace: openshift-adp
spec:
  includedClusterScopedResources:
  - customresourcedefinitions
  - securitycontextconstraints
  - clusterrolebindings
  - clusterroles
  excludedClusterScopedResources:
  - Namespace
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: test-app-cluster-resources
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "3" 2
spec:
  backupName:
    backup-app-cluster-resources

1: サンプルのリソース名を実際のリソースに置き換えます。
2: lca.openshift.io/apply-wave の値は、プラットフォームの Restore CR の値よりも大きく、アプリケーションの namespace スコープの Restore CR の値よりも小さくする必要があります。

namespace スコープのアプリケーションアーティファクト用の OADP CR を source-crs/custom-crs ディレクトリーに作成します。

LSO が使用される場合の OADP CR の namespace スコープのアプリケーションアーティファクトの例

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: backup-app
  namespace: openshift-adp
spec:
  includedNamespaces:
  - test
  includedNamespaceScopedResources:
  - secrets
  - persistentvolumeclaims
  - deployments
  - statefulsets
  - configmaps
  - cronjobs
  - services
  - job
  - poddisruptionbudgets
  - <application_custom_resources> 1
  excludedClusterScopedResources:
  - persistentVolumes
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: test-app
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "4"
spec:
  backupName:
    backup-app

1: アプリケーションのカスタムリソースを定義します。

LVM Storage が使用されている場合の OADP CR namespace スコープのアプリケーションアーティファクトの例

apiVersion: velero.io/v1
kind: Backup
metadata:
  labels:
    velero.io/storage-location: default
  name: backup-app
  namespace: openshift-adp
spec:
  includedNamespaces:
  - test
  includedNamespaceScopedResources:
  - secrets
  - persistentvolumeclaims
  - deployments
  - statefulsets
  - configmaps
  - cronjobs
  - services
  - job
  - poddisruptionbudgets
  - <application_custom_resources> 1
  includedClusterScopedResources:
  - persistentVolumes 2
  - logicalvolumes.topolvm.io 3
  - volumesnapshotcontents 4
---
apiVersion: velero.io/v1
kind: Restore
metadata:
  name: test-app
  namespace: openshift-adp
  labels:
    velero.io/storage-location: default
  annotations:
    lca.openshift.io/apply-wave: "4"
spec:
  backupName:
    backup-app
  restorePVs: true
  restoreStatus:
    includedResources:
    - logicalvolumes 5

1: アプリケーションのカスタムリソースを定義します。
2: 必須フィールド。
3: 必須フィールド
4: LVM Storage ボリュームスナップショットを使用する場合はオプションになります。
5: 必須フィールド。

重要

アプリケーションの同じバージョンが、OpenShift Container Platform の現在のリリースとターゲットリリースの両方で機能する必要があります。

ibu-upgrade-ranGen.yaml という新しい PolicyGenTemplate の oadp-cm-policy を通じて oadp-cm ConfigMap オブジェクトを作成します。

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: example-group-ibu
  namespace: "ztp-group"
spec:
  bindingRules:
    group-du-sno: ""
  mcp: "master"
  evaluationInterval:
    compliant: 10s
    noncompliant: 10s
  sourceFiles:
  - fileName: ConfigMapGeneric.yaml
    complianceType: mustonlyhave
    policyName: "oadp-cm-policy"
    metadata:
      name: oadp-cm
      namespace: openshift-adp

次の内容を含む kustomization.yaml を作成します。

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

generators: 1
- ibu-upgrade-ranGen.yaml

configMapGenerator: 2
- files:
  - source-crs/ibu/PlatformBackupRestore.yaml
  #- source-crs/custom-crs/ApplicationClusterScopedBackupRestore.yaml
  #- source-crs/custom-crs/ApplicationApplicationBackupRestoreLso.yaml
  name: oadp-cm
  namespace: ztp-group
generatorOptions:
  disableNameSuffixHash: true


patches: 3
- target:
    group: policy.open-cluster-management.io
    version: v1
    kind: Policy
    name: example-group-ibu-oadp-cm-policy
  patch: |-
    - op: replace
      path: /spec/policy-templates/0/objectDefinition/spec/object-templates/0/objectDefinition/data
      value: '{{hub copyConfigMapData "ztp-group" "oadp-cm" hub}}'

1: oadp-cm-policy を生成します。
2: Backup および Restore CR を使用して、ハブクラスター上に oadp-cm ConfigMap オブジェクトを作成します。
3: oadp-cm-policy に追加された ConfigMap のデータフィールドをオーバーライドします。ハブテンプレートは、oadp-cm ConfigMap をすべてのターゲットクラスターに伝播するために使用されます。

変更を Git リポジトリーにプッシュします。

関連情報

15.2.5.2. GitOps ZTP を使用したイメージベースアップグレード用の追加マニフェストのラベル付け

追加のマニフェストにラベルを付けて、Lifecycle Agent が lca.openshift.io/target-ocp-version: <target_version> ラベルでラベル付けされたリソースを抽出できるようにします。

前提条件

GitOps ZTP を使用して 1 つ以上のマネージドクラスターをプロビジョニングしている。
cluster-admin 権限を持つユーザーとしてログインしている。
互換性のあるシードクラスターからシードイメージを生成している。
stateroot 間で共有されるコンテナーイメージ用に、ターゲットクラスター上に個別のパーティションを作成している。詳細は、「GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定」を参照してください。
シードイメージで使用されるバージョンと互換性のある Lifecycle Agent のバージョンをデプロイしている。

手順

既存の PolicyGenTemplate CR で、必要な追加マニフェストに lca.openshift.io/target-ocp-version: <target_version> ラベルを付けます。

apiVersion: ran.openshift.io/v1
kind: PolicyGenTemplate
metadata:
  name: example-sno
spec:
  bindingRules:
    sites: "example-sno"
    du-profile: "4.15"
  mcp: "master"
  sourceFiles:
    - fileName: SriovNetwork.yaml
      policyName: "config-policy"
      metadata:
        name: "sriov-nw-du-fh"
        labels:
          lca.openshift.io/target-ocp-version: "4.15" 1
      spec:
        resourceName: du_fh
        vlan: 140
    - fileName: SriovNetworkNodePolicy.yaml
      policyName: "config-policy"
      metadata:
        name: "sriov-nnp-du-fh"
        labels:
          lca.openshift.io/target-ocp-version: "4.15"
      spec:
        deviceType: netdevice
        isRdma: false
        nicSelector:
          pfNames: ["ens5f0"]
        numVfs: 8
        priority: 10
        resourceName: du_fh
    - fileName: SriovNetwork.yaml
      policyName: "config-policy"
      metadata:
        name: "sriov-nw-du-mh"
        labels:
          lca.openshift.io/target-ocp-version: "4.15"
      spec:
        resourceName: du_mh
        vlan: 150
    - fileName: SriovNetworkNodePolicy.yaml
      policyName: "config-policy"
      metadata:
        name: "sriov-nnp-du-mh"
        labels:
          lca.openshift.io/target-ocp-version: "4.15"
      spec:
        deviceType: vfio-pci
        isRdma: false
        nicSelector:
          pfNames: ["ens7f0"]
        numVfs: 8
        priority: 10
        resourceName: du_mh
    - fileName: DefaultCatsrc.yaml 2
      policyName: "config-policy"
      metadata:
        name: default-cat-source
        namespace: openshift-marketplace
        labels:
            lca.openshift.io/target-ocp-version: "4.15"
      spec:
          displayName: default-cat-source
          image: quay.io/example-org/example-catalog:v1

1: lca.openshift.io/target-ocp-version ラベルが、ImageBasedUpgrade CR の spec.seedImageRef.version フィールドに指定されているターゲット OpenShift Container Platform バージョンの y-stream または z-stream のいずれかと一致することを確認します。Lifecycle Agent は、指定されたバージョンに一致する CR のみを適用します。
2: カスタムカタログソースを使用しない場合は、このエントリーを削除します。

変更を Git リポジトリーにプッシュします。

関連情報

15.2.6. コンテナーストレージディスクの自動イメージクリーンアップの設定

使用可能なストレージ領域の最小しきい値をアノテーションによって設定することで、Prep ステージにおいて Lifecycle Agent が固定されていないイメージをクリーンアップするときの条件を設定します。デフォルトのコンテナーストレージディスク使用量のしきい値は 50% です。

Lifecycle Agent は、CRI-O に固定されているイメージや現在使用されているイメージを削除しません。Operator は、まずダングリング (dangling) 状態のイメージから削除するイメージを選択します。さらに、イメージの Created タイムスタンプに基づいて最も古いイメージから新しいイメージの順に並べ替えることで、削除するイメージを選択します。

15.2.6.1. コンテナーストレージディスクの自動イメージクリーンアップの設定

アノテーションにより、使用可能なストレージ領域の最小しきい値を設定します。

前提条件

ImageBasedUpgrade CR を作成します。

手順

次のコマンドを実行して、しきい値を 65% に増やします。

$ oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/disk-usage-threshold-percent='65'

(オプション) 次のコマンドを実行して、しきい値のオーバーライドを削除します。

$ oc -n  openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/disk-usage-threshold-percent-

15.2.6.2. コンテナーストレージディスクの自動イメージクリーンアップの無効化

自動イメージクリーンアップのしきい値を無効にします。

手順

次のコマンドを実行して、自動イメージクリーンアップを無効にします。

$ oc -n openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep='Disabled'

(オプション) 次のコマンドを実行して、自動イメージクリーンアップを再度有効にします。
```
$ oc -n  openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep-
```

15.2. シングルノード OpenShift クラスターのイメージベースアップグレードの準備

15.2.1. イメージベースアップグレード用の共有コンテナーパーティションの設定

15.2.1.1. ostree stateroot 間の共有コンテナーパーティションの設定

15.2.1.2. GitOps ZTP を使用する場合の ostree stateroot 間の共有コンテナーディレクトリーの設定

15.2.2. イメージベースアップグレード用の Operator のインストール

15.2.2.1. CLI を使用した Lifecycle Agent のインストール

15.2.2.2. Web コンソールを使用した Lifecycle Agent のインストール

15.2.2.3. GitOps ZTP を使用した Lifecycle Agent のインストール

15.2.2.4. GitOps ZTP を使用した OADP Operator のインストールと設定

15.2.3. Lifecycle Agent を使用したイメージベースアップグレード用のシードイメージの生成

15.2.3.1. シードイメージの設定

15.2.3.1.1. RAN DU プロファイルを使用したシードイメージの設定

15.2.3.2. Lifecycle Agent を使用したシードイメージの生成

15.2.4. Lifecycle Agent を使用したイメージベースアップグレード用の ConfigMap オブジェクトの作成

15.2.4.1. Lifecycle Agent を使用したイメージベースアップグレード用の OADP ConfigMap オブジェクトの作成

15.2.4.2. Lifecycle Agent を使用したイメージベースアップグレード用の追加マニフェストの ConfigMap オブジェクトの作成

15.2.4.3. Lifecycle Agent を使用したイメージベースのアップグレード用のカスタムカタログソースの ConfigMap オブジェクトの作成

15.2.5. GitOps ZTP を使用した Lifecycle Agent によるイメージベースアップグレード用の ConfigMap オブジェクトの作成

15.2.5.1. GitOps ZTP を使用したイメージベースアップグレード用の OADP リソースの作成

15.2.5.2. GitOps ZTP を使用したイメージベースアップグレード用の追加マニフェストのラベル付け

15.2.6. コンテナーストレージディスクの自動イメージクリーンアップの設定

15.2.6.1. コンテナーストレージディスクの自動イメージクリーンアップの設定

15.2.6.2. コンテナーストレージディスクの自動イメージクリーンアップの無効化

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Red Hat legal and privacy links

Red Hat legal and privacy links