5.3. 경로 업데이트


설치된 클러스터 확장에 대한 업데이트 경로 (업그레이드 에지 또는 업그레이드 제약 조건이라고도 함)를 결정할 때 Operator Lifecycle Manager(OLM) v1은 OpenShift Container Platform 4.16부터 OLM(클래식) 의미 체계를 지원합니다. 이 지원은 replaces , skips , skipRange 지시어를 포함하여 OLM(클래식)의 동작을 따르지만 몇 가지 주목할 만한 차이점이 있습니다.

OLM(클래식) 의미론을 지원함으로써 OLM v1은 카탈로그의 업데이트 그래프를 정확하게 반영합니다.

원래 OLM(클래식) 구현과의 차이점

  • 가능한 후속자가 여러 명 있는 경우 OLM v1 동작은 다음과 같은 면에서 다릅니다.

    • OLM(클래식)에서는 채널 헤드에 가장 가까운 후속 채널이 선택됩니다.
    • OLM v1에서는 가장 높은 의미 버전(semver)을 가진 후속 버전이 선택됩니다.
  • 다음의 파일 기반 카탈로그(FBC) 채널 항목 세트를 고려하세요.

    # ...
    - name: example.v3.0.0
      skips: ["example.v2.0.0"]
    - name: example.v2.0.0
      skipRange: >=1.0.0 <2.0.0
    Copy to Clipboard Toggle word wrap

    1.0.0이 설치된 경우 OLM v1 동작은 다음과 같이 다릅니다.

    • OLM(클래식)은 v2.0.0 이 건너뛰어졌고 대체 체인에 없기 때문에 v2.0.0 에 대한 업데이트 경로를 감지하지 못합니다.
    • OLM v1에는 대체 체인이라는 개념이 없기 때문에 OLM v1은 업데이트 경로를 감지합니다. OLM v1은 현재 설치된 버전을 포함하는 replace , skip 또는 skipRange 값이 있는 모든 항목을 찾습니다.

5.3.1. 버전 범위 지원

Operator Lifecycle Manager(OLM) v1에서는 Operator 또는 확장 프로그램의 사용자 지정 리소스(CR)에 비교 문자열을 사용하여 버전 범위를 지정할 수 있습니다. CR에 버전 범위를 지정하면 OLM v1은 해당 버전 범위 내에서 해결 가능한 최신 버전의 Operator를 설치하거나 업데이트합니다.

해결된 버전 워크플로

  • 해결된 버전은 Operator와 환경의 제약 조건을 충족하는 Operator의 최신 버전입니다.
  • 지정된 범위 내의 운영자 업데이트는 성공적으로 해결되면 자동으로 설치됩니다.
  • 지정된 범위를 벗어나거나 성공적으로 해결할 수 없는 경우 업데이트는 설치되지 않습니다.

5.3.2. 버전 비교 문자열

