2.4. OLM(Operator Lifecycle Manager)
2.4.1. Operator Lifecycle Manager 개념 및 리소스
이 가이드에서는 OpenShift Container Platform에서 OLM(Operator Lifecycle Manager)을 구동하는 개념에 대한 개요를 제공합니다.
2.4.1.1. Operator Lifecycle Manager란?
OLM(Operator Lifecycle Manager)은 OpenShift Container Platform 클러스터에서 실행되는 Kubernetes 네이티브 애플리케이션(Operator) 및 관련 서비스의 라이프사이클을 설치, 업데이트, 관리하는 데 도움이 됩니다. Operator 프레임워크의 일부로, 효과적이고 자동화되었으며 확장 가능한 방식으로 Operator를 관리하도록 설계된 오픈 소스 툴킷입니다.
그림 2.2. Operator Lifecycle Manager 워크플로
![olm 워크플로](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Operators-ko-KR/images/c8a00bac5df42a702ff1b826333610d0/olm-workflow.png)
OLM은 OpenShift Container Platform 4.11에서 기본적으로 실행되므로 클러스터 관리자가 클러스터에서 실행되는 Operator를 설치, 업그레이드 및 액세스할 수 있도록 지원합니다. OpenShift Container Platform 웹 콘솔은 클러스터 관리자가 Operator를 설치할 수 있는 관리 화면을 제공하고, 클러스터에 제공되는 Operator 카탈로그를 사용할 수 있는 액세스 권한을 특정 프로젝트에 부여합니다.
개발자의 경우 분야별 전문가가 아니어도 셀프서비스 경험을 통해 데이터베이스, 모니터링, 빅 데이터 서비스의 인스턴스를 프로비저닝하고 구성할 수 있습니다. Operator에서 해당 지식을 제공하기 때문입니다.
2.4.1.2. OLM 리소스
다음 CRD(사용자 정의 리소스 정의)는 OLM(Operator Lifecycle Manager)에서 정의하고 관리합니다.
리소스 | 짧은 이름 | 설명 |
---|---|---|
|
| 애플리케이션 메타데이터입니다. 예를 들면 이름, 버전, 아이콘, 필수 리소스입니다. |
|
| 애플리케이션을 정의하는 CSV, CRD, 패키지의 리포지토리입니다. |
|
| 패키지의 채널을 추적하여 CSV를 최신 상태로 유지합니다. |
|
| CSV를 자동으로 설치하거나 업그레이드하기 위해 생성하는 계산된 리소스 목록입니다. |
|
|
동일한 네임스페이스에 배포된 모든 Operator를 |
| - |
OLM과 OLM에서 관리하는 Operator 간 통신 채널을 생성합니다. Operator는 복잡한 상태를 OLM에 보고하기 위해 |
2.4.1.2.1. 클러스터 서비스 버전
CSV(클러스터 서비스 버전)는 OpenShift Container Platform 클러스터에서 실행 중인 특정 버전의 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 Container Platform 웹 콘솔의 OperatorHub에는 카탈로그 소스에서 제공하는 Operator도 표시됩니다.
클러스터 관리자는 웹 콘솔의 관리
CatalogSource
오브젝트의 spec
은 Pod를 구성하는 방법 또는 Operator Registry gRPC API를 제공하는 서비스와 통신하는 방법을 나타냅니다.
예 2.8. 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: nodeSelector: 8 custom_label: <label> priorityClassName: system-cluster-critical 9 tolerations: 10 - key: "key1" operator: "Equal" value: "value1" effect: "NoSchedule" updateStrategy: registryPoll: 11 interval: 30m0s status: connectionState: address: example-catalog.openshift-marketplace.svc:50051 lastConnect: 2021-08-26T18:14:31Z lastObservedState: READY 12 latestImageRegistryPoll: 2021-08-26T18:46:25Z 13 registryService: 14 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
- 선택 사항:
grpc
유형 카탈로그 소스의 경우, 정의된 경우spec.image
의 콘텐츠를 제공하는 Pod의 기본 노드 선택기를 덮어씁니다. - 9
- 선택 사항:
grpc
유형 카탈로그 소스의 경우, 정의된 경우spec.image
의 콘텐츠를 제공하는 Pod의 기본 우선 순위 클래스 이름을 덮어씁니다. Kubernetes는 기본적으로system-cluster-critical
및system-node-critical
우선순위 클래스를 제공합니다. 필드를 빈(""
)으로 설정하면 Pod에 기본 우선순위가 할당됩니다. 기타 우선순위 클래스는 수동으로 정의할 수 있습니다. - 10
- 선택 사항:
grpc
유형 카탈로그 소스의 경우 정의된 경우spec.image
의 콘텐츠를 제공하는 Pod의 기본 허용 오차를 덮어씁니다. - 11
- 지정된 간격으로 새 버전을 자동으로 확인하여 최신 상태를 유지합니다.
- 12
- 카탈로그 연결의 마지막으로 관찰된 상태입니다. 예를 들어 다음과 같습니다.
-
READY
: 성공적으로 연결되었습니다. -
CONNECTING
: 계속 연결을 시도합니다. -
TRANSIENT_FAILURE
: 연결을 시도하는 동안 시간 초과와 같은 일시적인 문제가 발생했습니다. 상태는 결국CONNECTING
으로 다시 전환되고 다시 연결 시도합니다.
자세한 내용은 gRPC 문서의 연결 상태를 참조하십시오.
-
- 13
- 카탈로그 이미지를 저장하는 컨테이너 레지스트리가 폴링되어 이미지가 최신 상태인지 확인할 수 있는 마지막 시간입니다.
- 14
- 카탈로그의 Operator 레지스트리 서비스의 상태 정보입니다.
서브스크립션의 CatalogSource
오브젝트 name
을 참조하면 요청된 Operator를 찾기 위해 검색할 위치를 OLM에 지시합니다.
예 2.9. 카탈로그 소스를 참조하는 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 Container Platform 4.11).
클러스터 업그레이드 중에 기본 Red Hat 제공 카탈로그 소스의 인덱스 이미지 태그는 CVO(Cluster Version Operator)에서 자동으로 업데이트하여 OLM(Operator Lifecycle Manager)이 업데이트된 버전의 카탈로그를 가져옵니다. 예를 들어 OpenShift Container Platform 4.10에서 4.11로 업그레이드하는 동안 redhat-operators
카탈로그의 CatalogSource
오브젝트의 spec.image
필드가 다음과 같이 업데이트됩니다.
registry.redhat.io/redhat/redhat-operator-index:v4.10
다음으로 변경합니다.
registry.redhat.io/redhat/redhat-operator-index:v4.11
그러나 CVO는 사용자 정의 카탈로그의 이미지 태그를 자동으로 업데이트하지 않습니다. 클러스터 업그레이드 후 사용자가 호환 가능하고 지원되는 Operator 설치를 유지하려면 업데이트된 인덱스 이미지를 참조하도록 사용자 정의 카탈로그도 업데이트해야 합니다.
OpenShift Container Platform 4.9부터 클러스터 관리자는 사용자 정의 카탈로그의 CatalogSource
오브젝트에 olm.catalogImageTemplate
주석을 템플릿이 포함된 이미지 참조에 추가할 수 있습니다. 템플릿에서 사용할 수 있도록 지원되는 Kubernetes 버전 변수는 다음과 같습니다.
-
kube_major_version
-
kube_minor_version
-
kube_patch_version
현재 템플릿에 사용할 수 없으므로 OpenShift Container Platform 클러스터 버전이 아닌 Kubernetes 클러스터 버전을 지정해야 합니다.
업데이트된 Kubernetes 버전을 지정하는 태그로 인덱스 이미지를 생성하고 푸시한 경우 이 주석을 설정하면 사용자 정의 카탈로그의 인덱스 이미지 버전이 클러스터 업그레이드 후 자동으로 변경될 수 있습니다. 주석 값은 CatalogSource
오브젝트의 spec.image
필드에서 이미지 참조를 설정하거나 업데이트하는 데 사용됩니다. 이로 인해 Operator가 지원되지 않는 상태이거나 지속적인 업데이트 경로가 없는 클러스터 업그레이드가 방지됩니다.
업데이트된 태그가 있는 인덱스 이미지에 저장되어 있는 레지스트리가 클러스터 업그레이드 시 클러스터에서 액세스할 수 있는지 확인해야 합니다.
예 2.10. 이미지 템플릿이 있는 카탈로그 소스의 예
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.24 priority: -400 publisher: Example Org
spec.image
필드와 olm.catalogImageTemplate
주석이 둘 다 설정된 경우 주석의 확인된 값으로 spec.image
필드를 덮어씁니다. 주석이 사용 가능한 풀 사양으로 확인되지 않으면 카탈로그 소스는 설정된 spec.image
값으로 대체됩니다.
spec.image
필드가 설정되지 않고 주석이 사용 가능한 풀 사양으로 확인되지 않으면 OLM에서 카탈로그 소스의 조정을 중지하고 사람이 읽을 수 있는 오류 조건으로 설정합니다.
이전 예제의 olm.catalogImageTemplate
주석은 Kubernetes 1.24를 사용하는 OpenShift Container Platform 4.11 클러스터의 경우 다음 이미지 참조로 확인됩니다.
quay.io/example-org/example-catalog:v1.24
향후 OpenShift Container Platform 릴리스에서는 이후 OpenShift Container Platform 버전에서 사용하는 이후 Kubernetes 버전을 대상으로 하는 사용자 정의 카탈로그의 업데이트된 인덱스 이미지를 생성할 수 있습니다. 업그레이드 전에 olm.catalogImageTemplate
주석을 설정하여 클러스터를 이후 OpenShift Container Platform 버전으로 업그레이드하면 카탈로그의 인덱스 이미지도 자동으로 업데이트됩니다.
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 Container Platform 웹 콘솔에서 쉽게 확인할 수 있을 뿐만 아니라 관련 서브스크립션의 상태를 검사하여 사용 가능한 최신 버전의 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.11. 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 Container Platform의 OLM(Operator Lifecycle Manager) 구성 요소 아키텍처를 간략하게 설명합니다.
2.4.2.1. 구성 요소의 역할
OLM(Operator Lifecycle Manager)은 OLM Operator와 Catalog Operator의 두 Operator로 구성됩니다.
각 Operator는 OLM 프레임워크의 기반이 되는 CRD(사용자 정의 리소스 정의)를 관리합니다.
리소스 | 짧은 이름 | 소유자 | Description |
---|---|---|---|
|
| OLM | 애플리케이션 메타데이터: 이름, 버전, 아이콘, 필수 리소스, 설치 등입니다. |
|
| 카탈로그 | CSV를 자동으로 설치하거나 업그레이드하기 위해 생성하는 계산된 리소스 목록입니다. |
|
| 카탈로그 | 애플리케이션을 정의하는 CSV, CRD, 패키지의 리포지토리입니다. |
|
| 카탈로그 | 패키지의 채널을 추적하여 CSV를 최신 상태로 유지하는 데 사용됩니다. |
|
| OLM |
동일한 네임스페이스에 배포된 모든 Operator를 |
또한 각 Operator는 다음 리소스를 생성합니다.
리소스 | 소유자 |
---|---|
| OLM |
| |
| |
| |
CRD( | 카탈로그 |
|
2.4.2.2. OLM Operator
CSV에 지정된 필수 리소스가 클러스터에 제공되면 OLM Operator는 CSV 리소스에서 정의하는 애플리케이션을 배포합니다.
OLM Operator는 필수 리소스 생성과는 관련이 없습니다. CLI 또는 Catalog Operator를 사용하여 이러한 리소스를 수동으로 생성하도록 선택할 수 있습니다. 이와 같은 분리를 통해 사용자는 애플리케이션에 활용하기 위해 선택하는 OLM 프레임워크의 양을 점차 늘리며 구매할 수 있습니다.
OLM Operator에서는 다음 워크플로를 사용합니다.
- 네임스페이스에서 CSV(클러스터 서비스 버전)를 조사하고 해당 요구 사항이 충족되는지 확인합니다.
요구사항이 충족되면 CSV에 대한 설치 전략을 실행합니다.
참고설치 전략을 실행하기 위해서는 CSV가 Operator group의 활성 멤버여야 합니다.
2.4.2.3. Catalog Operator
Catalog Operator는 CSV(클러스터 서비스 버전) 및 CSV에서 지정하는 필수 리소스를 확인하고 설치합니다. 또한 채널에서 패키지 업데이트에 대한 카탈로그 소스를 조사하고 원하는 경우 사용 가능한 최신 버전으로 자동으로 업그레이드합니다.
채널에서 패키지를 추적하려면 원하는 패키지를 구성하는 Subscription
오브젝트, 채널, 업데이트를 가져오는 데 사용할 CatalogSource
오브젝트를 생성하면 됩니다. 업데이트가 확인되면 사용자를 대신하여 네임스페이스에 적절한 InstallPlan
오브젝트를 기록합니다.
Catalog Operator에서는 다음 워크플로를 사용합니다.
- 클러스터의 각 카탈로그 소스에 연결합니다.
사용자가 생성한 설치 계획 중 확인되지 않은 계획이 있는지 조사하고 있는 경우 다음을 수행합니다.
- 요청한 이름과 일치하는 CSV를 찾아 확인된 리소스로 추가합니다.
- 각 관리 또는 필수 CRD의 경우 CRD를 확인된 리소스로 추가합니다.
- 각 필수 CRD에 대해 이를 관리하는 CSV를 확인합니다.
- 확인된 설치 계획을 조사하고 사용자의 승인에 따라 또는 자동으로 해당 계획에 대해 검색된 리소스를 모두 생성합니다.
- 카탈로그 소스 및 서브스크립션을 조사하고 이에 따라 설치 계획을 생성합니다.
2.4.2.4. 카탈로그 레지스트리
Catalog 레지스트리는 클러스터에서 생성할 CSV 및 CRD를 저장하고 패키지 및 채널에 대한 메타데이터를 저장합니다.
패키지 매니페스트는 패키지 ID를 CSV 세트와 연결하는 카탈로그 레지스트리의 항목입니다. 패키지 내에서 채널은 특정 CSV를 가리킵니다. CSV는 교체하는 CSV를 명시적으로 참조하므로 패키지 매니페스트는 Catalog Operator에 각 중간 버전을 거쳐 CSV를 최신 버전으로 업데이트하는 데 필요한 모든 정보를 제공합니다.
2.4.3. Operator Lifecycle Manager 워크플로
이 가이드에서는 OpenShift Container Platform의 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](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Operators-ko-KR/images/a4756a206580a0a1ab0e6a170ddc75e3/olm-catalogsource.png)
Operator는 카탈로그 소스 내에서 패키지와 채널이라는 업데이트 스트림으로 구성되는데, 채널은 웹 브라우저와 같이 연속 릴리스 주기에서 OpenShift Container Platform 또는 기타 소프트웨어에 친숙한 업데이트 패턴이어야 합니다.
그림 2.4. 카탈로그 소스의 패키지 및 채널
![olm channels](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Operators-ko-KR/images/52025648e55a627b8be314426148fb97/olm-channels.png)
사용자는 서브스크립션의 특정 카탈로그 소스에서 특정 패키지 및 채널(예: etcd
패키지 및 해당 alpha
채널)을 나타냅니다. 네임스페이스에 아직 설치되지 않은 패키지에 서브스크립션이 생성되면 해당 패키지의 최신 Operator가 설치됩니다.
OLM에서는 의도적으로 버전을 비교하지 않으므로 지정된 카탈로그
각 CSV에는 교체 대상 Operator를 나타내는 replaces
매개변수가 있습니다. 이 매개변수를 통해 OLM에서 쿼리할 수 있는 CSV 그래프가 빌드되고 업데이트를 채널 간에 공유할 수 있습니다. 채널은 업데이트 그래프의 진입점으로 간주할 수 있습니다.
그림 2.5. 사용 가능한 채널 업데이트의 OLM 그래프
![OLM 대체](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Operators-ko-KR/images/6990efb545ef499e93732227bbe7df68/olm-replaces.png)
패키지에 포함된 채널의 예
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](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Operators-ko-KR/images/da1fe891cee5ba712308b9d0e08b91e0/olm-skipping-updates.png)
이 그래프에는 다음이 유지됩니다.
- 기존 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이 채널의 최신 항목으로 업데이트됩니다.
우선순위 순서는 다음과 같습니다.
-
기타 건너뛰기 기준이 충족되는 경우 서브스크립션의
sourceName
에 지정된 소스의 채널 헤드 -
sourceName
에 지정된 소스의 현재 Operator를 대체하는 다음 Operator - 기타 건너뛰기 조건이 충족되는 경우 서브스크립션에 표시되는 다른 소스의 채널 헤드.
- 서브스크립션에 표시되는 모든 소스의 현재 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 스트림](https://access.redhat.com/webassets/avalon/d/OpenShift_Container_Platform-4.11-Operators-ko-KR/images/9d8f445a920be612fe82454a3a545e70/olm-z-stream.png)
이 그래프에는 다음이 유지됩니다.
- 기존 CatalogSource에 있는 모든 Operator에는 새 CatalogSource에 단일 대체 항목이 있습니다.
- 새 CatalogSource에 있는 모든 Operator에는 새 CatalogSource에 단일 대체 항목이 있습니다.
- 이전 CatalogSource의 모든 z-stream 릴리스가 새 CatalogSource의 최신 z-stream 릴리스로 업데이트됩니다.
- 사용할 수 없는 릴리스는 "가상" 그래프 노드로 간주할 수 있습니다. 해당 콘텐츠가 존재할 필요는 없으며 그래프가 이와 같은 경우 레지스트리에서 응답하기만 하면 됩니다.
2.4.4. Operator Lifecycle Manager 종속성 확인
이 가이드에서는 OpenShift Container Platform의 OLM(Operator Lifecycle Manager)을 사용한 종속성 해결 및 CRD(사용자 정의 리소스 정의) 업그레이드 라이프사이클에 대해 간단히 설명합니다.
2.4.4.1. 종속성 확인 정보
OLM(Operator Lifecycle Manager)은 실행 중인 Operator의 종속성 확인 및 업그레이드 라이프사이클을 관리합니다. OLM에서 발생하는 문제는 여러 가지 면에서 yum
및 rpm
과 같은 다른 시스템 또는 언어 패키지 관리자와 유사합니다.
그러나 OLM에는 유사한 시스템에는 일반적으로 해당하지 않는 한 가지 제약 조건이 있습니다. 즉 Operator가 항상 실행되고 있으므로 OLM에서 서로 함께 작동하지 않는 Operator 세트를 제공하지 않도록 합니다.
결과적으로 OLM은 다음 시나리오를 생성하지 않아야 합니다.
- 제공할 수 없는 API가 필요한 Operator 세트를 설치합니다.
- Operator에 종속된 다른 Operator를 중단하는 방식으로 Operator 업데이트
이 작업은 다음 두 가지 유형의 데이터에서 수행할 수 있습니다.
속성 | 종속성 확인자에서 공용 인터페이스를 구성하는 Operator에 대한 입력한 메타데이터입니다. 예를 들어 Operator에서 제공하는 API의 GVK(그룹/버전/종류)와 Operator의 시맨틱 버전(semver)이 있습니다. |
제약 조건 또는 종속 항목 | 대상 클러스터에 이미 설치되어 있거나 설치되지 않았을 수 있는 다른 Operator에서 충족해야 하는 Operator의 요구 사항입니다. 이러한 작업은 사용 가능한 모든 Operator에 대한 쿼리 또는 필터 역할을 하며 종속성 확인 및 설치 중에 선택을 제한합니다. 예를 들어 클러스터에서 특정 API를 사용할 수 있거나 특정 버전이 있는 특정 Operator를 설치해야 하는 경우가 있습니다. |
OLM은 이러한 속성과 제약 조건을 부울 공식 시스템으로 변환하고 이를 SAT solver(SAT solver)로 전달합니다. 이 프로그램은 Operator를 설치해야 하는 부울 사격성을 설정하는 프로그램입니다.
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
속성은constraint가 아닌 속성을 구분하여 특정 유형의 종속성 제약 조건을 선언합니다. 해당 value
필드는 제약 조건 메시지를 나타내는 failureMessage
필드가 포함된 오브젝트입니다. 이 메시지는 런타임에 제약 조건이 만족되지 않은 경우 사용자에게 유용한 설명으로 표시됩니다.
다음 키는 사용 가능한 제약 조건 유형을 나타냅니다.
gvk
-
값 및 해석이
olm.gvk
유형과 동일한 유형을 입력합니다. 패키지
-
값 및 해석이
olm.package
유형과 동일한 유형을 입력합니다. cel
- 런타임 시 임의의 번들 속성 및 클러스터 정보에 대해 OLM(Operator Lifecycle Manager)에서 평가한 CEL(Common Expression Language) 표현식
모든
,어떤
,아니
-
gvk
또는 중첩된 복합 제약 조건과 같은 하나 이상의 구체적인 제약 조건을 포함하는 결합, 분리 및 부정 제약 조건
2.4.4.4.1. CEL(Common Expression Language) 제약 조건
Cel 제약
조건 유형은 표현식 언어로 CEL(Common Expression Language) 을 지원합니다. cel
struct에는 런타임 시 Operator 속성에 대해 평가되는 CEL 표현식 문자열이 포함된 rule
필드가 있어 Operator가 제약 조건을 충족하는지 확인합니다.
cel
제약 조건의 예
type: olm.constraint value: failureMessage: 'require to have "certified"' cel: rule: 'properties.exists(p, p.type == "certified")'
CEL 구문은 AND
및 또는
와 같은 광범위한 논리 연산자를 지원합니다. 결과적으로 단일 CEL 식에는 이러한 논리 연산자가 함께 연결된 여러 조건에 대해 여러 규칙이 있을 수 있습니다. 이러한 규칙은 번들 또는 지정된 소스의 여러 속성 데이터 집합에 대해 평가되며 출력은 단일 제약 조건 내에서 해당 규칙을 모두 충족하는 단일 번들 또는 Operator로 해결됩니다.
여러 규칙이 있는
컬 제약 조건의 예
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. 혼합 제약 조건 (모두, any, not)
복합 제약 조건 유형은 논리 정의에 따라 평가됩니다.
다음은 두 패키지와 하나의 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의 세 가지 버전의 분산 제약 조건의 예입니다. 즉, 설치된 번들로 최소 1개 이상 충족되어야 합니다.
제약 조건의 예
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 버전에 대한 부정 제약 조건의 예입니다. 즉, 결과 집합의 번들에서 이 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, 버전 패키지를 포함하는 가능한 모든 솔루션을 제거하도록 지시하거나 결과 집합에서 일부 하위 복합 제약 조건을 충족하도록 지시합니다.
강제적으로는 가능한 종속 항목 집합을 선택하지 않고 부정할 수 있으므로 모든
또는 제약 조건 내에서만 사용할 수 있어야 합니다.
2.4.4.4.3. 중첩된 복합 제약 조건
하나 이상의 간단한 제약 조건과 함께 하나 이상의 자식 복합 제약 조건을 포함하는 중첩된 복합 제약 조건은 이전에 설명한 각 제약 조건 유형에 대한 프로시저에 따라 아래쪽에서 평가됩니다.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 following 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 Container Platform 클러스터에서 OLM은 카탈로그 소스를 읽고 설치에 사용할 수 있는 Operator를 확인합니다.
CatalogSource
오브젝트의 예
apiVersion: "operators.coreos.com/v1alpha1" kind: "CatalogSource" metadata: name: "my-operators" namespace: "operators" spec: sourceType: grpc image: example.com/my/operator-index:v1 displayName: "My Operators" priority: 100
CatalogSource
오브젝트에는 priority
필드가 있으며 확인자는 이 필드를 통해 종속성에 대한 옵션의 우선순위를 부여하는 방법을 확인합니다.
카탈로그 기본 설정을 관리하는 규칙에는 다음 두 가지가 있습니다.
- 우선순위가 높은 카탈로그의 옵션이 우선순위가 낮은 카탈로그의 옵션보다 우선합니다.
- 종속 항목과 동일한 카탈로그의 옵션이 다른 카탈로그보다 우선합니다.
2.4.4.5.2. 채널 순서
카탈로그의 Operator 패키지는 사용자가 OpenShift Container Platform 클러스터에서 구독할 수 있는 업데이트 채널 컬렉션입니다. 채널은 마이너 릴리스(1.2
, 1.3
) 또는 릴리스 빈도(stable
, fast
)에 대해 특정 업데이트 스트림을 제공하는 데 사용할 수 있습니다.
동일한 패키지에 있지만 채널이 다른 Operator로 종속성을 충족할 수 있습니다. 예를 들어 버전 1.2
의 Operator는 stable
및 fast
채널 모두에 존재할 수 있습니다.
각 패키지에는 기본이 채널이 있으며 항상 기본이 아닌 채널에 우선합니다. 기본 채널의 옵션으로 종속성을 충족할 수 없는 경우 남아 있는 채널의 옵션을 채널 이름의 사전 순으로 고려합니다.
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.newfield
를MyObject
에 추가하지만 여전히 v1alpha1입니다.
Operator에
spec.newfield
를MyObject
리소스에 쓰는 기능이 필요할 수 있습니다.olm.gvk
제약 조건만으로는 OLM에서 TestOperator v1.0.0이 아닌 TestOperator v1.0.1이 필요한 것으로 판단하는 데 충분하지 않습니다.가능한 경우 API를 제공하는 특정 Operator를 미리 알고 있는 경우 추가
olm.package
제약 조건을 지정하여 최솟값을 설정합니다.-
TestOperator v1.0.0에서는 v1alpha1 API 버전의
- 최대 버전 생략 또는 광범위한 범위 허용
Operator는 API 서비스 및 CRD와 같은 클러스터 범위의 리소스를 제공하기 때문에 짧은 종속성 기간을 지정하는 Operator는 해당 종속성의 다른 소비자에 대한 업데이트를 불필요하게 제한할 수 있습니다.
가능한 경우 최대 버전을 설정하지 마십시오. 또는 다른 Operator와 충돌하지 않도록 매우 광범위한 의미 범위를 설정하십시오. 예를 들면
>1.0.0 <2.0.0
과 같습니다.기존 패키지 관리자와 달리 Operator 작성자는 OLM의 채널을 통해 업데이트가 안전함을 명시적으로 인코딩합니다. 기존 서브스크립션에 대한 업데이트가 제공되면 Operator 작성자가 이전 버전에서 업데이트할 수 있음을 나타내는 것으로 간주합니다. 종속성에 최대 버전을 설정하면 특정 상한에서 불필요하게 잘라 작성자의 업데이트 스트림을 덮어씁니다.
참고클러스터 관리자는 Operator 작성자가 설정한 종속 항목을 덮어쓸 수 없습니다.
그러나 피해야 하는 알려진 비호환성이 있는 경우 최대 버전을 설정할 수 있으며 설정해야 합니다. 버전 범위 구문을 사용하여 특정 버전을 생략할 수 있습니다(예:
> 1.0.0 !1.2.1
).
추가 리소스
- Kubernetes 설명서: API 변경
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 Container Platform의 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
로 구성된 설치 모드 세트가 포함될 수 있습니다.
InstallModeType | 설명 |
---|---|
| Operator가 자체 네임스페이스를 선택하는 Operator group의 멤버일 수 있습니다. |
| Operator가 하나의 네임스페이스를 선택하는 Operator group의 멤버일 수 있습니다. |
| Operator가 네임스페이스를 두 개 이상 선택하는 Operator group의 멤버일 수 있습니다. |
|
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
OLM(Operator Lifecycle Manager)은 각 Operator 그룹에 대해 다음 클러스터 역할을 생성합니다.
-
<operatorgroup_name>-admin
-
<operatorgroup_name>-edit
-
<operatorgroup_name>-view
Operator group을 수동으로 생성할 때 클러스터의 기존 클러스터 역할 또는 기타 Operator 그룹과 충돌하지 않는 고유한 이름을 지정해야 합니다.
또는 라벨 선택기를 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.targetNamespaces
및 spec.selector
를 둘 다 정의하면 spec.selector
가 무시됩니다. 또는 모든 네임스페이스를 선택하는 global Operator group을 지정하려면 spec.selector
및 spec.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에는 다음과 같은 주석이 있습니다.
주석 | 설명 |
---|---|
| Operator group의 이름을 포함합니다. |
| Operator group의 네임스페이스를 포함합니다. |
| 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(Operator Lifecycle Manager)은 각 Operator 그룹에 대해 다음 클러스터 역할을 생성합니다.
-
<operatorgroup_name>-admin
-
<operatorgroup_name>-edit
-
<operatorgroup_name>-view
Operator group을 수동으로 생성할 때 클러스터의 기존 클러스터 역할 또는 기타 Operator 그룹과 충돌하지 않는 고유한 이름을 지정해야 합니다.
다음 RBAC 리소스는 CSV가 AllNamespaces
설치 모드로 모든 네임스페이스를 조사하고 이유가 InterOperatorGroupOwnerConflict
인 실패 상태가 아닌 한 CSV가 Operator group의 활성 멤버가 될 때 생성됩니다.
- CRD의 각 API 리소스에 대한 클러스터 역할
- API 서비스의 각 API 리소스에 대한 클러스터 역할
- 추가 역할 및 역할 바인딩
클러스터 역할 | 설정 |
---|---|
|
집계 라벨:
|
|
집계 라벨:
|
|
집계 라벨:
|
|
집계 라벨:
|
클러스터 역할 | 설정 |
---|---|
|
집계 라벨:
|
|
집계 라벨:
|
|
집계 라벨:
|
추가 역할 및 역할 바인딩
-
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"
OLM(Operator Lifecycle Manager)은 각 Operator 그룹에 대해 다음 클러스터 역할을 생성합니다.
-
<operatorgroup_name>-admin
-
<operatorgroup_name>-edit
-
<operatorgroup_name>-view
Operator group을 수동으로 생성할 때 클러스터의 기존 클러스터 역할 또는 기타 Operator 그룹과 충돌하지 않는 고유한 이름을 지정해야 합니다.
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를 결합한 내용으로 교체합니다.
-
Operator group의
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으로 인한 실패 상태는 터미널이 아닙니다.
Operator group이 동기화될 때마다 다음 작업이 수행됩니다.
- 활성 멤버 CSV에서 제공되는 API 세트는 클러스터에서 계산됩니다. CSV 복사본은 무시됩니다.
-
클러스터 세트는
olm.providedAPIs
와 비교되며olm.providedAPIs
에 추가 API가 포함된 경우 해당 API가 정리됩니다. - 모든 네임스페이스에서 동일한 API를 제공하는 모든 CSV가 다시 큐에 추가됩니다. 그러면 충돌하는 CSV의 크기 조정 또는 삭제를 통해 충돌이 해결되었을 수 있음을 교차 group의 충돌하는 CSV에 알립니다.
2.4.5.10. 다중 테넌트 Operator 관리에 대한 제한 사항
OpenShift Container Platform은 동일한 클러스터에 다른 버전의 Operator를 동시에 설치할 수 있도록 제한된 지원을 제공합니다. OLM(Operator Lifecycle Manager)은 다른 네임스페이스에 Operator를 여러 번 설치합니다. 이에 대한 한 가지 제한 사항은 Operator의 API 버전이 동일해야 한다는 것입니다.
Operator는 Kubernetes의 글로벌 리소스인 CRD( CustomResourceDefinition
오브젝트)를 사용하므로 컨트롤 플레인 확장입니다. Operator의 다른 주요 버전에는 호환되지 않는 CRD가 있는 경우가 많습니다. 이로 인해 클러스터의 다른 네임스페이스에 동시에 설치할 수 없습니다.
모든 테넌트 또는 네임스페이스는 클러스터의 동일한 컨트롤 플레인을 공유합니다. 따라서 다중 테넌트 클러스터의 테넌트도 글로벌 CRD를 공유하므로 동일한 Operator의 다른 인스턴스를 동일한 클러스터에서 병렬로 사용할 수 있는 시나리오를 제한합니다.
지원되는 시나리오에는 다음이 포함됩니다.
- 정확히 동일한 CRD 정의를 제공하는 다른 버전의 Operator (버전이 지정된 CRD의 경우 정확히 동일한 버전 세트)
- CRD를 제공하지 않고 OperatorHub의 별도의 번들에서 CRD를 사용할 수 있는 다른 버전의 Operator
동일한 클러스터에서 조정할 다른 Operator 버전의 여러 가지 CRD가 있는 경우 클러스터 데이터의 무결성을 보장할 수 없기 때문에 다른 모든 시나리오가 지원되지 않습니다.
2.4.5.11. Operator groups 문제 해결
멤버십
설치 계획의 네임스페이스에는 하나의 Operator 그룹만 포함되어야 합니다. 네임스페이스에서 CSV(클러스터 서비스 버전)를 생성하려고 할 때 설치 계획은 다음 시나리오에서 Operator 그룹이 유효하지 않은 것으로 간주합니다.
- 설치 계획의 네임스페이스에 Operator 그룹이 없습니다.
- 설치 계획의 네임스페이스에 여러 Operator 그룹이 있습니다.
- Operator 그룹에 잘못된 서비스 계정 이름이 지정되어 있습니다.
설치 계획이 유효하지 않은 Operator 그룹이 발생하면 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 Container Platform 웹 콘솔을 사용하여 Operator를 설치할 때 모든 네임스페이스 설치 모드를 지원하는 Operator를 기본 openshift-operators
글로벌 네임스페이스에 설치하므로 일반적으로 표시됩니다.
클러스터 관리자는 다음 워크플로우를 사용하여 이 기본 동작을 수동으로 바이패스할 수 있습니다.
- Operator 설치를 위한 네임스페이스를 생성합니다.
- 모든 네임스페이스를 감시하는 Operator group인 사용자 정의 글로벌 Operator group을 생성합니다. 이 Operator group을 방금 생성한 네임스페이스와 연결하여 설치 네임스페이스를 글로벌 네임스페이스로 만들어 모든 네임스페이스에서 Operator를 사용할 수 있습니다.
- 설치 네임스페이스에 원하는 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"
2.4.7.3. 추가 리소스
2.4.8. Operator Lifecycle Manager 지표
2.4.8.1. 표시되는 지표
OLM(Operator Lifecycle Manager)에서는 Prometheus 기반 OpenShift Container Platform 클러스터 모니터링 스택에서 사용할 특정 OLM 관련 리소스를 표시합니다.
이름 | 설명 |
---|---|
| 카탈로그 소스 수입니다. |
|
카탈로그 소스의 상태입니다. 값 |
|
CSV(클러스터 서비스 버전)를 조정할 때 CSV 버전이 |
| 성공적으로 등록된 CSV 수입니다. |
|
CSV를 재조정할 때 CSV 버전이 |
| CSV 업그레이드의 단조 수입니다. |
| 설치 계획 수입니다. |
| 더 이상 사용되지 않는 리소스와 같이 설치 계획에 포함된 리소스에서 생성한 경고의 단조 수입니다. |
| 종속성 확인 시도의 기간입니다. |
| 서브스크립션 수입니다. |
|
서브스크립션 동기화의 단조 수입니다. |
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. 추가 리소스
- 웹 후크 승인 플러그인의 유형
Kubernetes 설명서: