2.4. OLM(Operator Lifecycle Manager)


2.4.1. Operator Lifecycle Manager 개념 및 리소스

이 가이드에서는 OpenShift Dedicated에서 OLM(Operator Lifecycle Manager)을 구동하는 개념에 대한 개요를 제공합니다.

2.4.1.1. Operator Lifecycle Manager란?

OLM( Operator Lifecycle Manager )은 사용자가 Kubernetes 네이티브 애플리케이션(Operator) 및 OpenShift Dedicated 클러스터에서 실행되는 관련 서비스를 설치, 업데이트 및 관리하는 데 도움이 됩니다. Operator 프레임워크의 일부로, 효과적이고 자동화되었으며 확장 가능한 방식으로 Operator를 관리하도록 설계된 오픈 소스 툴킷입니다.

그림 2.2. Operator Lifecycle Manager 워크플로

olm 워크플로

OLM은 기본적으로 OpenShift Dedicated 4에서 실행되며, 이를 통해 관리자는 클러스터에서 실행되는 Operator를 설치, 업그레이드, 액세스 권한을 부여하는 데 필요한 전용 관리자 역할을 수행할 수 있습니다. OpenShift Dedicated 웹 콘솔은 전용 관리자 화면을 제공하고 Operator를 설치할 수 있는 관리 화면을 제공하고, 특정 프로젝트에 클러스터에서 사용 가능한 Operator 카탈로그를 사용할 수 있는 액세스 권한을 부여합니다.

개발자의 경우 분야별 전문가가 아니어도 셀프서비스 경험을 통해 데이터베이스, 모니터링, 빅 데이터 서비스의 인스턴스를 프로비저닝하고 구성할 수 있습니다. Operator에서 해당 지식을 제공하기 때문입니다.

2.4.1.2. OLM 리소스

다음 CRD(사용자 정의 리소스 정의)는 OLM(Operator Lifecycle Manager)에서 정의하고 관리합니다.

표 2.2. OLM 및 Catalog Operator에서 관리하는 CRD
리소스짧은 이름설명

ClusterServiceVersion(CSV)

csv

애플리케이션 메타데이터입니다. 예를 들면 이름, 버전, 아이콘, 필수 리소스입니다.

CatalogSource

catsrc

애플리케이션을 정의하는 CSV, CRD, 패키지의 리포지토리입니다.

서브스크립션

sub

패키지의 채널을 추적하여 CSV를 최신 상태로 유지합니다.

InstallPlan

ip

CSV를 자동으로 설치하거나 업그레이드하기 위해 생성하는 계산된 리소스 목록입니다.

OperatorGroup

og

동일한 네임스페이스에 배포된 모든 Operator를 OperatorGroup 오브젝트로 구성하여 네임스페이스 목록 또는 클러스터 수준에서 CR(사용자 정의 리소스)을 조사합니다.

OperatorConditions

-

OLM과 OLM에서 관리하는 Operator 간 통신 채널을 생성합니다. Operator는 복잡한 상태를 OLM에 보고하기 위해 Status.Conditions 어레이에 작성할 수 있습니다.

2.4.1.2.1. 클러스터 서비스 버전

CSV( 클러스터 서비스 버전 )는 OpenShift Dedicated 클러스터에서 실행 중인 특정 버전의 Operator를 나타냅니다. 클러스터에서 Operator를 실행할 때 OLM(Operator Lifecycle Manager)을 지원하는 Operator 메타데이터에서 생성한 YAML 매니페스트입니다.

이러한 Operator 관련 메타데이터는 OLM이 클러스터에서 Operator가 계속 안전하게 실행되도록 유지하고 새 버전의 Operator가 게시되면 업데이트 적용 방법에 대한 정보를 제공하는 데 필요합니다. 이는 기존 운영 체제의 패키징 소프트웨어와 유사합니다. OLM 패키징 단계를 rpm, deb 또는 apk 번들을 생성하는 단계로 고려해 보십시오.

CSV에는 Operator 컨테이너 이미지와 함께 제공되는 메타데이터가 포함되며 이러한 데이터는 이름, 버전, 설명, 라벨, 리포지토리 링크, 로고와 같은 정보로 사용자 인터페이스를 채우는 데 사용됩니다.

CSV는 Operator를 실행하는 데 필요한 기술 정보의 소스이기도 합니다(예: RBAC 규칙, 클러스터 요구 사항, 설치 전략을 관리하고 사용하는 CR(사용자 정의 리소스)). 이 정보는 OLM에 필요한 리소스를 생성하고 Operator를 배포로 설정하는 방법을 지정합니다.

2.4.1.2.2. 카탈로그 소스

카탈로그 소스는 일반적으로 컨테이너 레지스트리에 저장된 인덱스 이미지를 참조하여 메타데이터 저장소를 나타냅니다. OLM(Operator Lifecycle Manager)은 카탈로그 소스를 쿼리하여 Operator 및 해당 종속성을 검색하고 설치합니다. OpenShift Dedicated 웹 콘솔의 OperatorHub에는 카탈로그 소스에서 제공하는 Operator도 표시됩니다.

작은 정보

클러스터 관리자는 웹 콘솔의 관리 클러스터 설정 구성 OperatorHub 페이지를 사용하여 클러스터에서 활성화된 카탈로그 소스에서 제공하는 전체 Operator 목록을 볼 수 있습니다.

CatalogSource 오브젝트의 spec은 Pod를 구성하는 방법 또는 Operator Registry gRPC API를 제공하는 서비스와 통신하는 방법을 나타냅니다.

예 2.9. CatalogSource 오브젝트의 예

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog 1
  namespace: openshift-marketplace 2
  annotations:
    olm.catalogImageTemplate: 3
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
spec:
  displayName: Example Catalog 4
  image: quay.io/example-org/example-catalog:v1 5
  priority: -400 6
  publisher: Example Org
  sourceType: grpc 7
  grpcPodConfig:
    securityContextConfig: <security_mode> 8
    nodeSelector: 9
      custom_label: <label>
    priorityClassName: system-cluster-critical 10
    tolerations: 11
      - key: "key1"
        operator: "Equal"
        value: "value1"
        effect: "NoSchedule"
  updateStrategy:
    registryPoll: 12
      interval: 30m0s
status:
  connectionState:
    address: example-catalog.openshift-marketplace.svc:50051
    lastConnect: 2021-08-26T18:14:31Z
    lastObservedState: READY 13
  latestImageRegistryPoll: 2021-08-26T18:46:25Z 14
  registryService: 15
    createdAt: 2021-08-26T16:16:37Z
    port: 50051
    protocol: grpc
    serviceName: example-catalog
    serviceNamespace: openshift-marketplace
1
CatalogSource 오브젝트의 이름입니다. 이 값은 요청된 네임스페이스에 생성된 관련 Pod의 이름으로도 사용됩니다.
2
카탈로그를 생성할 네임스페이스입니다. 카탈로그를 모든 네임스페이스에서 클러스터 전체로 사용하려면 이 값을 openshift-marketplace로 설정합니다. 기본 Red Hat 제공 카탈로그 소스에서도 openshift-marketplace 네임스페이스를 사용합니다. 그러지 않으면 해당 네임스페이스에서만 Operator를 사용할 수 있도록 값을 특정 네임스페이스로 설정합니다.
3
선택 사항: 클러스터 업그레이드를 통해 Operator 설치가 지원되지 않거나 지속적인 업데이트 경로가 없는 경우 클러스터 업그레이드의 일부로 Operator 카탈로그의 인덱스 이미지 버전을 자동으로 변경할 수 있습니다.

olm.catalogImageTemplate 주석을 인덱스 이미지 이름으로 설정하고 이미지 태그의 템플릿을 구성할 때 표시된 대로 하나 이상의 Kubernetes 클러스터 버전 변수를 사용합니다. 이 주석은 런타임 시 spec.image 필드를 덮어씁니다. 자세한 내용은 "사용자 지정 카탈로그 소스의 이미지 템플릿" 섹션을 참조하십시오.

4
웹 콘솔 및 CLI에 있는 카탈로그의 표시 이름입니다.
5
카탈로그의 인덱스 이미지입니다. 선택적으로 런타임 시 pull 사양을 설정하는 olm.catalogImageTemplate 주석을 사용할 때 생략할 수 있습니다.
6
카탈로그 소스의 가중치입니다. OLM은 종속성 확인 중에 가중치를 사용하여 우선순위를 지정합니다. 가중치가 높을수록 가중치가 낮은 카탈로그보다 카탈로그가 선호됨을 나타냅니다.
7
소스 유형에는 다음이 포함됩니다.
  • image 참조가 있는 grpc: OLM이 이미지를 가져온 후 Pod를 실행합니다. Pod는 규격 API를 제공할 것으로 예상됩니다.
  • address 필드가 있는 grpc: OLM이 지정된 주소에서 gRPC API에 연결을 시도합니다. 대부분의 경우 사용해서는 안 됩니다.
  • ConfigMap: OLM은 구성 맵 데이터를 구문 분석하고 이에 대해 gRPC API를 제공할 수 있는 Pod를 실행합니다.
8
legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 OpenShift Dedicated 릴리스에서는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.
9
선택 사항: grpc 유형 카탈로그 소스의 경우 정의된 경우 spec.image 의 콘텐츠를 제공하는 Pod의 기본 노드 선택기를 덮어씁니다.
10
선택 사항: grpc 유형 카탈로그 소스의 경우 정의된 경우 spec.image 의 콘텐츠를 제공하는 Pod의 기본 우선순위 클래스 이름을 덮어씁니다. Kubernetes는 기본적으로 system-cluster-criticalsystem-node-critical 우선순위 클래스를 제공합니다. 필드를 empty("")로 설정하면 Pod에 기본 우선순위가 할당됩니다. 다른 우선순위 클래스를 수동으로 정의할 수 있습니다.
11
선택 사항: grpc 유형 카탈로그 소스의 경우 정의된 경우 spec.image 의 콘텐츠를 제공하는 Pod의 기본 허용 오차를 덮어씁니다.
12
지정된 간격으로 새 버전을 자동으로 확인하여 최신 상태를 유지합니다.
13
카탈로그 연결의 마지막으로 관찰된 상태입니다. 예를 들면 다음과 같습니다.
  • READY: 성공적으로 연결되었습니다.
  • CONNECTING: 계속 연결을 시도합니다.
  • TRANSIENT_FAILURE: 연결을 시도하는 동안 시간 초과와 같은 일시적인 문제가 발생했습니다. 상태는 결국 CONNECTING으로 다시 전환되고 다시 연결 시도합니다.

자세한 내용은 gRPC 문서의 연결 상태를 참조하십시오.

14
카탈로그 이미지를 저장하는 컨테이너 레지스트리가 폴링되어 이미지가 최신 상태인지 확인할 수 있는 마지막 시간입니다.
15
카탈로그의 Operator 레지스트리 서비스의 상태 정보입니다.

