5.8. 번들 이미지 작업

Operator SDK를 사용하여 OLM(Operator Lifecycle Manager)에서 Operator를 번들 형식으로 패키지, 배포, 업그레이드할 수 있습니다.

5.8.1. Operator 번들

Operator 번들 형식은 Operator SDK 및 Operator Lifecycle Manager (OLM)의 기본 패키지 메서드입니다. Operator SDK를 사용하여 Operator 프로젝트를 번들 이미지로 빌드하고 푸시하여 OLM에서 Operator를 사용할 수 있습니다.

사전 요구 사항

  • 개발 워크스테이션에 Operator SDK CLI가 설치됨
  • OpenShift CLI (oc) v4.9 이상이 설치됨
  • Operator SDK를 사용하여 Operator 프로젝트를 초기화함
  • Operator가 Go 기반인 경우 OpenShift Container Platform에서 실행하기 위해 지원되는 이미지를 사용하도록 프로젝트를 업데이트해야 함

절차

  1. Operator 프로젝트 디렉터리에서 다음 make 명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서 IMG 인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

    1. 이미지를 빌드합니다.

      $ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
      참고

      Operator에 대해 SDK에서 생성한 Dockerfile은 Go 빌드 를 위해 GOARCH=amd64 를 명시적으로 참조합니다. 이는AMD64 이외의 아키텍처의 경우 GOARCH=$CACHEGETARCH 에 수정될 수 있습니다. Docker는 환경 변수를 -platform 에서 지정한 값으로 자동 설정합니다. Buildah를 사용하면 -build-arg 를 목적으로 사용해야 합니다. 자세한 내용은 여러 아키텍처를 참조하십시오.

    2. 이미지를 리포지토리로 내보냅니다.

      $ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
  2. Operator SDK generate bundlebundle validate 명령을 비롯한 다양한 명령을 호출하는 make bundle 명령을 실행하여 Operator 번들 매니페스트를 생성합니다.

    $ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>

    Operator의 번들 매니페스트는 애플리케이션을 표시, 생성, 관리하는 방법을 설명합니다. make bundle 명령은 Operator 프로젝트에서 다음 파일 및 디렉터리를 생성합니다.

    • ClusterServiceVersion 오브젝트를 포함하는 bundle/manifests라는 번들 매니페스트 디렉터리
    • bundle/metadata라는 번들 메타데이터 디렉터리
    • config/crd 디렉터리의 모든 CRD(사용자 정의 리소스 정의)
    • Dockerfile bundle.Dockerfile

    그런 다음 operator-sdk bundle validate를 사용하여 이러한 파일을 자동으로 검증하고 디스크상의 번들 표현이 올바른지 확인합니다.

  3. 다음 명령을 실행하여 번들 이미지를 빌드하고 내보냅니다. OLM에서는 하나 이상의 번들 이미지를 참조하는 인덱스 이미지를 통해 Operator 번들을 사용합니다.

    1. 번들 이미지를 빌드합니다. 이미지를 내보낼 레지스트리, 사용자 네임스페이스, 이미지 태그에 대한 세부 정보를 사용하여 BUNDLE_IMG를 설정합니다.

      $ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
    2. 번들 이미지를 내보냅니다.

      $ docker push <registry>/<user>/<bundle_image_name>:<tag>

5.8.2. Operator Lifecycle Manager를 사용하여 Operator 배포

OLM(Operator Lifecycle Manager)은 Kubernetes 클러스터에서 Operator 및 관련 서비스를 설치, 업데이트하고 라이프사이클을 관리하는 데 도움이 됩니다. OLM은 기본적으로 OpenShift Container Platform에 설치되고 Kubernetes 확장으로 실행되므로 추가 툴 없이 모든 Operator 라이프사이클 관리 기능에 웹 콘솔과 OpenShift CLI(oc)를 사용할 수 있습니다.

Operator 번들 형식은 Operator SDK 및 OLM의 기본 패키지 메서드입니다. Operator SDK를 사용하여 OLM에서 번들 이미지를 신속하게 실행하여 올바르게 실행되는지 확인할 수 있습니다.

사전 요구 사항

  • 개발 워크스테이션에 Operator SDK CLI가 설치됨
  • Operator 번들 이미지를 빌드하여 레지스트리로 내보냄
  • Kubernetes 기반 클러스터에 OLM이 설치되어 있음(apiextensions.k8s.io/v1 CRD(예: OpenShift Container Platform 4.9)를 사용하는 경우 v1.16.0 이상)
  • cluster-admin 권한이 있는 계정을 사용하여 oc로 클러스터에 로그인됨
  • Operator가 Go 기반인 경우 OpenShift Container Platform에서 실행하기 위해 지원되는 이미지를 사용하도록 프로젝트를 업데이트해야 함

