지원콘솔개발자평가판 시작연락처

15.2. 단일 노드 OpenShift 클러스터에 대한 이미지 기반 업그레이드 준비

15.2.1. 이미지 기반 업그레이드를 위한 공유 컨테이너 파티션 구성

단일 노드 OpenShift 클러스터에는 이미지 기반 업그레이드를 위한 공유 /var/lib/containers 파티션이 있어야 합니다. 설치 시 이 작업을 수행할 수 있습니다.

15.2.1.1. ostree stateroots 간의 공유 컨테이너 파티션 구성

설치 시 초기 클러스터와 대상 클러스터에 모두 MachineConfig 를 적용하여 별도의 파티션을 생성하고 업그레이드 프로세스 중에 사용할 두 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: var-lib-containers
              startMiB: <start_of_partition> 2
              sizeMiB: <partition_size> 3
      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
            [Unit]
            Before=local-fs.target
            Requires=systemd-fsck@dev-disk-by\x2dpartlabel-var\x2dlib\x2dcontainers.service
            After=systemd-fsck@dev-disk-by\x2dpartlabel-var\x2dlib\x2dcontainers.service

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

            [Install]
            RequiredBy=local-fs.target
          enabled: true
          name: var-lib-containers.mount
    1
    root 디스크를 지정합니다.
    2
    MiB로 파티션의 시작을 지정합니다. 값이 너무 작으면 설치에 실패합니다.
    3
    사전 캐시된 이미지에 적절한 디스크 공간을 확보하려면 500GB 파티션의 최소 크기를 지정합니다. 값이 너무 작으면 설치 후 배포가 실패합니다.

15.2.1.2. GitOps ZTP를 사용할 때 ostree stateroots 간에 공유 컨테이너 디렉터리 구성

GitOps ZTP(ZTP) 워크플로를 사용하는 경우 시드 클러스터와 대상 클러스터에 별도의 디스크 파티션을 생성하고 /var/lib/containers 파티션을 공유하는 절차를 수행합니다.

중요

설치 시 이 절차를 완료해야 합니다.

사전 요구 사항

  • Butane이 설치되어 있습니다. 자세한 내용은 " Butane 설치"를 참조하십시오.

프로세스

  1. 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
    root 디스크를 지정합니다.
    2
    MiB로 파티션의 시작을 지정합니다. 값이 너무 작으면 설치에 실패합니다.
    3
    사전 캐시된 이미지에 적절한 디스크 공간을 확보하려면 500GB 파티션의 최소 크기를 지정합니다. 값이 너무 작으면 설치 후 배포가 실패합니다.

  2. 다음 명령을 실행하여 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"}]}}

  3. 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"}]}}'
[...]

검증

  1. 설치 중 또는 설치 후 hub 클러스터에서 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\"}]}}"

  2. 설치 후 다음 명령을 실행하여 단일 노드 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

추가 리소스

15.2.2. 이미지 기반 업그레이드를 위한 Operator 설치

Lifecycle Agent 및 OADP Operator를 설치하여 업그레이드를 위해 클러스터를 준비합니다.

비GitOps 방법을 사용하여 OADP Operator를 설치하려면 "OADP Operator 설치"를 참조하십시오.

추가 리소스

15.2.2.1. CLI를 사용하여 라이프사이클 에이전트 설치

OpenShift CLI(oc)를 사용하여 Lifecycle Agent를 설치할 수 있습니다.

사전 요구 사항

  • OpenShift CLI(oc)가 설치되어 있습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. Lifecycle Agent에 대한 Namespace 오브젝트 YAML 파일을 생성합니다. 

    apiVersion: v1
kind: Namespace
metadata:
  name: openshift-lifecycle-agent
  annotations:
    workload.openshift.io/allowed: management

    1. 다음 명령을 실행하여 네임스페이스 CR을 생성합니다. 

      $ oc create -f <namespace_filename>.yaml

  2. Lifecycle Agent에 대한 OperatorGroup 오브젝트 YAML 파일을 생성합니다. 

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

    1. 다음 명령을 실행하여 OperatorGroup CR을 생성합니다. 

      $ oc create -f <operatorgroup_filename>.yaml

  3. Lifecycle Agent에 대한 서브스크립션 CR을 생성합니다. 

    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

    1. 다음 명령을 실행하여 서브스크립션 CR을 생성합니다. 

      $ oc create -f <subscription_filename>.yaml

검증

  1. 설치에 성공했는지 확인하려면 다음 명령을 실행하여 CSV 리소스를 검사합니다. 

    $ oc get csv -n openshift-lifecycle-agent

    출력 예

    NAME                              DISPLAY                     VERSION               REPLACES                           PHASE
lifecycle-agent.v4.17.0           Openshift Lifecycle Agent   4.17.0                Succeeded

  2. 다음 명령을 실행하여 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. 웹 콘솔을 사용하여 라이프사이클 에이전트 설치

OpenShift Container Platform 웹 콘솔을 사용하여 Lifecycle Agent를 설치할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 로그인했습니다.

프로세스

  1. OpenShift Container Platform 웹 콘솔에서 Operator OperatorHub로 이동합니다.
  2. 사용 가능한 Operator 목록에서 Lifecycle Agent 를 검색한 다음 설치를 클릭합니다.
  3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-lifecycle-agent 를 선택합니다.
  4. 설치를 클릭합니다.

검증

  1. 설치에 성공했는지 확인하려면 다음을 수행하십시오.

    1. Operators 설치된 Operators를 클릭합니다.

    2. Lifecycle Agent가 openshift-lifecycle-agent 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

Operator가 성공적으로 설치되지 않은 경우 다음을 수행하십시오.

  1. Operator 설치된 Operator 를 클릭하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애 또는 오류가 있는지 검사합니다.
  2. 워크로드 포드 를 클릭하고 openshift-lifecycle-agent 프로젝트에서 Pod 로그를 확인합니다.

15.2.2.3. GitOps ZTP를 사용하여 라이프사이클 에이전트 설치

GitOps ZTP(ZTP)를 사용하여 Lifecycle Agent를 설치하여 이미지 기반 업그레이드를 수행합니다.

프로세스

  1. 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

  2. 공통 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를 설치하고 구성합니다.

프로세스

  1. 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

  2. 공통 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"
[...]

  3. 대상 클러스터에 대해서만 DataProtectionApplication CR 및 S3 시크릿을 생성합니다.

    1. 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에서 생성한 백업 스토리지 위치의 가용성을 확인합니다.

    2. 재정의를 사용하여 사이트 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
      버킷 은 S3 백엔드에서 생성된 버킷 이름을 정의합니다. 접두사 는 버킷에 자동으로 생성될 하위 디렉터리의 이름을 정의합니다. 버킷 과 접두사 의 조합은 대상 클러스터마다 고유해야 합니다. 각 대상 클러스터의 고유한 스토리지 디렉터리를 보장하기 위해 RHACM 허브 템플릿 기능(예: prefix: {{hub .ManagedClusterName hub}} )을 사용할 수 있습니다.

15.2.3. Lifecycle Agent를 사용하여 이미지 기반 업그레이드의 시드 이미지 생성

Lifecycle Agent를 사용하여 SeedGenerator CR(사용자 정의 리소스)으로 시드 이미지를 생성합니다.

15.2.3.1. 시드 이미지 구성

시드 이미지는 동일한 하드웨어 및 유사한 구성으로 단일 노드 OpenShift 클러스터 세트를 대상으로 합니다. 즉, 시드 이미지에는 시드 클러스터가 대상 클러스터와 공유하는 모든 구성 요소 및 구성이 있어야 합니다. 따라서 시드 클러스터에서 생성된 시드 이미지에는 클러스터별 구성이 포함될 수 없습니다.

다음 표에는 시드 이미지에 포함되어야 하며 포함하지 않아야 하는 구성 요소, 리소스 및 구성이 나열되어 있습니다.

표 15.2. 시드 이미지 구성
클러스터 구성시드 이미지에 포함

성능 프로필

제공됨

대상 클러스터의 MachineConfig 리소스

제공됨

IP 버전 [1]

제공됨

Lifecycle Agent 및 OADP Operator를 포함한 Day 2 Operator 세트

제공됨

연결이 끊긴 레지스트리 설정 [2]

제공됨

유효한 프록시 설정 [3]

제공됨

FIPS 설정

제공됨

대상 클러스터의 크기와 일치하는 컨테이너 스토리지를 위한 기본 디스크의 전용 파티션

제공됨

로컬 볼륨

  • LSO의 LocalVolume 에서 사용되는 StorageClass
  • LSO용 LocalVolume
  • LVMS용 LVMCluster CR

없음

OADP DataProtectionApplication CR