서브스크립션의 CatalogSource 오브젝트 name을 참조하면 요청된 Operator를 찾기 위해 검색할 위치를 OLM에 지시합니다.

예 2.10. 카탈로그 소스를 참조하는 Subscription 오브젝트의 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace
2.4.1.2.2.1. 사용자 정의 카탈로그 소스의 이미지 템플릿

기본 클러스터와의 Operator 호환성은 다양한 방법으로 카탈로그 소스로 표시할 수 있습니다. 기본 Red Hat 제공 카탈로그 소스에 사용되는 한 가지 방법은 특정 플랫폼 릴리스(예: OpenShift Dedicated 4)용으로 특별히 생성된 인덱스 이미지의 이미지 태그를 식별하는 것입니다.

클러스터 업그레이드 중에 기본 Red Hat 제공 카탈로그 소스의 인덱스 이미지 태그는 CVO(Cluster Version Operator)에서 자동으로 업데이트하여 OLM(Operator Lifecycle Manager)이 업데이트된 버전의 카탈로그를 가져옵니다. 예를 들어 OpenShift Dedicated 4.16에서 4.17으로 업그레이드하는 동안 redhat-operators 카탈로그의 CatalogSource 오브젝트의 spec.image 필드가 다음에서 업데이트됩니다.

registry.redhat.io/redhat/redhat-operator-index:v4.16

다음으로 변경합니다.

registry.redhat.io/redhat/redhat-operator-index:v4.17

그러나 CVO는 사용자 정의 카탈로그의 이미지 태그를 자동으로 업데이트하지 않습니다. 클러스터 업그레이드 후 사용자가 호환 가능하고 지원되는 Operator 설치를 유지하려면 업데이트된 인덱스 이미지를 참조하도록 사용자 정의 카탈로그도 업데이트해야 합니다.

OpenShift Dedicated 4.9부터 클러스터 관리자는 사용자 정의 카탈로그의 CatalogSource 오브젝트에 olm.catalogImageTemplate 주석을 템플릿이 포함된 이미지 참조에 추가할 수 있습니다. 템플릿에서 사용할 수 있도록 지원되는 Kubernetes 버전 변수는 다음과 같습니다.

  • kube_major_version
  • kube_minor_version
  • kube_patch_version
참고

현재 템플릿에 사용할 수 없으므로 OpenShift Dedicated 클러스터 버전이 아닌 Kubernetes 클러스터 버전을 지정해야 합니다.

업데이트된 Kubernetes 버전을 지정하는 태그로 인덱스 이미지를 생성하고 푸시한 경우 이 주석을 설정하면 사용자 정의 카탈로그의 인덱스 이미지 버전이 클러스터 업그레이드 후 자동으로 변경될 수 있습니다. 주석 값은 CatalogSource 오브젝트의 spec.image 필드에서 이미지 참조를 설정하거나 업데이트하는 데 사용됩니다. 이로 인해 Operator가 지원되지 않는 상태이거나 지속적인 업데이트 경로가 없는 클러스터 업그레이드가 방지됩니다.

중요

업데이트된 태그가 있는 인덱스 이미지에 저장되어 있는 레지스트리가 클러스터 업그레이드 시 클러스터에서 액세스할 수 있는지 확인해야 합니다.

예 2.11. 이미지 템플릿이 있는 카탈로그 소스의 예

apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  generation: 1
  name: example-catalog
  namespace: openshift-marketplace
  annotations:
    olm.catalogImageTemplate:
      "quay.io/example-org/example-catalog:v{kube_major_version}.{kube_minor_version}"
spec:
  displayName: Example Catalog
  image: quay.io/example-org/example-catalog:v1.30
  priority: -400
  publisher: Example Org
참고

spec.image 필드와 olm.catalogImageTemplate 주석이 둘 다 설정된 경우 주석의 확인된 값으로 spec.image 필드를 덮어씁니다. 주석이 사용 가능한 풀 사양으로 확인되지 않으면 카탈로그 소스는 설정된 spec.image 값으로 대체됩니다.

spec.image 필드가 설정되지 않고 주석이 사용 가능한 풀 사양으로 확인되지 않으면 OLM에서 카탈로그 소스의 조정을 중지하고 사람이 읽을 수 있는 오류 조건으로 설정합니다.

Kubernetes 1.30을 사용하는 OpenShift Dedicated 4 클러스터의 경우 이전 예제의 olm.catalogImageTemplate 주석은 다음 이미지 참조로 확인됩니다.

quay.io/example-org/example-catalog:v1.30

향후 OpenShift Dedicated 릴리스에서는 이후 OpenShift Dedicated 버전에서 사용하는 이후 Kubernetes 버전을 대상으로 하는 사용자 정의 카탈로그에 대해 업데이트된 인덱스 이미지를 생성할 수 있습니다. 업그레이드 전에 olm.catalogImageTemplate 주석을 설정하면 클러스터를 이후 OpenShift Dedicated 버전으로 업그레이드하면 카탈로그의 인덱스 이미지도 자동으로 업데이트됩니다.

2.4.1.2.2.2. 카탈로그 상태 요구 사항

클러스터의 Operator 카탈로그는 설치 확인 관점에서 서로 바꿔 사용할 수 있습니다. 서브스크립션 오브젝트는 특정 카탈로그를 참조할 수 있지만 클러스터의 모든 카탈로그를 사용하여 종속성을 해결합니다.

예를 들어 카탈로그 A가 비정상이면 카탈로그 A를 참조하는 서브스크립션은 일반적으로 A보다 카탈로그 우선 순위가 낮기 때문에 클러스터 관리자가 예상하지 못할 수 있는 카탈로그 B의 종속성을 확인할 수 있습니다.

결과적으로 OLM에서는 지정된 글로벌 네임스페이스(예: 기본 openshift-marketplace 네임스페이스 또는 사용자 정의 글로벌 네임스페이스)가 있는 모든 카탈로그가 정상이어야 합니다. 카탈로그가 비정상이면 공유 글로벌 네임스페이스 내의 모든 Operator 설치 또는 업데이트 작업이 CatalogSourcesUnhealthy 조건으로 실패합니다. 비정상적인 상태에서 이러한 작업이 허용된 경우 OLM에서 클러스터 관리자에게 예기치 않은 확인 및 설치 결정을 내릴 수 있습니다.

클러스터 관리자는 비정상 카탈로그를 관찰하고 카탈로그를 유효하지 않은 것으로 간주하고 Operator 설치를 재개하려는 경우 비정상 카탈로그 제거에 대한 자세한 내용은 "사용자 정의 카탈로그 제거" 또는 "기본 OperatorHub 카탈로그 소스 비활성화" 섹션을 참조하십시오.

2.4.1.2.3. 서브스크립션

Subscription 오브젝트에서 정의하는 서브스크립션은 Operator를 설치하려는 의도를 나타냅니다. Operator와 카탈로그 소스를 연결하는 사용자 정의 리소스입니다.

서브스크립션은 Operator 패키지에서 구독할 채널과 업데이트를 자동 또는 수동으로 수행할지를 나타냅니다. 자동으로 설정된 경우 OLM(Operator Lifecycle Manager)은 서브스크립션을 통해 클러스터에서 항상 최신 버전의 Operator가 실행되도록 Operator를 관리하고 업그레이드합니다.

Subscription 개체 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: example-operator
  namespace: example-namespace
spec:
  channel: stable
  name: example-operator
  source: example-catalog
  sourceNamespace: openshift-marketplace

Subscription 오브젝트는 Operator의 이름 및 네임스페이스, Operator 데이터를 확인할 수 있는 카탈로그를 정의합니다. alpha, beta 또는 stable과 같은 채널은 카탈로그 소스에서 설치해야 하는 Operator 스트림을 결정하는 데 도움이 됩니다.

서브스크립션에서 채널 이름은 Operator마다 다를 수 있지만 이름 지정 스키마는 지정된 Operator 내의 공통 규칙을 따라야 합니다. 예를 들어 채널 이름은 Operator(1.2, 1.3) 또는 릴리스 빈도(stable, fast)에서 제공하는 애플리케이션의 마이너 릴리스 업데이트 스트림을 따를 수 있습니다.

OpenShift Dedicated 웹 콘솔에서 쉽게 볼 수 있을 뿐만 아니라 관련 서브스크립션의 상태를 검사하여 사용 가능한 최신 버전의 Operator가 있는 경우를 확인할 수 있습니다. currentCSV 필드와 연결된 값은 OLM에 알려진 최신 버전이고 installedCSV는 클러스터에 설치된 버전입니다.

2.4.1.2.4. 설치 계획

InstallPlan 오브젝트에서 정의하는 설치 계획은 OLM(Operator Lifecycle Manager)에서 특정 버전의 Operator로 설치 또는 업그레이드하기 위해 생성하는 리소스 세트를 설명합니다. 버전은 CSV(클러스터 서비스 버전)에서 정의합니다.

Operator, 클러스터 관리자 또는 Operator 설치 권한이 부여된 사용자를 설치하려면 먼저 Subscription 오브젝트를 생성해야 합니다. 서브스크립션은 카탈로그 소스에서 사용 가능한 Operator 버전의 스트림을 구독하려는 의도를 나타냅니다. 그런 다음 서브스크립션을 통해 Operator의 리소스를 쉽게 설치할 수 있도록 InstallPlan 오브젝트가 생성됩니다.

그런 다음 다음 승인 전략 중 하나에 따라 설치 계획을 승인해야 합니다.

  • 서브스크립션의 spec.installPlanApproval 필드가 Automatic로 설정된 경우 설치 계획이 자동으로 승인됩니다.
  • 서브스크립션의 spec.installPlanApproval 필드가 Manual로 설정된 경우 클러스터 관리자 또는 적절한 권한이 있는 사용자가 설치 계획을 수동으로 승인해야 합니다.

설치 계획이 승인되면 OLM에서 지정된 리소스를 생성하고 서브스크립션에서 지정한 네임스페이스에 Operator를 설치합니다.

예 2.12. InstallPlan 오브젝트의 예

apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
  name: install-abcde
  namespace: operators
spec:
  approval: Automatic
  approved: true
  clusterServiceVersionNames:
    - my-operator.v1.0.1
  generation: 1
status:
  ...
  catalogSources: []
  conditions:
    - lastTransitionTime: '2021-01-01T20:17:27Z'
      lastUpdateTime: '2021-01-01T20:17:27Z'
      status: 'True'
      type: Installed
  phase: Complete
  plan:
    - resolving: my-operator.v1.0.1
      resource:
        group: operators.coreos.com
        kind: ClusterServiceVersion
        manifest: >-
        ...
        name: my-operator.v1.0.1
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1alpha1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: apiextensions.k8s.io
        kind: CustomResourceDefinition
        manifest: >-
        ...
        name: webservers.web.servers.org
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1beta1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: ''
        kind: ServiceAccount
        manifest: >-
        ...
        name: my-operator
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: Role
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
    - resolving: my-operator.v1.0.1
      resource:
        group: rbac.authorization.k8s.io
        kind: RoleBinding
        manifest: >-
        ...
        name: my-operator.v1.0.1-my-operator-6d7cbc6f57
        sourceName: redhat-operators
        sourceNamespace: openshift-marketplace
        version: v1
      status: Created
      ...
2.4.1.2.5. Operator groups

OperatorGroup 리소스에서 정의하는 Operator group에서는 OLM에서 설치한 Operator에 다중 테넌트 구성을 제공합니다. Operator group은 멤버 Operator에 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

대상 네임스페이스 세트는 쉼표로 구분된 문자열 형식으로 제공되며 CSV(클러스터 서비스 버전)의 olm.targetNamespaces 주석에 저장되어 있습니다. 이 주석은 멤버 Operator의 CSV 인스턴스에 적용되며 해당 배포에 프로젝션됩니다.

추가 리소스

2.4.1.2.6. Operator 상태

OLM(Operator Lifecycle Manager)에서는 Operator의 라이프사이클을 관리하는 역할의 일부로, Operator를 정의하는 Kubernetes 리소스의 상태에서 Operator의 상태를 유추합니다. 이 접근 방식에서는 Operator가 지정된 상태에 있도록 어느 정도는 보장하지만 Operator에서 다른 방법으로는 유추할 수 없는 정보를 OLM에 보고해야 하는 경우가 많습니다. 그러면 OLM에서 이러한 정보를 사용하여 Operator의 라이프사이클을 더 효과적으로 관리할 수 있습니다.

OLM에서는 Operator에서 OLM에 조건을 보고할 수 있는 OperatorCondition이라는 CRD(사용자 정의 리소스 정의)를 제공합니다. OperatorCondition 리소스의 Spec.Conditions 어레이에 있는 경우 OLM의 Operator 관리에 영향을 줄 수 있는 일련의 조건이 지원됩니다.

참고

기본적으로 Spec.Conditions 어레이는 사용자가 추가하거나 사용자 정의 Operator 논리의 결과로 OperatorCondition 오브젝트에 존재하지 않습니다.

추가 리소스

2.4.2. Operator Lifecycle Manager 아키텍처

이 가이드에서는 OpenShift Dedicated의 OLM(Operator Lifecycle Manager) 구성 요소 아키텍처를 간략하게 설명합니다.

2.4.2.1. 구성 요소의 역할

OLM(Operator Lifecycle Manager)은 OLM Operator와 Catalog Operator의 두 Operator로 구성됩니다.

각 Operator는 OLM 프레임워크의 기반이 되는 CRD(사용자 정의 리소스 정의)를 관리합니다.

표 2.3. OLM 및 Catalog Operator에서 관리하는 CRD
리소스짧은 이름소유자Description

ClusterServiceVersion(CSV)

csv

OLM

애플리케이션 메타데이터: 이름, 버전, 아이콘, 필수 리소스, 설치 등입니다.

InstallPlan

ip

카탈로그

CSV를 자동으로 설치하거나 업그레이드하기 위해 생성하는 계산된 리소스 목록입니다.

CatalogSource

catsrc

카탈로그

애플리케이션을 정의하는 CSV, CRD, 패키지의 리포지토리입니다.

서브스크립션

sub

카탈로그

패키지의 채널을 추적하여 CSV를 최신 상태로 유지하는 데 사용됩니다.

OperatorGroup

og

OLM

동일한 네임스페이스에 배포된 모든 Operator를 OperatorGroup 오브젝트로 구성하여 네임스페이스 목록 또는 클러스터 수준에서 CR(사용자 정의 리소스)을 조사합니다.

또한 각 Operator는 다음 리소스를 생성합니다.

표 2.4. OLM 및 Catalog Operator에서 생성하는 리소스
리소스소유자

Deployments

OLM

ServiceAccounts

(Cluster)Roles

(Cluster)RoleBindings

CRD(CustomResourceDefinitions)

카탈로그

ClusterServiceVersions

2.4.2.2. OLM Operator

CSV에 지정된 필수 리소스가 클러스터에 제공되면 OLM Operator는 CSV 리소스에서 정의하는 애플리케이션을 배포합니다.

OLM Operator는 필수 리소스 생성과는 관련이 없습니다. CLI 또는 Catalog Operator를 사용하여 이러한 리소스를 수동으로 생성하도록 선택할 수 있습니다. 이와 같은 분리를 통해 사용자는 애플리케이션에 활용하기 위해 선택하는 OLM 프레임워크의 양을 점차 늘리며 구매할 수 있습니다.

OLM Operator에서는 다음 워크플로를 사용합니다.

  1. 네임스페이스에서 CSV(클러스터 서비스 버전)를 조사하고 해당 요구 사항이 충족되는지 확인합니다.
  2. 요구사항이 충족되면 CSV에 대한 설치 전략을 실행합니다.

    참고

    설치 전략을 실행하기 위해서는 CSV가 Operator group의 활성 멤버여야 합니다.

2.4.2.3. Catalog Operator

Catalog Operator는 CSV(클러스터 서비스 버전) 및 CSV에서 지정하는 필수 리소스를 확인하고 설치합니다. 또한 채널에서 패키지 업데이트에 대한 카탈로그 소스를 조사하고 원하는 경우 사용 가능한 최신 버전으로 자동으로 업그레이드합니다.

채널에서 패키지를 추적하려면 원하는 패키지를 구성하는 Subscription 오브젝트, 채널, 업데이트를 가져오는 데 사용할 CatalogSource 오브젝트를 생성하면 됩니다. 업데이트가 확인되면 사용자를 대신하여 네임스페이스에 적절한 InstallPlan 오브젝트를 기록합니다.

Catalog Operator에서는 다음 워크플로를 사용합니다.

  1. 클러스터의 각 카탈로그 소스에 연결합니다.
  2. 사용자가 생성한 설치 계획 중 확인되지 않은 계획이 있는지 조사하고 있는 경우 다음을 수행합니다.

    1. 요청한 이름과 일치하는 CSV를 찾아 확인된 리소스로 추가합니다.
    2. 각 관리 또는 필수 CRD의 경우 CRD를 확인된 리소스로 추가합니다.
    3. 각 필수 CRD에 대해 이를 관리하는 CSV를 확인합니다.
  3. 확인된 설치 계획을 조사하고 사용자의 승인에 따라 또는 자동으로 해당 계획에 대해 검색된 리소스를 모두 생성합니다.
  4. 카탈로그 소스 및 서브스크립션을 조사하고 이에 따라 설치 계획을 생성합니다.

2.4.2.4. 카탈로그 레지스트리

Catalog 레지스트리는 클러스터에서 생성할 CSV 및 CRD를 저장하고 패키지 및 채널에 대한 메타데이터를 저장합니다.

패키지 매니페스트는 패키지 ID를 CSV 세트와 연결하는 카탈로그 레지스트리의 항목입니다. 패키지 내에서 채널은 특정 CSV를 가리킵니다. CSV는 교체하는 CSV를 명시적으로 참조하므로 패키지 매니페스트는 Catalog Operator에 각 중간 버전을 거쳐 CSV를 최신 버전으로 업데이트하는 데 필요한 모든 정보를 제공합니다.

2.4.3. Operator Lifecycle Manager 워크플로

이 가이드에서는 OpenShift Dedicated의 OLM(Operator Lifecycle Manager)의 워크플로를 간략하게 설명합니다.

2.4.3.1. OLM의 Operator 설치 및 업그레이드 워크플로

OLM(Operator Lifecycle Manager) 에코시스템에서 다음 리소스를 사용하여 Operator 설치 및 업그레이드를 확인합니다.

  • ClusterServiceVersion(CSV)
  • CatalogSource
  • 서브스크립션

CSV에 정의된 Operator 메타데이터는 카탈로그 소스라는 컬렉션에 저장할 수 있습니다. OLM은 Operator Registry API를 사용하는 카탈로그 소스를 통해 사용 가능한 Operator와 설치된 Operator의 업그레이드를 쿼리합니다.

그림 2.3. 카탈로그 소스 개요

olm catalogsource

Operator는 카탈로그 소스 내에서 패키지채널 이라는 업데이트 스트림으로 구성됩니다. 이 업데이트 스트림은 웹 브라우저와 같은 지속적인 릴리스 사이클에서 OpenShift Dedicated 또는 기타 소프트웨어에서 친숙한 업데이트 패턴이어야 합니다.

그림 2.4. 카탈로그 소스의 패키지 및 채널

olm channels

사용자는 서브스크립션의 특정 카탈로그 소스에서 특정 패키지 및 채널(예: etcd 패키지 및 해당 alpha 채널)을 나타냅니다. 네임스페이스에 아직 설치되지 않은 패키지에 서브스크립션이 생성되면 해당 패키지의 최신 Operator가 설치됩니다.

참고

OLM에서는 의도적으로 버전을 비교하지 않으므로 지정된 카탈로그 채널 패키지 경로에서 사용 가능한 "최신" Operator의 버전 번호가 가장 높은 버전 번호일 필요는 없습니다. Git 리포지토리와 유사하게 채널의 헤드 참조로 간주해야 합니다.

각 CSV에는 교체 대상 Operator를 나타내는 replaces 매개변수가 있습니다. 이 매개변수를 통해 OLM에서 쿼리할 수 있는 CSV 그래프가 빌드되고 업데이트를 채널 간에 공유할 수 있습니다. 채널은 업데이트 그래프의 진입점으로 간주할 수 있습니다.

그림 2.5. 사용 가능한 채널 업데이트의 OLM 그래프

OLM 대체

패키지에 포함된 채널의 예

packageName: example
channels:
- name: alpha
  currentCSV: example.v0.1.2
- name: beta
  currentCSV: example.v0.1.3
defaultChannel: alpha

OLM에서 카탈로그 소스, 패키지, 채널, CSV와 관련된 업데이트를 쿼리하려면 카탈로그에서 입력 CSV를 replaces하는 단일 CSV를 모호하지 않게 결정적으로 반환할 수 있어야 합니다.

2.4.3.1.1. 업그레이드 경로의 예

업그레이드 시나리오 예제에서는 CSV 버전 0.1.1에 해당하는 Operator가 설치되어 있는 것으로 간주합니다. OLM은 카탈로그 소스를 쿼리하고 구독 채널에서 이전 버전이지만 설치되지 않은 CSV 버전 0.1.2를 교체하는(결국 설치된 이전 CSV 버전 0.1.1을 교체함) 새 CSV 버전 0.1.3이 포함된 업그레이드를 탐지합니다.

OLM은 CSV에 지정된 replaces 필드를 통해 채널 헤드에서 이전 버전으로 돌아가 업그레이드 경로 0.1.3 0.1.2 0.1.1을 결정합니다. 화살표 방향은 전자가 후자를 대체함을 나타냅니다. OLM은 채널 헤드에 도달할 때까지 Operator 버전을 한 번에 하나씩 업그레이드합니다.