절차

  1. 다음 명령을 입력하여 클러스터에서 Operator를 실행합니다.

    $ operator-sdk run bundle \
        [-n <namespace>] \1
        <registry>/<user>/<bundle_image_name>:<tag>
    1
    기본적으로 이 명령은 현재 활성 프로젝트의 ~/.kube/config 파일에 Operator를 설치합니다. -n 플래그를 추가하면 설치에 다른 네임스페이스 범위를 설정할 수 있습니다.

    이 명령은 다음 작업을 수행합니다.

    • 번들 이미지를 참조하는 인덱스 이미지를 생성합니다. 인덱스 이미지는 불투명하고 일시적이지만 프로덕션에서 카탈로그에 번들을 추가하는 방법을 정확하게 반영합니다.
    • OperatorHub에서 Operator를 검색할 수 있도록 새 인덱스 이미지를 가리키는 카탈로그 소스를 생성합니다.
    • OperatorGroup,Subscription,InstallPlan 및 RBAC를 포함한 기타 모든 필수 오브젝트를 생성하여 Operator를 클러스터에 배포합니다.

5.8.3. 번들 Operator가 포함된 카탈로그 게시

Operator를 설치하고 관리하려면 OLM(Operator Lifecycle Manager)이 클러스터의 카탈로그에서 참조하는 인덱스 이미지에 Operator 번들을 나열해야 합니다. Operator 작성자는 Operator SDK를 사용하여 Operator 및 모든 종속 항목에 대한 번들이 포함된 인덱스를 생성할 수 있습니다. 이 기능은 원격 클러스터에서 테스트하고 컨테이너 레지스트리에 게시하는 데 유용합니다.

참고

Operator SDK는 opm CLI를 사용하여 인덱스 이미지 생성을 용이하게 합니다. opm 명령에 대한 경험이 필요하지 않습니다. 고급 사용 사례의 경우 Operator SDK 대신 opm 명령을 직접 사용할 수 있습니다.

사전 요구 사항

  • 개발 워크스테이션에 Operator SDK CLI가 설치됨
  • Operator 번들 이미지를 빌드하여 레지스트리로 내보냄
  • Kubernetes 기반 클러스터에 OLM이 설치되어 있음(apiextensions.k8s.io/v1 CRD(예: OpenShift Container Platform 4.9)를 사용하는 경우 v1.16.0 이상)
  • cluster-admin 권한이 있는 계정을 사용하여 oc로 클러스터에 로그인됨

절차

  1. Operator 프로젝트 디렉터리에서 다음 make 명령을 실행하여 Operator 번들이 포함된 인덱스 이미지를 빌드합니다.

    $ make catalog-build CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>

    여기서 CATALOG_IMG 인수는 액세스할 수 있는 리포지토리를 참조합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

  2. 빌드 인덱스 이미지를 리포지토리로 푸시합니다.

    $ make catalog-push CATALOG_IMG=<registry>/<user>/<index_image_name>:<tag>
    작은 정보

    한 번에 여러 작업을 순서대로 수행하는 경우 Operator SDK make 명령을 함께 사용할 수 있습니다. 예를 들어 Operator 프로젝트에 대한 번들 이미지를 아직 빌드하지 않은 경우 다음 구문을 사용하여 번들 이미지와 인덱스 이미지를 빌드하고 푸시할 수 있습니다.

    $ make bundle-build bundle-push catalog-build catalog-push \
        BUNDLE_IMG=<bundle_image_pull_spec> \
        CATALOG_IMG=<index_image_pull_spec>

    또는 MakefileIMAGE_TAG_BASE 필드를 기존 리포지토리로 설정할 수도 있습니다.

    IMAGE_TAG_BASE=quay.io/example/my-operator

    다음 구문을 사용하여 자동으로 생성된 이름으로 이미지를 빌드하고 푸시할 수 있습니다 (예: 번들 이미지의 경우 quay.io/example/my-operator-bundle:v0.0.1 및 인덱스 이미지의 경우 quay.io/example/my-operator-catalog:v0.0.1.)

    $ make bundle-build bundle-push catalog-build catalog-push
  3. 방금 생성한 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 정의한 다음 oc apply 명령 또는 웹 콘솔을 사용하여 오브젝트를 생성합니다.

    CatalogSource YAML의 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: cs-memcached
      namespace: default
    spec:
      displayName: My Test
      publisher: Company
      sourceType: grpc
      image: quay.io/example/memcached-catalog:v0.0.1 1
      updateStrategy:
        registryPoll:
          interval: 10m

    1
    CATALOG_IMG 인수와 함께 이전에 사용한 이미지 가져오기 사양으로 image를 설정합니다.
  4. 카탈로그 소스를 확인합니다.

    $ oc get catalogsource

    출력 예

    NAME           DISPLAY     TYPE   PUBLISHER   AGE
    cs-memcached   My Test     grpc   Company     4h31m