없음

  1. 이번 릴리스에서는 듀얼 스택 네트워킹이 지원되지 않습니다.
  2. 시드 클러스터가 연결이 끊긴 환경에 설치된 경우 대상 클러스터도 연결이 끊긴 환경에 설치해야 합니다.
  3. 시드 및 대상 클러스터의 프록시 구성이 일치하지 않아도 됩니다.
15.2.3.1.1. RAN DU 프로필을 사용한 시드 이미지 구성

다음 표에는 RAN DU 프로필을 사용할 때 시드 이미지에 포함되어야 하는 구성 요소, 리소스 및 구성이 나열되어 있습니다.

표 15.3. RAN DU 프로필을 사용한 시드 이미지 구성
리소스시드 이미지에 포함

Day 0 설치의 일부로 적용되는 모든 추가 매니페스트

제공됨

모든 Day 2 Operator 서브스크립션

제공됨

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

대상 클러스터의 인터페이스가 seed 클러스터와 공통되는 경우 시드 이미지에 포함할 수 있습니다. 그렇지 않으면 추가 매니페스트로 적용합니다.

SriovNetwork.yamlSriovNetworkNodePolicy.yaml

네임스페이스를 포함한 구성이 시드 및 대상 클러스터에서 정확히 동일하면 시드 이미지에 포함할 수 있습니다. 그렇지 않으면 추가 매니페스트로 적용합니다.

15.2.3.2. Lifecycle Agent를 사용하여 시드 이미지 생성

Lifecycle Agent를 사용하여 관리 클러스터에서 시드 이미지를 생성합니다. Operator는 필수 시스템 구성을 확인하고 시드 이미지를 생성하기 전에 필요한 시스템 정리를 수행한 다음 이미지 생성을 시작합니다. 시드 이미지 생성에는 다음 작업이 포함됩니다.

  • 클러스터 Operator 중지
  • 시드 이미지 구성 준비
  • SeedGenerator CR에 지정된 이미지 리포지토리로 시드 이미지를 생성하고 푸시
  • 클러스터 Operator 복원
  • 시드 클러스터 인증서 만료
  • 시드 클러스터에 대한 새 인증서 생성
  • seed 클러스터에서 SeedGenerator CR 복원 및 업데이트

사전 요구 사항

  • Kubernetes Operator의 RHACM 및 다중 클러스터 엔진은 시드 클러스터에 설치되지 않습니다.
  • seed 클러스터에 공유 컨테이너 디렉터리를 구성했습니다.
  • seed 클러스터에 최소 버전의 OADP Operator 및 Lifecycle Agent를 설치했습니다.
  • 영구 볼륨이 시드 클러스터에 구성되지 않았는지 확인합니다.
  • Local Storage Operator가 사용되는 경우 LocalVolume CR이 시드 클러스터에 존재하지 않는지 확인합니다.
  • LVM 스토리지가 사용되는 경우 LVMCluster CR이 시드 클러스터에 존재하지 않는지 확인합니다.
  • OADP가 사용되는 경우 DataProtectionApplication CR이 시드 클러스터에 존재하지 않는지 확인합니다.

프로세스

  1. 관리 클러스터를 허브에서 분리하여 시드 이미지에 없는 초기 클러스터에서 RHACM 관련 리소스를 삭제합니다.

    1. 다음 명령을 실행하여 시드 클러스터를 수동으로 분리합니다. 

      $ oc delete managedcluster sno-worker-example
      1. 관리 클러스터가 제거될 때까지 기다립니다. 클러스터가 제거된 후 적절한 SeedGenerator CR을 생성합니다. Lifecycle Agent는 RHACM 아티팩트를 정리합니다.

    2. GitOps ZTP를 사용하는 경우 kustomization.yaml 에서 seed 클러스터의 SiteConfig CR을 제거하여 클러스터를 분리합니다.

      1. 여러 SiteConfig CR을 참조하는 kustomization.yaml 파일이 있는 경우 kustomization.yaml 에서 시드 클러스터의 siteConfig CR을 제거합니다. 

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

generators:
#- example-seed-sno1.yaml
- example-target-sno2.yaml
- example-target-sno3.yaml

      2. 하나의 SiteConfig CR을 참조하는 kustomization.yaml 이 있는 경우 kustomization.yaml 에서 시드 클러스터의 siteConfig CR을 제거하고 generators: {} 행을 추가합니다. 

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