지정된 이 시나리오의 경우 OLM은 Operator 버전 0.1.2를 설치하여 기존 Operator 버전 0.1.1을 교체합니다. 그런 다음 Operator 버전 0.1.3을 설치하여 이전에 설치한 Operator 버전 0.1.2를 대체합니다. 이 시점에 설치한 Operator 버전 0.1.3이 채널 헤드와 일치하며 업그레이드가 완료됩니다.

2.4.3.1.2. 업그레이드 건너뛰기

OLM의 기본 업그레이드 경로는 다음과 같습니다.

  • 카탈로그 소스는 Operator에 대한 하나 이상의 업데이트로 업데이트됩니다.
  • OLM은 카탈로그 소스에 포함된 최신 버전에 도달할 때까지 Operator의 모든 버전을 트래버스합니다.

그러나 경우에 따라 이 작업을 수행하는 것이 안전하지 않을 수 있습니다. 게시된 버전의 Operator가 아직 설치되지 않은 경우 클러스터에 설치해서는 안 되는 경우가 있습니다. 예를 들면 버전에 심각한 취약성이 있기 때문입니다.

이러한 경우 OLM에서는 두 가지 클러스터 상태를 고려하여 다음을 둘 다 지원하는 업데이트 그래프를 제공해야 합니다.

  • "잘못"된 중간 Operator가 클러스터에 표시되고 설치되었습니다.
  • "잘못된" 중간 Operator가 클러스터에 아직 설치되지 않았습니다.

새 카탈로그를 제공하고 건너뛰기 릴리스를 추가하면 클러스터 상태 및 잘못된 업데이트가 있는지와 관계없이 OLM에서 항상 고유한 단일 업데이트를 가져올 수 있습니다.

릴리스를 건너뛰는 CSV의 예

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
  name: etcdoperator.v0.9.2
  namespace: placeholder
  annotations:
spec:
    displayName: etcd
    description: Etcd Operator
    replaces: etcdoperator.v0.9.0
    skips:
    - etcdoperator.v0.9.1

기존 CatalogSource새 CatalogSource의 다음 예제를 고려하십시오.

그림 2.6. 업데이트 건너뛰기

업데이트를 건너뛰는 OLM

이 그래프에는 다음이 유지됩니다.

  • 기존 CatalogSource에 있는 모든 Operator에는 새 CatalogSource에 단일 대체 항목이 있습니다.
  • 새 CatalogSource에 있는 모든 Operator에는 새 CatalogSource에 단일 대체 항목이 있습니다.
  • 잘못된 업데이트가 아직 설치되지 않은 경우 설치되지 않습니다.
2.4.3.1.3. 여러 Operator 교체

설명된 새 CatalogSource를 생성하려면 하나의 Operator를 replace하지만 여러 Operator를 건너뛸 수 있는 CSV를 게시해야 합니다. 이 작업은 skipRange 주석을 사용하여 수행할 수 있습니다.

olm.skipRange: <semver_range>

여기서 <semver_range>에는 semver 라이브러리에서 지원하는 버전 범위 형식이 있습니다.

카탈로그에서 업데이트를 검색할 때 채널 헤드에 skipRange 주석이 있고 현재 설치된 Operator에 범위에 해당하는 버전 필드가 있는 경우 OLM이 채널의 최신 항목으로 업데이트됩니다.

우선순위 순서는 다음과 같습니다.

  1. 기타 건너뛰기 기준이 충족되는 경우 서브스크립션의 sourceName에 지정된 소스의 채널 헤드
  2. sourceName에 지정된 소스의 현재 Operator를 대체하는 다음 Operator
  3. 기타 건너뛰기 조건이 충족되는 경우 서브스크립션에 표시되는 다른 소스의 채널 헤드.
  4. 서브스크립션에 표시되는 모든 소스의 현재 Operator를 대체하는 다음 Operator.

skipRange가 있는 CSV의 예

apiVersion: operators.coreos.com/v1alpha1
kind: ClusterServiceVersion
metadata:
    name: elasticsearch-operator.v4.1.2
    namespace: <namespace>
    annotations:
        olm.skipRange: '>=4.1.0 <4.1.2'

2.4.3.1.4. z-stream 지원

마이너 버전이 동일한 경우 z-stream 또는 패치 릴리스로 이전 z-stream 릴리스를 모두 교체해야 합니다. OLM은 메이저, 마이너 또는 패치 버전을 구분하지 않으므로 카탈로그에 올바른 그래프만 빌드해야 합니다.

즉 OLM은 이전 CatalogSource에서와 같이 그래프를 가져올 수 있어야 하고 이전과 유사하게 새 CatalogSource에서와 같이 그래프를 생성할 수 있어야 합니다.

그림 2.7. 여러 Operator 교체

olm z 스트림

이 그래프에는 다음이 유지됩니다.

  • 기존 CatalogSource에 있는 모든 Operator에는 새 CatalogSource에 단일 대체 항목이 있습니다.
  • 새 CatalogSource에 있는 모든 Operator에는 새 CatalogSource에 단일 대체 항목이 있습니다.
  • 이전 CatalogSource의 모든 z-stream 릴리스가 새 CatalogSource의 최신 z-stream 릴리스로 업데이트됩니다.
  • 사용할 수 없는 릴리스는 "가상" 그래프 노드로 간주할 수 있습니다. 해당 콘텐츠가 존재할 필요는 없으며 그래프가 이와 같은 경우 레지스트리에서 응답하기만 하면 됩니다.

2.4.4. Operator Lifecycle Manager 종속성 확인

이 가이드에서는 OpenShift Dedicated의 OLM(Operator Lifecycle Manager)을 사용한 종속성 확인 및 CRD(사용자 정의 리소스 정의) 업그레이드 라이프사이클에 대해 간단히 설명합니다.

2.4.4.1. 종속성 확인 정보

OLM(Operator Lifecycle Manager)은 실행 중인 Operator의 종속성 확인 및 업그레이드 라이프사이클을 관리합니다. OLM에서 발생하는 문제는 여러 가지 면에서 yumrpm 과 같은 다른 시스템 또는 언어 패키지 관리자와 유사합니다.

그러나 OLM에는 유사한 시스템에는 일반적으로 해당하지 않는 한 가지 제약 조건이 있습니다. 즉 Operator가 항상 실행되고 있으므로 OLM에서 서로 함께 작동하지 않는 Operator 세트를 제공하지 않도록 합니다.

결과적으로 OLM에서 다음 시나리오를 생성하지 않아야 합니다.

  • 제공할 수 없는 API가 필요한 Operator 세트를 설치합니다.
  • Operator에 종속된 다른 Operator를 중단하는 방식으로 업데이트

이는 다음 두 가지 유형의 데이터로 가능합니다.

속성

종속성 확인기에서 공용 인터페이스를 구성하는 Operator에 대한 입력된 메타데이터입니다. 예를 들면 Operator에서 제공하는 API의 GVK(그룹/버전/종류)와 Operator의 의미 버전(semver)이 있습니다.

제약 조건 또는 종속 항목

대상 클러스터에 이미 설치되어 있거나 설치되지 않았을 수 있는 다른 Operator에서 충족해야 하는 Operator의 요구 사항입니다. 이는 사용 가능한 모든 Operator에 대한 쿼리 또는 필터 역할을 하며 종속성 확인 및 설치 중에 선택을 제한합니다. 예를 들면 클러스터에서 특정 API를 사용하거나 특정 버전이 설치된 특정 Operator가 설치되어 있어야 하는 경우가 있습니다.

OLM은 이러한 속성 및 제약 조건을 부울 공식 시스템으로 변환하고 이를 설치해야 하는 Operator를 결정하는 작업을 수행하는 부울 만족 가능성을 설정하는 프로그램인 SAT 솔버에 전달합니다.

2.4.4.2. Operator 속성

카탈로그의 모든 Operator에는 다음과 같은 속성이 있습니다.

olm.package
패키지 이름 및 Operator 버전이 포함됩니다.
olm.gvk
CSV(클러스터 서비스 버전)에서 제공되는 각 API의 단일 속성

Operator 번들의 metadata/ 디렉터리에 properties.yaml 파일을 포함하여 Operator 작성자가 추가 속성을 직접 선언할 수도 있습니다.

임의의 속성의 예

properties:
- type: olm.kubeversion
  value:
    version: "1.16.0"

2.4.4.2.1. 임의의 속성

Operator 작성자는 Operator 번들의 metadata/ 디렉터리에 있는 properties.yaml 파일에서 임의의 속성을 선언할 수 있습니다. 이러한 속성은 런타임 시 OLM(Operator Lifecycle Manager) 확인기에 대한 입력으로 사용되는 맵 데이터 구조로 변환됩니다.

이러한 속성은 속성을 이해할 수 없으므로 확인자에게 불투명하지만, 해당 속성에 대한 일반 제약 조건을 평가하여 속성 목록을 충족할 수 있는지 여부를 결정할 수 있습니다.

임의의 속성의 예

properties:
  - property:
      type: color
      value: red
  - property:
      type: shape
      value: square
  - property:
      type: olm.gvk
      value:
        group: olm.coreos.io
        version: v1alpha1
        kind: myresource

이 구조를 사용하여 일반 제약 조건에 대한 CEL(Common Expression Language) 표현식을 구성할 수 있습니다.

2.4.4.3. Operator 종속 항목

Operator의 종속 항목은 번들의 metadata/ 폴더에 있는 dependencies.yaml 파일에 나열되어 있습니다. 이 파일은 선택 사항이며 현재는 명시적인 Operator 버전 종속 항목을 지정하는 데만 사용됩니다.

종속성 목록에는 종속성의 유형을 지정하기 위해 각 항목에 대한 type 필드가 포함되어 있습니다. 다음과 같은 유형의 Operator 종속 항목이 지원됩니다.

olm.package
이 유형은 특정 Operator 버전에 대한 종속성을 나타냅니다. 종속 정보에는 패키지 이름과 패키지 버전이 semver 형식으로 포함되어야 합니다. 예를 들어 0.5.2와 같은 정확한 버전이나 >0.5.1과 같은 버전 범위를 지정할 수 있습니다.
olm.gvk
이 유형을 사용하면 작성자는 CSV의 기존 CRD 및 API 기반 사용과 유사하게 GVK(그룹/버전/종류) 정보를 사용하여 종속성을 지정할 수 있습니다. 이 경로를 통해 Operator 작성자는 모든 종속 항목, API 또는 명시적 버전을 동일한 위치에 통합할 수 있습니다.
olm.constraint
이 유형은 임의의 Operator 속성에 대한 일반 제약 조건을 선언합니다.

다음 예제에서는 Prometheus Operator 및 etcd CRD에 대한 종속 항목을 지정합니다.

dependencies.yaml 파일의 예

dependencies:
  - type: olm.package
    value:
      packageName: prometheus
      version: ">0.27.0"
  - type: olm.gvk
    value:
      group: etcd.database.coreos.com
      kind: EtcdCluster
      version: v1beta2

2.4.4.4. 일반 제약 조건

olm.constraint 속성은 특정 유형의 종속성 제약 조건을 선언하여 non-constraint 및 constraint 속성을 구분합니다. 해당 value 필드는 제약 조건 메시지의 문자열 표시가 있는 failureMessage 필드를 포함하는 오브젝트입니다. 이 메시지는 런타임 시 제약 조건이 만족스럽지 않은 경우 사용자에게 유용한 주석으로 표시됩니다.

다음 키는 사용 가능한 제약 조건 유형을 나타냅니다.

gvk
olm.gvk 유형과 동일한 값 및 해석을 입력합니다.
패키지
olm.package 유형과 동일한 값 및 해석을 입력합니다.
EL
임의의 번들 속성 및 클러스터 정보를 통해 OLM(Operator Lifecycle Manager) 확인자에 의해 런타임 시 평가되는 CEL(Common Expression Language) 표현식
all,any,not
gvk 또는 중첩된 복합 제약 조건과 같은 하나 이상의 구체적인 제약 조건을 각각 포함하는 결합, 제거 및 부정 제약 조건
2.4.4.4.1. CEL(Common Expression Language) 제약 조건

Cel 제약 조건 유형은 CEL(Common Expression Language) 을 표현식 언어로 지원합니다. cel struct에는 Operator가 제약 조건을 충족하는지 확인하기 위해 런타임 시 Operator 속성에 대해 평가되는 CEL 표현식 문자열이 포함된 rule 필드가 있습니다.

cel 제약 조건 예

type: olm.constraint
value:
  failureMessage: 'require to have "certified"'
  cel:
    rule: 'properties.exists(p, p.type == "certified")'

CEL 구문은 ANDOR 와 같은 다양한 논리 연산자를 지원합니다. 결과적으로 단일 CEL 표현식에는 이러한 논리 연산자가 함께 연결된 여러 조건에 대해 여러 규칙이 있을 수 있습니다. 이러한 규칙은 번들 또는 지정된 소스와 다른 여러 속성의 데이터 집합에 대해 평가되며 단일 제약 조건 내에서 모든 규칙을 충족하는 단일 번들 또는 Operator로 출력이 해결됩니다.

여러 규칙이 있는 cel 제약 조건의 예

type: olm.constraint
value:
  failureMessage: 'require to have "certified" and "stable" properties'
  cel:
    rule: 'properties.exists(p, p.type == "certified") && properties.exists(p, p.type == "stable")'

2.4.4.4.2. 복합 제약 조건 (모두, 일부, 아님)

복합 제약 조건 유형은 논리 정의에 따라 평가됩니다.

다음은 두 패키지의 연속 제약 조건(모두)과 하나의 GVK의 예입니다. 즉, 설치된 번들로 모두 충족해야 합니다.

모든 제약 조건의 예

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: All are required for Red because...
    all:
      constraints:
      - failureMessage: Package blue is needed for...
        package:
          name: blue
          versionRange: '>=1.0.0'
      - failureMessage: GVK Green/v1 is needed for...
        gvk:
          group: greens.example.com
          version: v1
          kind: Green

다음은 동일한 GVK의 세 가지 버전의 disjunctive 제약 조건 (any)의 예입니다. 즉, 설치된 번들로 하나 이상을 충족해야 합니다.

제약 조건 예

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: Any are required for Red because...
    any:
      constraints:
      - gvk:
          group: blues.example.com
          version: v1beta1
          kind: Blue
      - gvk:
          group: blues.example.com
          version: v1beta2
          kind: Blue
      - gvk:
          group: blues.example.com
          version: v1
          kind: Blue

다음은 하나의 GVK 버전의 부정 제약 조건(Not)의 예입니다. 즉 결과 집합의 모든 번들에서 GVK를 제공할 수 없습니다.

제약 조건이 아닌

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
  all:
    constraints:
    - failureMessage: Package blue is needed for...
      package:
        name: blue
        versionRange: '>=1.0.0'
    - failureMessage: Cannot be required for Red because...
      not:
        constraints:
        - gvk:
            group: greens.example.com
            version: v1alpha1
            kind: greens

부정 의미 체계는 제약 조건이 아닌 컨텍스트에서 명확하지 않을 수 있습니다. 명확히하기 위해 부정은 특정 GVK, 버전에서 패키지 또는 결과 세트에서 일부 하위 복합 제약 조건을 충족하는 가능한 솔루션을 제거하도록 해결자에게 실제로 지시하고 있습니다.

코롤리(corollary)로서, not compound constraint는 모든 또는 임의의 제약 조건 내에서만 사용해야 하는데, 이는 우선 가능한 종속성 세트를 선택하지 않고 부정하는 것은 의미가 없기 때문입니다.

2.4.4.4.3. 중첩된 복합 제약 조건

0개 이상의 간단한 제약 조건과 함께 하나 이상의 하위 복합 제약 조건을 포함하는 중첩된 복합 제약 조건은 이전에 설명한 각 제약 조건 유형에 대한 프로시저에 따라 평가됩니다.A nested compound constraint, one that contains at least one child compound constraint along with zero or more simple constraints, is evaluated from the bottom up the procedures for each previously described constraint type.

다음은 연결 해제의 예이며, 여기서 하나, 다른 또는 둘 다 제약 조건을 충족할 수 있습니다.

중첩된 복합 제약 조건의 예

schema: olm.bundle
name: red.v1.0.0
properties:
- type: olm.constraint
  value:
    failureMessage: Required for Red because...
    any:
      constraints:
      - all:
          constraints:
          - package:
              name: blue
              versionRange: '>=1.0.0'
          - gvk:
              group: blues.example.com
              version: v1
              kind: Blue
      - all:
          constraints:
          - package:
              name: blue
              versionRange: '<1.0.0'
          - gvk:
              group: blues.example.com
              version: v1beta1
              kind: Blue

참고

olm.constraint 유형의 최대 원시 크기는 리소스 소진 공격을 제한하는 64KB입니다.

2.4.4.5. 종속 기본 설정

Operator의 종속성을 동등하게 충족하는 옵션이 여러 개가 있을 수 있습니다. OLM(Operator Lifecycle Manager)의 종속성 확인자는 요청된 Operator의 요구 사항에 가장 적합한 옵션을 결정합니다. Operator 작성자 또는 사용자에게는 명확한 종속성 확인을 위해 이러한 선택이 어떻게 이루어지는지 이해하는 것이 중요할 수 있습니다.

2.4.4.5.1. 카탈로그 우선순위

OpenShift Dedicated 클러스터에서 OLM은 카탈로그 소스를 읽고 설치에 사용할 수 있는 Operator를 확인합니다.

CatalogSource 오브젝트의 예

apiVersion: "operators.coreos.com/v1alpha1"
kind: "CatalogSource"
metadata:
  name: "my-operators"
  namespace: "operators"
spec:
  sourceType: grpc
  grpcPodConfig:
    securityContextConfig: <security_mode> 1
  image: example.com/my/operator-index:v1
  displayName: "My Operators"
  priority: 100

1
legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 OpenShift Dedicated 릴리스에서는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.

CatalogSource 오브젝트에는 priority 필드가 있으며 확인자는 이 필드를 통해 종속성에 대한 옵션의 우선순위를 부여하는 방법을 확인합니다.

카탈로그 기본 설정을 관리하는 규칙에는 다음 두 가지가 있습니다.

  • 우선순위가 높은 카탈로그의 옵션이 우선순위가 낮은 카탈로그의 옵션보다 우선합니다.
  • 종속 항목과 동일한 카탈로그의 옵션이 다른 카탈로그보다 우선합니다.
2.4.4.5.2. 채널 순서

카탈로그의 Operator 패키지는 사용자가 OpenShift Dedicated 클러스터에서 구독할 수 있는 업데이트 채널 컬렉션입니다. 채널은 마이너 릴리스(1.2, 1.3) 또는 릴리스 빈도(stable, fast)에 대해 특정 업데이트 스트림을 제공하는 데 사용할 수 있습니다.

동일한 패키지에 있지만 채널이 다른 Operator로 종속성을 충족할 수 있습니다. 예를 들어 버전 1.2의 Operator는 stablefast 채널 모두에 존재할 수 있습니다.

각 패키지에는 기본이 채널이 있으며 항상 기본이 아닌 채널에 우선합니다. 기본 채널의 옵션으로 종속성을 충족할 수 없는 경우 남아 있는 채널의 옵션을 채널 이름의 사전 순으로 고려합니다.

2.4.4.5.3. 채널 내 순서

대부분의 경우 단일 채널 내에는 종속성을 충족하는 옵션이 여러 개 있습니다. 예를 들어 하나의 패키지 및 채널에 있는 Operator에서는 동일한 API 세트를 제공합니다.

이는 사용자가 서브스크립션을 생성할 때 업데이트를 수신하는 채널을 나타냅니다. 이를 통해 검색 범위가 이 하나의 채널로 즉시 줄어듭니다. 하지만 채널 내에서 다수의 Operator가 종속성을 충족할 수 있습니다.

채널 내에서는 업데이트 그래프에서 더 높이 있는 최신 Operator가 우선합니다. 채널 헤드에서 종속성을 충족하면 먼저 시도됩니다.

2.4.4.5.4. 기타 제약 조건

패키지 종속 항목에서 제공하는 제약 조건 외에도 OLM에는 필요한 사용자 상태를 나타내고 확인 불변성을 적용하는 추가 제약 조건이 포함됩니다.

2.4.4.5.4.1. 서브스크립션 제약 조건

서브스크립션 제약 조건은 서브스크립션을 충족할 수 있는 Operator 세트를 필터링합니다. 서브스크립션은 종속성 확인자에 대한 사용자 제공 제약 조건입니다. Operator가 클러스터에 없는 경우 새 Operator를 설치하거나 기존 Operator를 계속 업데이트할지를 선언합니다.

2.4.4.5.4.2. 패키지 제약 조건

하나의 네임스페이스 내에 동일한 패키지의 두 Operator가 제공되지 않을 수 있습니다.

2.4.4.5.5. 추가 리소스

2.4.4.6. CRD 업그레이드

OLM은 CRD(사용자 정의 리소스 정의)가 단수형 CSV(클러스터 서비스 버전)에 속하는 경우 CRD를 즉시 업그레이드합니다. CRD가 여러 CSV에 속하는 경우에는 다음과 같은 하위 호환 조건을 모두 충족할 때 CRD가 업그레이드됩니다.

  • 현재 CRD의 기존 서비스 버전은 모두 새 CRD에 있습니다.
  • CRD 제공 버전과 연결된 기존의 모든 인스턴스 또는 사용자 정의 리소스는 새 CRD의 검증 스키마에 대해 검증할 때 유효합니다.

2.4.4.7. 종속성 모범 사례

종속 항목을 지정할 때는 모범 사례를 고려해야 합니다.

API 또는 특정 버전의 Operator 범위에 따라
Operator는 언제든지 API를 추가하거나 제거할 수 있습니다. 항상 Operator에서 요구하는 API에 olm.gvk 종속성을 지정합니다. 이에 대한 예외는 대신 olm.package 제약 조건을 지정하는 경우입니다.
최소 버전 설정