검증

  1. 카탈로그를 사용하여 Operator를 설치합니다.

    1. OperatorGroup 오브젝트를 정의하고 oc apply 명령 또는 웹 콘솔을 사용하여 생성합니다.

      OperatorGroup YAML의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: my-test
        namespace: default
      spec:
        targetNamespaces:
        - default

    2. Subscription 오브젝트를 정의하고 oc apply 명령 또는 웹 콘솔을 사용하여 생성합니다.

      Subscription YAML의 예

      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: catalogtest
        namespace: default
      spec:
        channel: "alpha"
        installPlanApproval: Manual
        name: catalog
        source: cs-memcached
        sourceNamespace: default
        startingCSV: memcached-operator.v0.0.1

  2. 설치된 Operator가 실행 중인지 확인합니다.

    1. Operator 그룹을 확인합니다.

      $ oc get og

      출력 예

      NAME             AGE
      my-test           4h40m

    2. CSV(클러스터 서비스 버전)를 확인합니다.

      $ oc get csv

      출력 예

      NAME                        DISPLAY   VERSION   REPLACES   PHASE
      memcached-operator.v0.0.1   Test      0.0.1                Succeeded

    3. Operator의 Pod를 확인합니다.

      $ oc get pods

      출력 예

      NAME                                                              READY   STATUS      RESTARTS   AGE
      9098d908802769fbde8bd45255e69710a9f8420a8f3d814abe88b68f8ervdj6   0/1     Completed   0          4h33m
      catalog-controller-manager-7fd5b7b987-69s4n                       2/2     Running     0          4h32m
      cs-memcached-7622r                                                1/1     Running     0          4h33m

추가 리소스

5.8.4. Operator Lifecycle Manager에서 Operator 업그레이드 테스트

인덱스 이미지 및 카탈로그 소스를 수동으로 관리하지 않아도 Operator SDK에서 OLM(Operator Lifecycle Manager) 통합을 사용하여 Operator 업그레이드를 신속하게 테스트할 수 있습니다.

run bundle-upgrade 하위 명령은 최신 버전의 번들 이미지를 지정하여 설치된 Operator가 최신 버전으로 업그레이드되도록 트리거하는 작업을 자동화합니다.

사전 요구 사항

  • run bundle 하위 명령을 사용하거나 기존 OLM 설치와 함께 OLM과 함께 Operator 설치
  • 번들 이미지에 설치된 Operator의 최신 버전이 표시됨