generators: {}

      3. Git 리포지토리에서 kustomization.yaml 변경 사항을 커밋하고 변경 사항을 리포지토리로 내보냅니다.

        ArgoCD 파이프라인은 변경 사항을 감지하고 관리 클러스터를 제거합니다.

  2. 시드 이미지를 레지스트리로 푸시할 수 있도록 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 네임스페이스의 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. 다음 명령을 실행하여 보안을 적용합니다. 

      $ oc apply -f secretseedgenerator.yaml

  3. 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 > 형식을 사용하는 것이 좋습니다.

  4. 다음 명령을 실행하여 시드 이미지를 생성합니다. 

    $ oc apply -f seedgenerator.yaml
    중요

    클러스터가 재부팅되고 API 기능이 손실되는 동안 Lifecycle Agent에서 시드 이미지를 생성합니다. 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에는 이미지 기반 업그레이드를 위해 해당 리소스를 처리하기 위해 ConfigMap 오브젝트로 래핑된 모든 OADP 리소스, 추가 매니페스트 및 사용자 정의 카탈로그 소스가 필요합니다.

15.2.4.1. Lifecycle Agent를 사용하여 이미지 기반 업그레이드에 대한 OADP ConfigMap 오브젝트 생성

업그레이드 중에 리소스를 백업하고 복원하는 데 사용되는 OADP 리소스를 생성합니다.

사전 요구 사항

  • 호환되는 시드 클러스터에서 시드 이미지를 생성했습니다.
  • OADP 백업 및 복원 리소스를 생성했습니다.
  • stateroots 간에 공유되는 컨테이너 이미지의 대상 클러스터에 별도의 파티션을 생성했습니다. 자세한 내용은 "이미지 기반 업그레이드에 대한 공유 컨테이너 파티션 구성"을 참조하십시오.
  • 시드 이미지와 함께 사용되는 버전과 호환되는 Lifecycle Agent 버전을 배포했습니다.
  • 대상 클러스터에 OADP Operator, DataProtectionApplication CR 및 해당 시크릿을 설치했습니다.
  • 적절한 인증 정보가 구성된 S3 호환 스토리지 솔루션 및 즉시 사용 가능한 버킷을 생성했습니다. 자세한 내용은 "OADP 설치 제외"를 참조하십시오.

프로세스

  1. OADP Operator가 설치된 동일한 네임스페이스에서 플랫폼 아티팩트에 대한 OADP Backup 및 Restore CR을 openshift-adp.

    1. 대상 클러스터가 RHACM에서 관리하는 경우 다음 YAML 파일을 추가하여 RHACM 아티팩트를 백업 및 복원합니다.

      PlatformBackupRestore.yaml for RHACM

      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
      다중 클러스터Hub CR에 .spec.imagePullSecret 이 정의되어 있지 않고 허브 클러스터의 open-cluster-management-agent 네임스페이스에 보안이 존재하지 않는 경우 v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials.

    2. LVM 스토리지를 통해 클러스터에 영구 볼륨을 생성한 경우 LVM 스토리지 아티팩트에 대해 다음 YAML 파일을 추가합니다.

      PlatformBackupRestoreLvms.yaml for LVM Storage

      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- ECDSA 값은 애플리케이션 Restore CR에 지정된 값보다 작아야 합니다.

  2. 업그레이드 후 애플리케이션을 복원해야 하는 경우 openshift-adp 네임스페이스에서 애플리케이션의 OADP Backup 및 Restore CR을 생성합니다.

    1. openshift-adp 네임스페이스에서 클러스터 범위 애플리케이션 아티팩트에 대한 OADP CR을 생성합니다.

      LSO 및 LVM 스토리지의 클러스터 범위 애플리케이션 아티팩트에 대한 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- Cryostat 값은 플랫폼 Restore CR의 값보다 크고 애플리케이션 네임스페이스 범위 Restore CR의 값보다 작아야 합니다.

    2. 네임스페이스 범위 애플리케이션 아티팩트에 대한 OADP CR을 생성합니다.

      LSO를 사용할 때 OADP CR의 네임스페이스 범위 애플리케이션 아티팩트의 예

      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 스토리지를 사용할 때 OADP CR의 네임스페이스 범위 애플리케이션 아티팩트의 예

      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 스토리지 볼륨 스냅샷을 사용하는 경우 선택 사항입니다.
      5
      필수 필드입니다.
      중요

      동일한 버전의 애플리케이션이 OpenShift Container Platform의 현재 릴리스와 대상 릴리스에서 작동해야 합니다.

  3. 다음 명령을 실행하여 OADP CR의 ConfigMap 오브젝트를 생성합니다. 

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

  4. 다음 명령을 실행하여 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 오브젝트 생성