API 변경에 대한 Kubernetes 설명서에서는 Kubernetes 스타일 Operator에 허용되는 변경 사항을 설명합니다. 이러한 버전 관리 규칙을 사용하면 API가 이전 버전과 호환되는 경우 Operator에서 API 버전 충돌 없이 API를 업데이트할 수 있습니다.

Operator 종속 항목의 경우 이는 API 버전의 종속성을 확인하는 것으로는 종속 Operator가 의도한 대로 작동하는지 확인하는 데 충분하지 않을 수 있을 의미합니다.

예를 들면 다음과 같습니다.

  • TestOperator v1.0.0에서는 v1alpha1 API 버전의 MyObject 리소스를 제공합니다.
  • TestOperator v1.0.1에서는 새 필드 spec.newfieldMyObject에 추가하지만 여전히 v1alpha1입니다.

Operator에 spec.newfieldMyObject 리소스에 쓰는 기능이 필요할 수 있습니다. olm.gvk 제약 조건만으로는 OLM에서 TestOperator v1.0.0이 아닌 TestOperator v1.0.1이 필요한 것으로 판단하는 데 충분하지 않습니다.

가능한 경우 API를 제공하는 특정 Operator를 미리 알고 있는 경우 추가 olm.package 제약 조건을 지정하여 최솟값을 설정합니다.

최대 버전 생략 또는 광범위한 범위 허용

Operator는 API 서비스 및 CRD와 같은 클러스터 범위의 리소스를 제공하기 때문에 짧은 종속성 기간을 지정하는 Operator는 해당 종속성의 다른 소비자에 대한 업데이트를 불필요하게 제한할 수 있습니다.

가능한 경우 최대 버전을 설정하지 마십시오. 또는 다른 Operator와 충돌하지 않도록 매우 광범위한 의미 범위를 설정하십시오. 예를 들면 >1.0.0 <2.0.0과 같습니다.

기존 패키지 관리자와 달리 Operator 작성자는 OLM의 채널을 통해 업데이트가 안전함을 명시적으로 인코딩합니다. 기존 서브스크립션에 대한 업데이트가 제공되면 Operator 작성자가 이전 버전에서 업데이트할 수 있음을 나타내는 것으로 간주합니다. 종속성에 최대 버전을 설정하면 특정 상한에서 불필요하게 잘라 작성자의 업데이트 스트림을 덮어씁니다.

참고

클러스터 관리자는 Operator 작성자가 설정한 종속 항목을 덮어쓸 수 없습니다.

그러나 피해야 하는 알려진 비호환성이 있는 경우 최대 버전을 설정할 수 있으며 설정해야 합니다. 버전 범위 구문을 사용하여 특정 버전을 생략할 수 있습니다(예: > 1.0.0 !1.2.1).

추가 리소스

2.4.4.8. 종속성 경고

종속성을 지정할 때 고려해야 할 경고 사항이 있습니다.

혼합 제약 조건(AND) 없음

현재 제약 조건 간 AND 관계를 지정할 수 있는 방법은 없습니다. 즉 하나의 Operator가 지정된 API를 제공하면서 버전이 >1.1.0인 다른 Operator에 종속되도록 지정할 수 없습니다.

즉 다음과 같은 종속성을 지정할 때를 나타냅니다.

dependencies:
- type: olm.package
  value:
    packageName: etcd
    version: ">3.1.0"
- type: olm.gvk
  value:
    group: etcd.database.coreos.com
    kind: EtcdCluster
    version: v1beta2

OLM은 EtcdCluster를 제공하는 Operator와 버전이 >3.1.0인 Operator를 사용하여 이러한 조건을 충족할 수 있습니다. 이러한 상황이 발생하는지 또는 두 제약 조건을 모두 충족하는 Operator가 선택되었는지는 잠재적 옵션을 방문하는 순서에 따라 다릅니다. 종속성 기본 설정 및 순서 지정 옵션은 잘 정의되어 있으며 추론할 수 있지만 주의를 기울이기 위해 Operator는 둘 중 하나의 메커니즘을 유지해야 합니다.

네임스페이스 간 호환성
OLM은 네임스페이스 범위에서 종속성 확인을 수행합니다. 한 네임스페이스의 Operator를 업데이트하면 다른 네임스페이스의 Operator에 문제가 되고 반대의 경우도 마찬가지인 경우 업데이트 교착 상태에 빠질 수 있습니다.

2.4.4.9. 종속성 확인 시나리오 예제

다음 예제에서 공급자는 CRD 또는 API 서비스를 "보유"한 Operator입니다.

예: 종속 API 사용 중단

A 및 B는 다음과 같은 API입니다(CRD).

  • A 공급자는 B에 의존합니다.
  • B 공급자에는 서브스크립션이 있습니다.
  • C를 제공하도록 B 공급자를 업데이트하지만 B를 더 이상 사용하지 않습니다.

결과는 다음과 같습니다.

  • B에는 더 이상 공급자가 없습니다.
  • A가 더 이상 작동하지 않습니다.

이는 OLM에서 업그레이드 전략으로 방지하는 사례입니다.

예: 버전 교착 상태

A 및 B는 다음과 같은 API입니다.

  • A 공급자에는 B가 필요합니다.
  • B 공급자에는 A가 필요합니다.
  • A 공급자를 업데이트(A2 제공, B2 요청)하고 A를 더 이상 사용하지 않습니다.
  • B 공급자를 업데이트(A2 제공, B2 요청)하고 B를 더 이상 사용하지 않습니다.

OLM에서 B를 동시에 업데이트하지 않고 A를 업데이트하거나 반대 방향으로 시도하는 경우 새 호환 가능 세트가 있는 경우에도 새 버전의 Operator로 진행할 수 없습니다.

이는 OLM에서 업그레이드 전략으로 방지하는 또 다른 사례입니다.

2.4.5. Operator groups

이 가이드에서는 OpenShift Dedicated의 OLM(Operator Lifecycle Manager)에서 Operator groups을 사용하는 방법을 간략하게 설명합니다.

2.4.5.1. Operator groups 정의

OperatorGroup 리소스에서 정의하는 Operator group에서는 OLM에서 설치한 Operator에 다중 테넌트 구성을 제공합니다. Operator group은 멤버 Operator에 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

대상 네임스페이스 세트는 쉼표로 구분된 문자열 형식으로 제공되며 CSV(클러스터 서비스 버전)의 olm.targetNamespaces 주석에 저장되어 있습니다. 이 주석은 멤버 Operator의 CSV 인스턴스에 적용되며 해당 배포에 프로젝션됩니다.

2.4.5.2. Operator group 멤버십

다음 조건이 충족되면 Operator가 Operator group의 멤버로 간주됩니다.

  • Operator의 CSV는 Operator group과 동일한 네임스페이스에 있습니다.
  • Operator의 CSV 설치 모드에서는 Operator group이 대상으로 하는 네임스페이스 세트를 지원합니다.

CSV의 설치 모드는 InstallModeType 필드 및 부울 Supported 필드로 구성됩니다. CSV 사양에는 다음 네 가지 InstallModeTypes로 구성된 설치 모드 세트가 포함될 수 있습니다.

표 2.5. 설치 모드 및 지원되는 Operator groups
InstallModeType설명

OwnNamespace

Operator가 자체 네임스페이스를 선택하는 Operator group의 멤버일 수 있습니다.

SingleNamespace

Operator가 하나의 네임스페이스를 선택하는 Operator group의 멤버일 수 있습니다.

MultiNamespace

Operator가 네임스페이스를 두 개 이상 선택하는 Operator group의 멤버일 수 있습니다.

AllNamespaces

Operator가 네임스페이스를 모두 선택하는 Operator group의 멤버일 수 있습니다(대상 네임스페이스 세트는 빈 문자열("")임).

참고

CSV 사양에서 InstallModeType 항목이 생략되면 암시적으로 지원하는 기존 항목에서 지원을 유추할 수 있는 경우를 제외하고 해당 유형을 지원하지 않는 것으로 간주합니다.

2.4.5.3. 대상 네임스페이스 선택

spec.targetNamespaces 매개변수를 사용하여 Operator group의 대상 네임스페이스의 이름을 명시적으로 지정할 수 있습니다.

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

또는 라벨 선택기를 spec.selector 매개변수와 함께 사용하여 네임스페이스를 지정할 수도 있습니다.

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace
spec:
  selector:
    cool.io/prod: "true"
중요

spec.targetNamespaces를 통해 여러 네임스페이스를 나열하거나 spec.selector를 통해 라벨 선택기를 사용하는 것은 바람직하지 않습니다. Operator group의 대상 네임스페이스 두 개 이상에 대한 지원이 향후 릴리스에서 제거될 수 있습니다.

spec.targetNamespacesspec.selector를 둘 다 정의하면 spec.selector가 무시됩니다. 또는 모든 네임스페이스를 선택하는 global Operator group을 지정하려면 spec.selectorspec.targetNamespaces를 둘 다 생략하면 됩니다.

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: my-group
  namespace: my-namespace

선택된 네임스페이스의 확인된 세트는 Opeator group의 status.namespaces 매개변수에 표시됩니다. 글로벌 Operator group의 status.namespace에는 사용 중인 Operator에 모든 네임스페이스를 조사해야 함을 알리는 빈 문자열("")이 포함됩니다.

2.4.5.4. Operator group CSV 주석

Operator group의 멤버 CSV에는 다음과 같은 주석이 있습니다.

주석설명

olm.operatorGroup=<group_name>

Operator group의 이름을 포함합니다.

olm.operatorNamespace=<group_namespace>

Operator group의 네임스페이스를 포함합니다.

olm.targetNamespaces=<target_namespaces>

Operator group의 대상 네임스페이스 선택 사항을 나열하는 쉼표로 구분된 문자열을 포함합니다.

참고

olm.targetNamespaces를 제외한 모든 주석은 CSV 복사본에 포함됩니다. CSV 복제본에서 olm.targetNamespaces 주석을 생략하면 테넌트 간에 대상 네임스페이스를 복제할 수 없습니다.

2.4.5.5. 제공된 API 주석

GVK(그룹/버전/종류)는 Kubernetes API의 고유 ID입니다. Operator group에서 제공하는 GVK에 대한 정보는 olm.providedAPIs 주석에 표시됩니다. 주석 값은 <kind>.<version>.<group>으로 구성된 문자열로, 쉼표로 구분됩니다. Operator group의 모든 활성 멤버 CSV에서 제공하는 CRD 및 API 서비스의 GVK가 포함됩니다.

PackageManifest 리소스를 제공하는 하나의 활성 멤버 CSV에서 OperatorGroup 오브젝트의 다음 예제를 검토합니다.

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  annotations:
    olm.providedAPIs: PackageManifest.v1alpha1.packages.apps.redhat.com
  name: olm-operators
  namespace: local
  ...