절차

  1. OLM을 사용하여 Operator가 아직 설치되지 않은 경우 run bundle 하위 명령을 사용하거나 기존 OLM 설치와 함께 이전 버전을 설치합니다.

    참고

    OLM을 사용하여 이전 버전의 번들이 설치된 경우 카탈로그 소스에서 참조하는 인덱스 이미지에 업그레이드하려는 최신 번들이 없어야 합니다. 그렇지 않으면 패키지 및 CSV(클러스터 서비스 버전)를 제공하는 인덱스에서 최신 번들을 이미 참조하므로 run bundle-upgrade 하위 명령을 실행하면 레지스트리 pod가 실패합니다.

    예를 들어 이전 번들 이미지를 지정하여 Memcached Operator에 다음 run bundle 하위 명령을 사용할 수 있습니다.

    $ operator-sdk run bundle <registry>/<user>/memcached-operator:v0.0.1

    출력 예

    INFO[0009] Successfully created registry pod: quay-io-demo-memcached-operator-v0-0-1
    INFO[0009] Created CatalogSource: memcached-operator-catalog
    INFO[0010] OperatorGroup "operator-sdk-og" created
    INFO[0010] Created Subscription: memcached-operator-v0-0-1-sub
    INFO[0013] Approved InstallPlan install-bqggr for the Subscription: memcached-operator-v0-0-1-sub
    INFO[0013] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to reach 'Succeeded' phase
    INFO[0013]   Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.1" to appear
    INFO[0019]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.1" phase: Succeeded

  2. 최신 Operator 버전에 번들 이미지를 지정하여 설치한 Operator를 업그레이드합니다.

    $ operator-sdk run bundle-upgrade <registry>/<user>/memcached-operator:v0.0.2

    출력 예

    INFO[0002] Found existing subscription with name memcached-operator-v0-0-1-sub and namespace my-project
    INFO[0002] Found existing catalog source with name memcached-operator-catalog and namespace my-project
    INFO[0009] Successfully created registry pod: quay-io-demo-memcached-operator-v0-0-2
    INFO[0009] Updated catalog source memcached-operator-catalog with address and annotations
    INFO[0010] Deleted previous registry pod with name "quay-io-demo-memcached-operator-v0-0-1"
    INFO[0041] Approved InstallPlan install-gvcjh for the Subscription: memcached-operator-v0-0-1-sub
    INFO[0042] Waiting for ClusterServiceVersion "my-project/memcached-operator.v0.0.2" to reach 'Succeeded' phase
    INFO[0042]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: InstallReady
    INFO[0043]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Installing
    INFO[0044]   Found ClusterServiceVersion "my-project/memcached-operator.v0.0.2" phase: Succeeded
    INFO[0044] Successfully upgraded to "memcached-operator.v0.0.2"

  3. 설치된 Operator를 정리합니다.

    $ operator-sdk cleanup memcached-operator

5.8.5. OpenShift Container Platform 버전과 Operator 호환성 제어

중요

Kubernetes는 후속 릴리스에서 제거된 특정 API를 주기적으로 사용하지 않습니다. Operator가 더 이상 사용되지 않는 API를 사용하는 경우 OpenShift Container Platform 클러스터가 제거된 Kubernetes 버전으로 업그레이드된 후 더 이상 작동하지 않을 수 있습니다.

Operator 작성자는 Kubernetes 문서에서 더 이상 사용되지 않는 API 마이그레이션 가이드를 검토하고 더 이상 사용되지 않거나 삭제된 API를 사용하지 않도록 Operator 프로젝트를 최신 상태로 유지하는 것이 좋습니다. Operator와 호환되지 않는 향후 버전의 OpenShift Container Platform을 릴리스하기 전에 Operator를 업데이트하는 것이 좋습니다.

OpenShift Container Platform 버전에서 API가 제거되면 제거된 API를 계속 사용하는 클러스터 버전에서 실행되는 Operator가 더 이상 제대로 작동하지 않게 됩니다. Operator 작성자는 Operator 사용자의 중단을 방지하기 위해 API 사용 중단 및 제거를 수용하도록 Operator 프로젝트를 업데이트해야 합니다.

작은 정보

Operator의 이벤트 경고를 확인하여 현재 사용 중인 API에 대한 경고가 있는지 확인할 수 있습니다. 다음 릴리스에서 제거될 사용 중인 API를 감지하면 다음 경고가 실행됩니다.

APIRemovedInNextReleaseInUse
OpenShift Container Platform의 다음 릴리스에서 제거될 API
APIRemovedInNextEUSReleaseInUse
OpenShift Container Platform EUS (Extended Update Support)의 다음 릴리스에서 제거될 API

클러스터 관리자가 다음 버전의 OpenShift Container Platform으로 업그레이드하기 전에 Operator를 설치한 경우 다음 클러스터 버전과 호환되는 Operator 버전이 설치되어 있는지 확인해야 합니다. 이전 버전의 OpenShift Container Platform에서 계속 사용할 수 있도록 Operator 프로젝트를 더 이상 사용되지 않거나 제거된 API와 함께 게시해야 하는 경우에도 Operator 프로젝트를 업데이트하는 것이 좋습니다.

다음 절차에서는 관리자가 호환되지 않는 OpenShift Container Platform 버전에 Operator 버전을 설치하지 않도록 하는 데 도움이 됩니다. 이러한 단계를 수행하면 관리자가 현재 클러스터에 설치된 Operator 버전과 호환되지 않는 최신 버전의 OpenShift Container Platform으로 업그레이드할 수 없습니다.