대상 클러스터에 적용할 추가 매니페스트를 생성합니다.

프로세스

  1. 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"

  2. 다음 명령을 실행하여 ConfigMap 오브젝트를 생성합니다. 

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

  3. 다음 명령을 실행하여 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 필드에 추가하여 업그레이드 후 사용자 정의 카탈로그 소스를 유지할 수 있습니다. 카탈로그 소스에 대한 자세한 내용은 "Catalog source"를 참조하십시오.

프로세스

  1. 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

  2. 다음 명령을 실행하여 ConfigMap 오브젝트를 생성합니다. 

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

  3. 다음 명령을 실행하여 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 오브젝트로 래핑된 추가 매니페스트 및 사용자 정의 카탈로그 소스를 생성합니다.

15.2.5.1. GitOps ZTP를 사용하여 이미지 기반 업그레이드에 대한 OADP 리소스 생성

업그레이드 후 OADP 리소스를 준비하여 애플리케이션을 복원합니다.

사전 요구 사항

  • GitOps ZTP를 사용하여 하나 이상의 관리 클러스터를 프로비저닝했습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 호환되는 시드 클러스터에서 시드 이미지를 생성했습니다.
  • stateroots 간에 공유되는 컨테이너 이미지의 대상 클러스터에 별도의 파티션을 생성했습니다. 자세한 내용은 GitOps ZTP를 사용할 때 "ostree stateroots 간에 공유 컨테이너 파티션 구성"을 참조하십시오.
  • 시드 이미지와 함께 사용되는 버전과 호환되는 Lifecycle Agent 버전을 배포했습니다.
  • 대상 클러스터에 OADP Operator, DataProtectionApplication CR 및 해당 시크릿을 설치했습니다.
  • 적절한 인증 정보가 구성된 S3 호환 스토리지 솔루션 및 즉시 사용 가능한 버킷을 생성했습니다. 자세한 내용은 " GitOps ZTP를 사용하여 OADP Operator 설치 및 구성"을 참조하십시오.
  • OADP ConfigMap 오브젝트의 openshift-adp 네임스페이스는 모든 관리 클러스터에 있어야 하며 OADP ConfigMap 을 생성하고 클러스터에 복사하려면 허브가 있어야 합니다.

프로세스

  1. ArgoCD 정책 애플리케이션과 함께 사용하는 Git 리포지토리에 다음 디렉터리 구조가 포함되어 있는지 확인합니다. 

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

    source-crs/ibu/PlatformBackupRestoreWithIBGU.yaml 파일은 ZTP 컨테이너 이미지에 제공됩니다.

    PlatformBackupRestoreWithIBGU.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-work:ibu-role,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
    다중 클러스터Hub CR에 .spec.imagePullSecret 이 정의되어 있지 않고 허브 클러스터의 open-cluster-management-agent 네임스페이스에 보안이 존재하지 않는 경우 v1/secrets/open-cluster-management-agent/open-cluster-management-image-pull-credentials.
    참고

    관리 클러스터에서 직접 이미지 기반 업그레이드를 수행하는 경우 PlatformBackupRestore.yaml 파일을 사용합니다.

    LVM 스토리지를 사용하여 영구 볼륨을 생성하는 경우 ZTP 컨테이너 이미지에 제공된 source-crs/ibu/PlatformBackupRestoreLvms.yaml 을 사용하여 LVM 스토리지 리소스를 백업할 수 있습니다.

    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- ECDSA 값은 애플리케이션 Restore CR에 지정된 값보다 작아야 합니다.

  2. 업그레이드 후 애플리케이션을 복원해야 하는 경우 openshift-adp 네임스페이스에서 애플리케이션의 OADP Backup 및 Restore CR을 생성합니다.

    1. openshift-adp 네임스페이스에서 클러스터 범위 애플리케이션 아티팩트에 대한 OADP CR을 생성합니다.

      LSO 및 LVM 스토리지의 클러스터 범위 애플리케이션 아티팩트에 대한 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- Cryostat 값은 플랫폼 Restore CR의 값보다 크고 애플리케이션 네임스페이스 범위 Restore CR의 값보다 작아야 합니다.

    2. source-crs/custom-crs 디렉터리의 네임스페이스 범위 애플리케이션 아티팩트에 대한 OADP CR을 생성합니다.

      LSO를 사용할 때 OADP CR의 네임스페이스 범위 애플리케이션 아티팩트의 예

      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 스토리지를 사용할 때 OADP CR의 네임스페이스 범위 애플리케이션 아티팩트의 예

      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 스토리지 볼륨 스냅샷을 사용하는 경우 선택 사항입니다.
      5
      필수 필드입니다.
      중요

      동일한 버전의 애플리케이션이 OpenShift Container Platform의 현재 릴리스와 대상 릴리스에서 작동해야 합니다.

  3. 다음 콘텐츠를 사용하여 kustomization.yaml 을 생성합니다. 

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