spec:
  selector: {}
  serviceAccount:
    metadata:
      creationTimestamp: null
  targetNamespaces:
  - local
status:
  lastUpdated: 2019-02-19T16:18:28Z
  namespaces:
  - local

2.4.5.6. 역할 기반 액세스 제어

Operator v이 생성되면 세 개의 클러스터 역할이 생성됩니다. 각 역할에는 다음과 같이 라벨과 일치하도록 클러스터 역할 선택기가 설정된 단일 집계 규칙이 포함됩니다.

클러스터 역할일치해야 하는 라벨

olm.og.<operatorgroup_name>-admin-<hash_value>

olm.opgroup.permissions/aggregate-to-admin: <operatorgroup_name>

olm.og.<operatorgroup_name>-edit-<hash_value>

olm.opgroup.permissions/aggregate-to-edit: <operatorgroup_name>

olm.og.<operatorgroup_name>-view-<hash_value>

olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

다음 RBAC 리소스는 CSV가 AllNamespaces 설치 모드로 모든 네임스페이스를 조사하고 이유가 InterOperatorGroupOwnerConflict인 실패 상태가 아닌 한 CSV가 Operator group의 활성 멤버가 될 때 생성됩니다.

  • CRD의 각 API 리소스에 대한 클러스터 역할
  • API 서비스의 각 API 리소스에 대한 클러스터 역할
  • 추가 역할 및 역할 바인딩
표 2.6. CRD에서 각 API 리소스에 대해 생성된 클러스터 역할
클러스터 역할설정

<kind>.<group>-<version>-admin

<kind>의 동사:

  • *

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-admin: true
  • olm.opgroup.permissions/aggregate-to-admin: <operatorgroup_name>

<kind>.<group>-<version>-edit

<kind>의 동사:

  • create
  • update
  • patch
  • delete

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-edit: true
  • olm.opgroup.permissions/aggregate-to-edit: <operatorgroup_name>

<kind>.<group>-<version>-view

<kind>의 동사:

  • get
  • list
  • watch

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-view: true
  • olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

<kind>.<group>-<version>-view-crdview

apiextensions.k8s.io customresourcedefinitions <crd-name>의 동사:

  • get

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-view: true
  • olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>
표 2.7. API 서비스에서 각 API 리소스에 대해 생성한 클러스터 역할
클러스터 역할설정

<kind>.<group>-<version>-admin

<kind>의 동사:

  • *

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-admin: true
  • olm.opgroup.permissions/aggregate-to-admin: <operatorgroup_name>

<kind>.<group>-<version>-edit

<kind>의 동사:

  • create
  • update
  • patch
  • delete

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-edit: true
  • olm.opgroup.permissions/aggregate-to-edit: <operatorgroup_name>

<kind>.<group>-<version>-view

<kind>의 동사:

  • get
  • list
  • watch

집계 라벨:

  • rbac.authorization.k8s.io/aggregate-to-view: true
  • olm.opgroup.permissions/aggregate-to-view: <operatorgroup_name>

추가 역할 및 역할 바인딩

  • CSV에서 *를 포함하는 정확히 하나의 대상 네임스페이스를 정의하는 경우 CSV의 permissions 필드에 정의된 각 권한에 대해 클러스터 역할 및 해당 클러스터 역할 바인딩이 생성됩니다. 생성된 모든 리소스에는 olm.owner: <csv_name>olm.owner.namespace: <csv_namespace> 라벨이 지정됩니다.
  • CSV에서 *를 포함하는 정확히 하나의 대상 네임스페이스를 정의하지 않는 경우에는 olm.owner: <csv_name>olm.owner.namespace: <csv_namespace> 라벨이 있는 Operator 네임스페이스의 모든 역할 및 역할 바인딩이 대상 네임스페이스에 복사됩니다.

2.4.5.7. CSV 복사본

OLM은 해당 Operator group의 각 대상 네임스페이스에서 Operator group의 모든 활성 멤버에 대한 CSV 복사본을 생성합니다. CSV 복사본의 용도는 대상 네임스페이스의 사용자에게 특정 Operator가 그곳에서 생성된 리소스를 조사하도록 구성됨을 알리는 것입니다.

CSV 복사본은 상태 이유가 Copied이고 해당 소스 CSV의 상태와 일치하도록 업데이트됩니다. olm.targetNamespaces 주석은 해당 주석이 클러스터에서 생성되기 전에 CSV 복사본에서 제거됩니다. 대상 네임스페이스 선택 단계를 생략하면 테넌트 간 대상 네임스페이스가 중복되지 않습니다.

CSV 복사본은 복사본의 소스 CSV가 더 이상 존재하지 않거나 소스 CSV가 속한 Operator group이 더 이상 CSV 복사본의 네임스페이스를 대상으로 하지 않는 경우 삭제됩니다.

참고

기본적으로 disableCopiedCSVs 필드는 비활성화되어 있습니다. disableCopiedCSVs 필드를 활성화하면 OLM에서 클러스터에서 기존 복사된 CSV를 삭제합니다. disableCopiedCSVs 필드가 비활성화되면 OLM에서 복사된 CSV를 다시 추가합니다.

  • disableCopiedCSVs 필드를 비활성화합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OLMConfig
    metadata:
      name: cluster
    spec:
      features:
        disableCopiedCSVs: false
    EOF
  • disableCopiedCSVs 필드를 활성화합니다.

    $ cat << EOF | oc apply -f -
    apiVersion: operators.coreos.com/v1
    kind: OLMConfig
    metadata:
      name: cluster
    spec:
      features:
        disableCopiedCSVs: true
    EOF

2.4.5.8. 정적 Operator groups

spec.staticProvidedAPIs 필드가 true로 설정된 경우 Operator group은 static입니다. 결과적으로 OLM은 Operator group의 olm.providedAPIs 주석을 수정하지 않으므로 사전에 설정할 수 있습니다. 이는 사용자가 Operator group을 사용하여 일련의 네임스페이스에서 리소스 경합을 방지하려고 하지만 해당 리소스에 대한 API를 제공하는 활성 멤버 CSV가 없는 경우 유용합니다.

다음은 something.cool.io/cluster-monitoring: "true" 주석을 사용하여 모든 네임스페이스에서 Prometheus 리소스를 보호하는 Operator group의 예입니다.

apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: cluster-monitoring
  namespace: cluster-monitoring
  annotations:
    olm.providedAPIs: Alertmanager.v1.monitoring.coreos.com,Prometheus.v1.monitoring.coreos.com,PrometheusRule.v1.monitoring.coreos.com,ServiceMonitor.v1.monitoring.coreos.com
spec:
  staticProvidedAPIs: true
  selector:
    matchLabels:
      something.cool.io/cluster-monitoring: "true"

2.4.5.9. Operator group 교집합

대상 네임스페이스 세트의 교집합이 빈 세트가 아니고 olm.providedAPIs 주석으로 정의되어 제공된 API 세트의 교집합이 빈 세트가 아닌 경우 두 Operator groups을 교차 제공 API가 있다고 합니다.

잠재적인 문제는 교차 제공 API가 있는 Operator groups이 교차 네임스페이스 세트에서 동일한 리소스에 대해 경쟁할 수 있다는 점입니다.

참고

교집합 규칙을 확인할 때는 Operator group 네임스페이스가 항상 선택한 대상 네임스페이스의 일부로 포함됩니다.

교집합 규칙

활성 멤버 CSV가 동기화될 때마다 OLM은 CSV의 Operator group 및 기타 모든 그룹 간에 교차 제공되는 API 세트에 대한 클러스터를 쿼리합니다. 그런 다음 OLM은 해당 세트가 빈 세트인지 확인합니다.

  • true 및 CSV 제공 API가 Operator group의 서브 세트인 경우:

    • 계속 전환합니다.
  • true 및 CSV 제공 API가 Operator group의 서브 세트가 아닌 경우:

    • Operator group이 정적이면 다음을 수행합니다.

      • CSV에 속하는 배포를 정리합니다.
      • 상태 이유 CannotModifyStaticOperatorGroupProvidedAPIs와 함께 CSV를 실패 상태로 전환합니다.
    • Operator group이 정적이 아니면 다음을 수행합니다.

      • Operator group의 olm.providedAPIs 주석을 주석 자체와 CSV 제공 API를 결합한 내용으로 교체합니다.
  • false 및 CSV 제공 API가 Operator group의 서브 세트가 아닌 경우:

    • CSV에 속하는 배포를 정리합니다.
    • 상태 이유 InterOperatorGroupOwnerConflict와 함께 CSV를 실패 상태로 전환합니다.
  • false 및 CSV 제공 API가 Operator group의 서브 세트인 경우:

    • Operator group이 정적이면 다음을 수행합니다.

      • CSV에 속하는 배포를 정리합니다.
      • 상태 이유 CannotModifyStaticOperatorGroupProvidedAPIs와 함께 CSV를 실패 상태로 전환합니다.
    • Operator group이 정적이 아니면 다음을 수행합니다.

      • Operator group의 olm.providedAPIs 주석을 주석 자체와 CSV 제공 API 간의 차이로 교체합니다.
참고

Operator group으로 인한 실패 상태는 터미널이 아닙니다.

Operator group이 동기화될 때마다 다음 작업이 수행됩니다.

  • 활성 멤버 CSV에서 제공되는 API 세트는 클러스터에서 계산됩니다. CSV 복사본은 무시됩니다.
  • 클러스터 세트는 olm.providedAPIs와 비교되며 olm.providedAPIs에 추가 API가 포함된 경우 해당 API가 정리됩니다.
  • 모든 네임스페이스에서 동일한 API를 제공하는 모든 CSV가 다시 큐에 추가됩니다. 그러면 충돌하는 CSV의 크기 조정 또는 삭제를 통해 충돌이 해결되었을 수 있음을 교차 group의 충돌하는 CSV에 알립니다.

2.4.5.10. 다중 테넌트 Operator 관리에 대한 제한 사항

OpenShift Dedicated는 동일한 클러스터에 다른 버전의 Operator를 동시에 설치할 수 있도록 제한된 지원을 제공합니다. OLM(Operator Lifecycle Manager)은 다른 네임스페이스에 Operator를 여러 번 설치합니다. 이에 대한 한 가지 제한 사항은 Operator의 API 버전이 동일해야 한다는 것입니다.

Operator는 Kubernetes의 글로벌 리소스인 CRD( CustomResourceDefinition 오브젝트)를 사용하므로 컨트롤 플레인 확장입니다. Operator의 다른 주요 버전에는 종종 호환되지 않는 CRD가 있습니다. 이로 인해 클러스터의 다른 네임스페이스에 동시에 설치할 수 없습니다.

모든 테넌트 또는 네임스페이스는 클러스터의 동일한 컨트롤 플레인을 공유합니다. 따라서 다중 테넌트 클러스터의 테넌트는 글로벌 CRD도 공유하므로 동일한 클러스터에서 동일한 Operator의 다른 인스턴스를 병렬로 사용할 수 있는 시나리오를 제한합니다.