이 절차는 특정 OpenShift Container Platform 버전에서 현재 버전의 Operator가 제대로 작동하지 않는 경우에도 유용합니다. Operator를 배포해야 하는 클러스터 버전을 정의하면 Operator가 허용 범위 외부에 있는 클러스터 버전의 카탈로그에 표시되지 않아야 합니다.

중요

클러스터 관리자가 API가 더 이상 지원되지 않는 향후 OpenShift Container Platform 버전으로 업그레이드할 때 더 이상 사용되지 않는 API를 사용하는 Operator는 중요한 워크로드에 부정적인 영향을 미칠 수 있습니다. Operator가 더 이상 사용되지 않는 API를 사용하는 경우 최대한 빨리 Operator 프로젝트에서 다음 설정을 구성해야 합니다.

사전 요구 사항

  • 기존 Operator 프로젝트

절차

  1. 특정 Operator 번들이 지원되지 않고 특정 클러스터 버전 이후의 OpenShift Container Platform에서 올바르게 작동하지 않는 경우 Operator가 호환되는 최대 버전의 OpenShift Container Platform을 구성합니다. Operator 프로젝트의 CSV(클러스터 서비스 버전)에서 olm.maxOpenShiftVersion 주석을 설정하여 설치된 Operator를 호환 버전으로 업그레이드하기 전에 관리자가 클러스터를 업그레이드하지 못하도록 합니다.

    중요

    Operator 번들 버전이 이후 버전에서 작동할 수 없는 경우에만 olm.maxOpenShiftVersion 주석을 사용해야 합니다. 클러스터 관리자는 솔루션이 설치된 클러스터를 업그레이드할 수 없습니다. 이후 버전 및 유효한 업그레이드 경로를 제공하지 않으면 클러스터 관리자가 Operator를 제거하고 클러스터 버전을 업그레이드할 수 있습니다.

    olm.maxOpenShiftVersion 주석이 있는 CSV의 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: ClusterServiceVersion
    metadata:
      annotations:
        "olm.properties": '[{"type": "olm.maxOpenShiftVersion", "value": "<cluster_version>"}]' 1

    1
    Operator와 호환되는 최대 OpenShift Container Platform 클러스터 버전을 지정합니다. 예를 들어 value4.9로 설정하면 이 번들을 클러스터에 설치할 때 OpenShift Container Platform 버전 4.9 이후 버전으로 클러스터를 업그레이드할 수 없습니다.
  2. 번들이 Red Hat 제공 Operator 카탈로그에 배포되도록 설계된 경우 다음 속성을 설정하여 Operator에 대해 호환되는 OpenShift Container Platform 버전을 구성합니다. 이 구성을 사용하면 Operator가 OpenShift Container Platform의 대상 호환 버전을 대상으로 하는 카탈로그에만 포함됩니다.

    참고

    이 단계는 Red Hat 제공 카탈로그에서 Operator를 게시할 때만 유효합니다. 번들이 사용자 지정 카탈로그의 배포 전용인 경우 이 단계를 건너뛸 수 있습니다. 자세한 내용은 "Red Hat 제공 Operator 카탈로그"를 참조하십시오.

    1. 프로젝트의 bundle/metadata/annotations.yaml 파일에com.redhat.openshift.versions 주석을 설정합니다.

      호환 버전이 있는 bundle/metadata/annotations.yaml 파일의 예

      com.redhat.openshift.versions: "v4.7-v4.9" 1

      1
      범위 또는 단일 버전으로 설정합니다.
    2. 번들이 호환되지 않는 OpenShift Container Platform 버전으로 전달되지 않도록 하려면 Operator 번들 이미지에 있는 적절한 com.redhat.openshift.versions 라벨을 사용하여 인덱스 이미지가 생성되어야 합니다. 예를 들어 Operator SDK를 사용하여 프로젝트가 생성된 경우 bundle.Dockerfile 파일을 업데이트합니다.

      호환 버전이 있는 bundle.Dockerfile의 예

      LABEL com.redhat.openshift.versions="<versions>" 1

      1
      범위 또는 단일 버전으로 설정합니다 (예: v4.7-v4.9 ). 이 설정은 Operator를 배포해야 하는 클러스터 버전을 정의하고 범위 외부에 있는 클러스터 버전의 카탈로그에는 Operator가 표시되지 않습니다.

이제 새 버전의 Operator를 번들하고 업데이트된 버전을 배포 카탈로그에 게시할 수 있습니다.

추가 리소스

5.8.6. 추가 리소스