configMapGenerator: 1
- files:
  - source-crs/ibu/PlatformBackupRestoreWithIBGU.yaml
  #- source-crs/custom-crs/ApplicationClusterScopedBackupRestore.yaml
  #- source-crs/custom-crs/ApplicationApplicationBackupRestoreLso.yaml
  name: oadp-cm
  namespace: openshift-adp 2
generatorOptions:
  disableNameSuffixHash: true
    1
    Backup 및 Restore CR을 사용하여 hub 클러스터에서 oadp-cm ConfigMap 오브젝트를 생성합니다.
    2
    네임스페이스는 모든 관리 클러스터에 있어야 하며 OADP ConfigMap 을 생성하고 클러스터에 복사하려면 허브가 있어야 합니다.
  4. Git 리포지토리로 변경 사항을 내보냅니다.

추가 리소스

15.2.5.2. GitOps ZTP를 사용하여 이미지 기반 업그레이드에 대한 추가 매니페스트 레이블

Lifecycle Agent에서 lca.openshift.io/target-ocp-version: <target_version > 레이블로 레이블이 지정된 리소스를 추출할 수 있도록 추가 매니페스트에 레이블을 지정합니다.

사전 요구 사항

  • GitOps ZTP를 사용하여 하나 이상의 관리 클러스터를 프로비저닝했습니다.
  • cluster-admin 권한이 있는 사용자로 로그인했습니다.
  • 호환되는 시드 클러스터에서 시드 이미지를 생성했습니다.
  • stateroots 간에 공유되는 컨테이너 이미지의 대상 클러스터에 별도의 파티션을 생성했습니다. 자세한 내용은 GitOps ZTP를 사용할 때 "ostree stateroots 간에 공유 컨테이너 디렉터리 구성"을 참조하십시오.
  • 시드 이미지와 함께 사용되는 버전과 호환되는 Lifecycle Agent 버전을 배포했습니다.

프로세스

  1. 기존 사이트 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
    사용자 정의 카탈로그 소스를 사용하지 않으려면 이 항목을 제거하십시오.
  2. Git 리포지토리로 변경 사항을 내보냅니다.

추가 리소스

15.2.6. 컨테이너 스토리지 디스크의 자동 이미지 정리 구성

주석을 통해 사용 가능한 스토리지 공간에 최소 임계값을 설정하여 Lifecycle Agent가 Prep 단계에서 고정되지 않은 이미지를 정리할 때 를 구성합니다. 기본 컨테이너 스토리지 디스크 사용량 임계값은 50%입니다.

Lifecycle Agent는 CRI-O에 고정되거나 현재 사용되는 이미지를 삭제하지 않습니다. Operator는 이미지 배치로 시작한 다음 생성된 이미지 타임스탬프에 의해 결정된 가장 오래된 이미지에서 최신 이미지까지 정렬하여 삭제할 이미지를 선택합니다.

15.2.6.1. 컨테이너 스토리지 디스크의 자동 이미지 정리 구성

주석을 통해 사용 가능한 스토리지 공간에 대한 최소 임계값을 구성합니다.

사전 요구 사항

  • ImageBasedUpgrade CR을 생성했습니다.

프로세스

  1. 다음 명령을 실행하여 임계값을 Cryostat로 늘립니다. 

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

  2. (선택 사항) 다음 명령을 실행하여 임계값 덮어쓰기를 제거합니다. 

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

15.2.6.2. 컨테이너 스토리지 디스크의 자동 이미지 정리 비활성화

자동 이미지 정리 임계값을 비활성화합니다.

프로세스

  1. 다음 명령을 실행하여 자동 이미지 정리를 비활성화합니다. 

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

  2. (선택 사항) 다음 명령을 실행하여 자동 이미지 정리를 다시 활성화합니다. 

    $ oc -n  openshift-lifecycle-agent annotate ibu upgrade image-cleanup.lca.openshift.io/on-prep-
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.