지원되는 시나리오에는 다음이 포함됩니다.

  • 정확히 동일한 CRD 정의를 제공하는 다양한 버전의 Operator(버전이 지정된 CRD인 경우 정확히 동일한 버전)
  • CRD를 제공하지 않는 다른 버전의 Operator는 대신 OperatorHub의 개별 번들에서 CRD를 사용할 수 있습니다.

동일한 클러스터에서 조정할 다른 Operator 버전에서 여러 개의 경쟁 또는 중복 CRD가 있는 경우 클러스터 데이터의 무결성을 보장할 수 없기 때문에 다른 시나리오는 지원되지 않습니다.

2.4.5.11. Operator groups 문제 해결

멤버십
  • 설치 계획의 네임스페이스에는 하나의 Operator 그룹만 포함되어야 합니다. 네임스페이스에서 CSV(클러스터 서비스 버전)를 생성하려고 할 때 설치 계획은 다음 시나리오에서 Operator 그룹이 유효하지 않은 것으로 간주합니다.

    • 설치 계획의 네임스페이스에 Operator 그룹이 없습니다.
    • 설치 계획의 네임스페이스에 여러 Operator 그룹이 있습니다.
    • Operator 그룹에 잘못된 서비스 계정 이름이 지정되어 있습니다.

    설치 계획이 유효하지 않은 Operator group이 발생하면 CSV가 생성되지 않고 InstallPlan 리소스가 관련 메시지와 함께 계속 설치됩니다. 예를 들어 동일한 네임스페이스에 둘 이상의 Operator 그룹이 있는 경우 다음 메시지가 제공됩니다.

    attenuated service account query failed - more than one operator group(s) are managing this namespace count=2

    여기서 count= 은 네임스페이스에서 Operator 그룹 수를 지정합니다.

  • CSV의 설치 모드가 해당 네임스페이스에서 Operator group의 대상 네임스페이스 선택을 지원하지 않는 경우 CSV는 UnsupportedOperatorGroup 이유와 함께 실패 상태로 전환됩니다. 이러한 이유로 실패 상태에 있는 CSV는 Operator group의 대상 네임스페이스 선택이 지원되는 구성으로 변경된 후 보류 중으로 전환되거나 대상 네임스페이스 선택을 지원하도록 CSV의 설치 모드가 수정됩니다.

2.4.6. 멀티 테넌시 및 Operator 공동 배치

이 가이드에서는 OLM(Operator Lifecycle Manager)의 멀티 테넌시 및 Operator 공동 배치에 대해 간단히 설명합니다.

2.4.6.1. 네임스페이스에 Operator 공동 배치

OLM(Operator Lifecycle Manager)은 동일한 네임스페이스에 설치된 OLM 관리 Operator를 처리합니다. 즉, 서브스크립션 리소스가 관련 Operator와 동일한 네임스페이스에 배치됩니다. 실제로 관련이 없는 경우에도 OLM은 해당 버전 및 업데이트 정책 중 하나가 업데이트될 때 해당 상태를 고려합니다.

이 기본 동작은 다음 두 가지 방법으로 발생합니다.

  • 보류 중인 업데이트의 InstallPlan 리소스에는 동일한 네임스페이스에 있는 다른 모든 Operator의 CSV( ClusterServiceVersion ) 리소스가 포함됩니다.
  • 동일한 네임스페이스의 모든 Operator는 동일한 업데이트 정책을 공유합니다. 예를 들어 하나의 Operator가 수동 업데이트로 설정된 경우 다른 모든 Operator 업데이트 정책도 manual로 설정됩니다.

이러한 시나리오에서는 다음과 같은 문제가 발생할 수 있습니다.

  • 업데이트된 Operator보다 더 많은 리소스가 정의되기 때문에 Operator 업데이트에 대한 설치 계획에 대한 이유하기가 어렵습니다.
  • 클러스터 관리자의 일반적인 요구 사항은 다른 Operator를 수동으로 업데이트하는 동안 네임스페이스에 일부 Operator를 자동으로 업데이트할 수 없습니다.

이러한 문제는 OpenShift Dedicated 웹 콘솔을 사용하여 Operator를 설치할 때 모든 네임스페이스 설치 모드를 지원하는 Operator를 기본 openshift-operators 글로벌 네임스페이스에 설치하기 때문에 일반적으로 발생합니다.

dedicated-admin 역할의 관리자는 다음 워크플로를 사용하여 이 기본 동작을 수동으로 무시할 수 있습니다.

  1. Operator 설치를 위한 프로젝트를 생성합니다.
  2. 모든 네임스페이스를 감시하는 Operator group인 사용자 정의 글로벌 Operator group을 생성합니다. 이 Operator group을 방금 생성한 네임스페이스와 연결하면 설치 네임스페이스가 글로벌 네임스페이스로 만들어 모든 네임스페이스에 Operator를 설치할 수 있습니다.
  3. 설치 네임스페이스에 원하는 Operator를 설치합니다.

Operator에 종속 항목이 있는 경우 사전 생성된 네임스페이스에 종속 항목이 자동으로 설치됩니다. 결과적으로 종속성 Operator에 동일한 업데이트 정책 및 공유 설치 계획이 있는 것이 유효합니다. 자세한 절차는 "사용자 정의 네임스페이스에 글로벌 Operator 설치"를 참조하십시오.

2.4.7. Operator 상태

이 가이드에서는 OLM(Operator Lifecycle Manager)에서 Operator 조건을 사용하는 방법을 간단히 설명합니다.

2.4.7.1. Operator 조건 정보

OLM(Operator Lifecycle Manager)에서는 Operator의 라이프사이클을 관리하는 역할의 일부로, Operator를 정의하는 Kubernetes 리소스의 상태에서 Operator의 상태를 유추합니다. 이 접근 방식에서는 Operator가 지정된 상태에 있도록 어느 정도는 보장하지만 Operator에서 다른 방법으로는 유추할 수 없는 정보를 OLM에 보고해야 하는 경우가 많습니다. 그러면 OLM에서 이러한 정보를 사용하여 Operator의 라이프사이클을 더 효과적으로 관리할 수 있습니다.

OLM에서는 Operator에서 OLM에 조건을 보고할 수 있는 OperatorCondition이라는 CRD(사용자 정의 리소스 정의)를 제공합니다. OperatorCondition 리소스의 Spec.Conditions 어레이에 있는 경우 OLM의 Operator 관리에 영향을 줄 수 있는 일련의 조건이 지원됩니다.

참고

기본적으로 Spec.Conditions 어레이는 사용자가 추가하거나 사용자 정의 Operator 논리의 결과로 OperatorCondition 오브젝트에 존재하지 않습니다.

2.4.7.2. 지원되는 조건

OLM(Operator Lifecycle Manager)에서는 다음과 같은 Operator 조건을 지원합니다.

2.4.7.2.1. 업그레이드 가능한 조건

Upgradeable Operator 조건을 사용하면 기존 CSV(클러스터 서비스 버전)가 최신 버전의 CSV로 교체되지 않습니다. 이 조건은 다음과 같은 경우 유용합니다.

  • Operator에서 중요한 프로세스를 시작할 예정이며 프로세스가 완료될 때까지 업그레이드해서는 안 됩니다.
  • Operator에서 Operator를 업그레이드하기 위해 준비하기 전에 완료해야 하는 CR(사용자 정의 리소스) 마이그레이션을 수행하고 있습니다.
중요

Upgradeable Operator 조건을 False 값으로 설정하면 Pod가 중단되지 않습니다. Pod가 중단되지 않도록 해야 하는 경우 "Pod 중단 예산을 사용하여 가동해야 하는 Pod 수" 및 "추가 리소스" 섹션의 "Graceful termination"를 참조하십시오.

Upgradeable Operator 조건의 예

apiVersion: operators.coreos.com/v1
kind: OperatorCondition
metadata:
  name: my-operator
  namespace: operators
spec:
  conditions:
  - type: Upgradeable 1
    status: "False" 2
    reason: "migration"
    message: "The Operator is performing a migration."
    lastTransitionTime: "2020-08-24T23:15:55Z"

1
조건의 이름입니다.
2
False 값은 Operator를 업그레이드할 준비가 되지 않았음을 나타냅니다. OLM에서는 Operator의 기존 CSV를 대체하는 CSV가 Pending 상태가 되지 않도록 합니다. False 값은 클러스터 업그레이드를 차단하지 않습니다.

2.4.7.3. 추가 리소스

2.4.8. Operator Lifecycle Manager 지표

2.4.8.1. 표시되는 지표

OLM(Operator Lifecycle Manager)은 Prometheus 기반 OpenShift Dedicated 클러스터 모니터링 스택에서 사용할 특정 OLM 관련 리소스를 표시합니다.

표 2.8. OLM에서 표시하는 지표
이름설명

catalog_source_count

카탈로그 소스 수입니다.

catalogsource_ready

카탈로그 소스의 상태. 값 1 은 카탈로그 소스가 READY 상태에 있음을 나타냅니다. 값 0 은 카탈로그 소스가 READY 상태가 아님을 나타냅니다.

csv_abnormal

CSV(클러스터 서비스 버전)를 조정할 때 CSV 버전이 Succeeded 이외의 상태가 될 때마다(예: 설치되지 않은 경우) 표시됩니다. name, namespace, phase, reason, version 라벨이 포함됩니다. 이 지표가 표시되면 Prometheus 경고가 생성됩니다.

csv_count

성공적으로 등록된 CSV 수입니다.

csv_succeeded

CSV를 재조정할 때 CSV 버전이 Succeeded 상태(값 1)인지 아닌지(값 0)를 나타냅니다. name, namespace, version 라벨이 포함됩니다.

csv_upgrade_count

CSV 업그레이드의 단조 수입니다.

install_plan_count

설치 계획 수입니다.

installplan_warnings_total

설치 계획에 포함된 더 이상 사용되지 않는 리소스와 같이 리소스에서 생성한 경고의 단조 수입니다.

olm_resolution_duration_seconds

종속성 확인 시도의 기간입니다.

subscription_count

서브스크립션 수입니다.

subscription_sync_total

서브스크립션 동기화의 단조 수입니다. channel, installed CSV, 서브스크립션 name 라벨이 포함됩니다.

2.4.9. Operator Lifecycle Manager의 Webhook 관리

Operator 작성자는 Webhook를 통해 리소스를 오브젝트 저장소에 저장하고 Operator 컨트롤러에서 이를 처리하기 전에 리소스를 가로채기, 수정, 수락 또는 거부할 수 있습니다. Operator와 함께 webhook 가 제공 될 때 OLM (Operator Lifecycle Manager)은 이러한 Webhook의 라이프 사이클을 관리할 수 있습니다.

Operator 개발자가 Operator에 대한 Webhook를 정의하는 방법과 OLM에서 실행할 때의 고려 사항은 CSV(클러스터 서비스 버전) 정의를 참조하십시오.

2.4.9.1. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.