Operator 또는 확장 프로그램의 사용자 정의 리소스(CR)에 있는 spec.version 필드에 비교 문자열을 추가하여 버전 범위를 정의할 수 있습니다. 비교 문자열은 공백이나 쉼표로 구분된 값과 큰따옴표( " )로 묶인 하나 이상의 비교 연산자 목록입니다. 문자열 사이에 OR 또는 이중 수직 막대( || ) 비교 연산자를 포함하여 다른 비교 문자열을 추가할 수 있습니다.

Expand
표 5.4. 기본 비교
비교 연산자정의

=

동일하다

!=

같지 않다

>

보다 크다

<

미만

>=

이상 또는 같음

<=

이하

다음 예와 유사한 범위 비교를 사용하여 연산자 또는 확장 프로그램의 CR에서 버전 범위를 지정할 수 있습니다.

예제 버전 범위 비교

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: ">=1.11, <1.13"
Copy to Clipboard Toggle word wrap

모든 유형의 비교 문자열에서 와일드카드 문자를 사용할 수 있습니다. OLM v1은 x , X 및 별표( * )를 와일드카드 문자로 허용합니다. 등호( = ) 비교 연산자와 함께 와일드카드 문자를 사용하면 패치 또는 마이너 버전 수준에서 비교를 정의합니다.

Expand
표 5.5. 비교 문자열의 와일드카드 문자 예
와일드카드 비교일치하는 문자열

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

~( 틸드 ) 비교 연산자를 사용하여 패치 릴리스를 비교할 수 있습니다. 패치 릴리스 비교는 다음 주요 버전까지의 하위 버전을 지정합니다.

Expand
표 5.6. 패치 릴리스 비교 예시
패치 릴리스 비교일치하는 문자열

~1.11.0

>=1.11.0, <1.12.0

~1

>=1, <2

~1.12

>=1.12, <1.13

~1.12.x

>=1.12.0, <1.13.0

~1.x

>=1, <2

주요 릴리스에 대한 비교를 하려면 캐럿( ^ ) 비교 연산자를 사용할 수 있습니다. 첫 번째 안정적인 릴리스가 출시되기 전에 주요 릴리스를 비교하는 경우, 하위 버전은 API의 안정성 수준을 정의합니다. 의미적 버전(semver) 사양에 따르면 첫 번째 안정적 릴리스는 1.0.0 버전으로 게시됩니다.

Expand
표 5.7. 주요 릴리스 비교 예시
주요 릴리스 비교일치하는 문자열

^0

>=0.0.0, <1.0.0

^0.0

>=0.0.0, <0.1.0

^0.0.3

>=0.0.3, <0.0.4

^0.2

>=0.2.0, <0.3.0

^0.2.3

>=0.2.3, <0.3.0

^1.2.x

>= 1.2.0, < 2.0.0

^1.2.3

>= 1.2.3, < 2.0.0

^2.x

>= 2.0.0, < 3

^2.3

>= 2.3, < 3

5.3.3. 대상 버전을 지정하는 사용자 정의 리소스(CR) 예시

Operator Lifecycle Manager(OLM) v1에서 클러스터 관리자는 사용자 지정 리소스(CR)에서 Operator 또는 확장 프로그램의 대상 버전을 선언적으로 설정할 수 있습니다.

다음 필드 중 하나를 지정하여 대상 버전을 정의할 수 있습니다.

  • 채널
  • 버전 번호
  • 버전 범위

CR에서 채널을 지정하면 OLM v1은 지정된 채널 내에서 확인 가능한 최신 버전의 Operator나 확장 프로그램을 설치합니다. 지정된 채널에 업데이트가 게시되면 OLM v1은 해당 채널에서 확인할 수 있는 최신 릴리스로 자동 업데이트됩니다.

지정된 채널이 있는 CR 예

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        channels:
          - latest 
1
Copy to Clipboard Toggle word wrap

1
선택 사항: 지정된 채널에서 해결 가능한 최신 릴리스를 설치합니다. 채널 업데이트는 자동으로 설치됩니다. channels 매개변수의 값을 배열로 지정합니다.

CR에서 운영자 또는 확장 프로그램의 대상 버전을 지정하면 OLM v1은 지정된 버전을 설치합니다. CR에 대상 버전이 지정되면 카탈로그에 업데이트가 게시될 때 OLM v1은 대상 버전을 변경하지 않습니다.

클러스터에 설치된 Operator 버전을 업데이트하려면 Operator의 CR을 수동으로 편집해야 합니다. 운영자의 대상 버전을 지정하면 운영자의 버전이 지정된 릴리스로 고정됩니다.

대상 버전이 지정된 CR 예

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: "1.11.1" 
1
Copy to Clipboard Toggle word wrap

1
선택 사항: 대상 버전을 지정합니다. 설치된 Operator나 확장 프로그램의 버전을 업데이트하려면 CR 필드를 원하는 대상 버전으로 수동으로 업데이트해야 합니다.

연산자나 확장 기능에 대해 허용되는 버전 범위를 정의하려면 비교 문자열을 사용하여 버전 범위를 지정할 수 있습니다. 버전 범위를 지정하면 OLM v1은 Operator Controller에서 확인할 수 있는 Operator 또는 확장 프로그램의 최신 버전을 설치합니다.

버전 범위가 지정된 CR 예

apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    serviceAccount:
      name: <service_account_installer_name>
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        version: ">1.11.1" 
1
Copy to Clipboard Toggle word wrap

1
선택 사항: 원하는 버전 범위가 버전 1.11.1 보다 큰지 지정합니다. 자세한 내용은 "버전 범위 지원"을 참조하세요.

CR을 생성하거나 업데이트한 후 다음 명령을 실행하여 구성 파일을 적용합니다.

명령 구문

$ oc apply -f <extension_name>.yaml
Copy to Clipboard Toggle word wrap

5.3.4. 업데이트 또는 롤백 강제 실행

OLM v1은 다음 주요 버전으로의 자동 업데이트나 이전 버전으로의 롤백을 지원하지 않습니다. 주요 버전 업데이트나 롤백을 수행하려면 업데이트를 수동으로 검증하고 강제로 적용해야 합니다.

주의

수동 업데이트나 롤백을 강제로 실행할 경우의 결과를 확인해야 합니다. 강제 업데이트나 롤백을 검증하지 못하면 데이터 손실과 같은 치명적인 결과가 초래될 수 있습니다.

사전 요구 사항

  • 카탈로그가 설치되었습니다.
  • Operator나 확장 프로그램이 설치되어 있습니다.
  • 설치하려는 확장 프로그램을 설치, 업데이트, 관리하는 데 필요한 서비스 계정을 만들고 역할 기반 액세스 제어(RBAC)를 할당했습니다. 자세한 내용은 서비스 계정 만들기를 참조하세요.

프로세스

  1. 다음 예와 같이 운영자 또는 확장 프로그램의 사용자 정의 리소스(CR)를 편집하세요.

    CR 예시

    apiVersion: olm.operatorframework.io/v1
      kind: ClusterExtension
      metadata:
        name: <clusterextension_name>
      spec:
        namespace: <installed_namespace> 
    1
    
        serviceAccount:
          name: <service_account_installer_name> 
    2
    
        source:
          sourceType: Catalog
          catalog:
            packageName: <package_name>
            channels:
              - <channel_name> 
    3
    
            version: <version_or_version_range> 
    4
    
            upgradeConstraintPolicy: SelfCertified 
    5
    Copy to Clipboard Toggle word wrap

    1
    번들을 설치할 네임스페이스(예: 파이프라인 또는 my-extension ) 를 지정합니다. 확장 프로그램은 여전히 클러스터 범위이며 다른 네임스페이스에 설치된 리소스를 포함할 수 있습니다.
    2
    확장 프로그램을 설치, 업데이트, 관리하기 위해 만든 서비스 계정의 이름을 지정합니다.
    3
    선택 사항: 파이프라인-1.14 또는 최신 과 같이 채널 이름을 배열로 지정합니다.
    4
    선택 사항: 설치 또는 업데이트하려는 패키지의 버전 또는 버전 범위(예: 1.14.0 , 1.14.x 또는 >=1.16 )를 지정합니다. 자세한 내용은 "대상 버전을 지정하는 사용자 정의 리소스(CR) 예시" 및 "버전 범위 지원"을 참조하세요.
    5
    선택 사항: 업그레이드 제약 정책을 지정합니다. 업데이트나 롤백을 강제로 실행하려면 필드를 SelfCertified 로 설정합니다. 지정하지 않으면 기본 설정은 CatalogProvided 입니다. CatalogProvided 설정은 새 버전이 패키지 작성자가 설정한 업그레이드 제약 조건을 충족하는 경우에만 업데이트됩니다.
  2. 다음 명령을 실행하여 Operator 또는 확장 프로그램 CR에 변경 사항을 적용하세요.

    $ oc apply -f <extension_name>.yaml
    Copy to Clipboard Toggle word wrap

5.3.5. OpenShift 컨테이너 플랫폼 버전과의 호환성

클러스터 관리자가 OpenShift Container Platform 클러스터를 다음 마이너 버전으로 업데이트하기 전에, 설치된 모든 Operator가 클러스터의 다음 마이너 버전(4.y+1)과 호환되는 번들 버전으로 업데이트되었는지 확인해야 합니다.

예를 들어, Kubernetes는 후속 릴리스에서 제거되는 특정 API를 주기적으로 사용 중단합니다. 확장 프로그램이 더 이상 사용되지 않는 API를 사용하는 경우, OpenShift Container Platform 클러스터가 API가 제거된 Kubernetes 버전으로 업데이트된 후에는 더 이상 작동하지 않을 수 있습니다.

운영자 작성자가 특정 번들 버전이 지원되지 않고 어떤 이유로든 특정 클러스터 마이너 버전 이후의 OpenShift Container Platform에서 제대로 작동하지 않을 것이라는 사실을 알고 있는 경우, 해당 운영자가 호환되는 OpenShift Container Platform의 최대 버전을 구성할 수 있습니다.

Operator 프로젝트의 클러스터 서비스 버전(CSV)에서 작성자는 olm.maxOpenShiftVersion 주석을 설정하여 관리자가 설치된 Operator를 호환 버전으로 업데이트하기 전에 클러스터를 업데이트하지 못하도록 할 수 있습니다.

olm.maxOpenShiftVersion 주석이 있는 CSV의 예

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

1
운영자가 호환되는 OpenShift Container Platform(4.y)의 최신 마이너 버전을 지정합니다. 예를 들어, 값을 4.19 로 설정하면 이 번들이 클러스터에 설치될 때 4.19 이후의 마이너 버전으로 클러스터 업데이트가 방지됩니다.

olm.maxOpenShiftVersion 필드가 생략되면 이 연산자는 클러스터 업데이트를 차단하지 않습니다.

참고

클러스터의 다음 마이너 버전(4.y+1)을 결정할 때 OLM v1은 비교를 위해 메이저 버전과 마이너 버전(x와 y)만 고려합니다. z-stream 버전(4.yz)은 무시됩니다. 이는 패치 릴리스 또는 사전 릴리스 버전이라고도 합니다.

예를 들어, 클러스터의 현재 버전이 4.19.0 이면 다음 마이너 버전은 4.20 입니다. 현재 버전이 4.19.0-rc1 인 경우, 다음의 마이너 버전은 여전히 4.20 입니다.

설치된 Operator의 olm.maxOpenShiftVersion 필드가 설정되어 있고 클러스터 관리자가 Operator가 유효한 업데이트 경로를 제공하지 않는 버전으로 클러스터를 업데이트하려고 시도하면 클러스터 업데이트가 실패하고 olm 클러스터 Operator의 업그레이드 가능 상태가 False 로 설정됩니다.

이 문제를 해결하려면 클러스터 관리자가 설치된 Operator를 유효한 업데이트 경로가 있는 버전으로 업데이트하거나(사용 가능한 경우) Operator를 제거해야 합니다. 그런 다음 클러스터 업데이트를 다시 시도할 수 있습니다.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat