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 워크플로

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

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

2.4.1.2. OLM 리소스

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

Expand
표 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 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도 표시됩니다.

작은 정보

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

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

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 Container Platform 릴리스에서는 기본값이 제한 될 예정입니다.
참고

제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.

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에 지시합니다.

카탈로그 소스를 참조하는 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.15)에 대해 특별히 생성된 인덱스 이미지의 이미지 태그를 식별하는 것입니다.

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

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

다음으로 변경합니다.

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

그러나 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.9. 이미지 템플릿이 있는 카탈로그 소스의 예

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.28
  priority: -400
  publisher: Example Org
참고

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

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

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

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

향후 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.10. 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 오브젝트에 존재하지 않습니다.

Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 소개

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

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

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

Red Hat 문서 정보

Legal Notice

Theme

© 2026 Red Hat
맨 위로 이동