7.3. OLM 1.0의 카탈로그에서 Operator 설치 (기술 프리뷰)

PDF

클러스터 관리자는 카탈로그 또는 Operator 및 Kubernetes 확장의 컬렉션을 클러스터에 추가할 수 있습니다. Operator 작성자는 해당 카탈로그에 제품을 게시합니다. 클러스터에 카탈로그를 추가할 때 카탈로그에 게시된 Operator 및 확장의 버전, 패치 및 무선 업데이트에 액세스할 수 있습니다.

OLM(Operator Lifecycle Manager) 1.0의 현재 기술 프리뷰 릴리스에서는 CR(사용자 정의 리소스)을 사용하여 CLI에서 카탈로그 및 Operator를 선언적으로 관리합니다.

중요

OLM 1.0은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.

Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.

7.3.1. 사전 요구 사항

cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스
참고
OpenShift Container Platform 4.15의 경우 OLM 1.0에 대한 문서화된 절차는 CLI 기반 전용입니다. 또는 관리자는 YAML 가져오기 및 검색 페이지와 같은 일반 방법을 사용하여 웹 콘솔에서 관련 오브젝트를 생성하고 볼 수 있습니다. 그러나 기존 OperatorHub 및 설치된 Operator 페이지에는 OLM 1.0 구성 요소가 표시되지 않습니다.
클러스터에서 TechPreviewNoUpgrade 기능 세트 활성화
주의
TechPreviewNoUpgrade 기능 세트를 활성화하면 취소할 수 없으며 마이너 버전 업데이트가 허용되지 않습니다. 이러한 기능 세트는 프로덕션 클러스터에서는 권장되지 않습니다.
워크스테이션에 설치된 OpenShift CLI(oc)

추가 리소스

기능 게이트를 사용한 기능 활성화

7.3.2. OLM 1.0의 카탈로그 정보

카탈로그 구성 요소를 사용하여 Operator 및 컨트롤러와 같은 Kubernetes 확장 카탈로그를 쿼리하여 설치 가능한 콘텐츠를 검색할 수 있습니다. Catalogd는 클러스터 내 클라이언트의 카탈로그 콘텐츠의 압축을 풀고 OLM(Operator Lifecycle Manager) 1.0 마이크로 서비스 제품군의 일부입니다. 현재 catalogd는 컨테이너 이미지로 패키지 및 배포되는 카탈로그 콘텐츠의 압축을 풉니다.

중요

고유한 이름이 없는 Operator 또는 확장을 설치하려고 하면 설치에 실패하거나 예기치 않은 결과가 발생할 수 있습니다. 이는 다음과 같은 이유로 발생합니다.

mulitple 카탈로그가 클러스터에 설치된 경우 OLM 1.0에는 Operator 또는 확장을 설치할 때 카탈로그를 지정하는 메커니즘이 포함되어 있지 않습니다.
OLM(Operator Lifecycle Manager) 1.0의 종속성 확인에서는 클러스터에 설치할 수 있는 모든 Operator 및 확장이 번들 및 패키지에 고유한 이름을 사용해야 합니다.

추가 리소스

파일 기반 카탈로그

7.3.3. OLM 1.0의 Red Hat 제공 Operator 카탈로그

OLM(Operator Lifecycle Manager) 1.0에는 기본적으로 Red Hat 제공 Operator 카탈로그가 포함되어 있지 않습니다. Red Hat 제공 카탈로그를 클러스터에 추가하려면 카탈로그의 CR(사용자 정의 리소스)을 생성하여 클러스터에 적용합니다. 다음 CR(사용자 정의 리소스) 예제에서는 OLM 1.0에 대한 카탈로그 리소스를 생성하는 방법을 보여줍니다.

중요

registry.redhat.io 의 Red Hat 제공 Operator 카탈로그와 같은 보안 레지스트리에서 호스팅되는 카탈로그를 사용하려면 openshift-catalogd 네임스페이스에 풀 시크릿 범위가 지정되어야 합니다. 자세한 내용은 "보안 레지스트리에서 호스팅되는 카탈로그의 풀 시크릿 생성"을 참조하십시오.

Red Hat Operator 카탈로그의 예

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: <poll_interval_duration> 1

1: 최신 이미지 다이제스트를 위해 원격 레지스트리를 폴링하는 간격을 지정합니다. 기본값은 24h 입니다. 유효한 단위에는 초(s), 분(m) 및 시간(h)이 포함됩니다. 폴링을 비활성화하려면 0s 와 같은 0 값을 설정합니다.

인증된 Operator 카탈로그의 예

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: certified-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/certified-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

커뮤니티 Operator 카탈로그의 예

apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: community-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/community-operator-index:v4.15
      pullSecret: <pull_secret_name>
      pollInterval: 24h

다음 명령은 클러스터에 카탈로그를 추가합니다.

명령 구문

$ oc apply -f <catalog_name>.yaml 1

1: redhat-operators.yaml 과 같은 카탈로그 CR을 지정합니다.

추가 리소스

7.3.4. 보안 레지스트리에서 호스팅되는 카탈로그의 풀 시크릿 생성

registry.redhat.io 의 Red Hat 제공 Operator 카탈로그와 같은 보안 레지스트리에서 호스팅되는 카탈로그를 사용하려면 openshift-catalogd 네임스페이스에 풀 시크릿 범위가 지정되어야 합니다.

참고

현재 catalogd는 OpenShift Container Platform 클러스터에서 글로벌 풀 시크릿을 읽을 수 없습니다. Catalogd는 배포된 네임스페이스에서만 보안에 대한 참조를 읽을 수 있습니다.

사전 요구 사항

보안 레지스트리의 로그인 인증 정보
워크스테이션에 Docker 또는 Podman이 설치되어 있어야 합니다.

프로세스

보안 레지스트리에 대한 로그인 인증 정보가 있는 .dockercfg 파일이 이미 있는 경우 다음 명령을 실행하여 가져오기 보안을 생성합니다.

$ oc create secret generic <pull_secret_name> \
    --from-file=.dockercfg=<file_path>/.dockercfg \
    --type=kubernetes.io/dockercfg \
    --namespace=openshift-catalogd

예 7.1. 명령 예

$ oc create secret generic redhat-cred \
    --from-file=.dockercfg=/home/<username>/.dockercfg \
    --type=kubernetes.io/dockercfg \
    --namespace=openshift-catalogd

보안 레지스트리의 로그인 인증 정보가 있는 $HOME/.docker/config.json 파일이 이미 있는 경우 다음 명령을 실행하여 풀 시크릿을 생성합니다.

$ oc create secret generic <pull_secret_name> \
    --from-file=.dockerconfigjson=<file_path>/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson \
    --namespace=openshift-catalogd

예 7.2. 명령 예

$ oc create secret generic redhat-cred \
    --from-file=.dockerconfigjson=/home/<username>/.docker/config.json \
    --type=kubernetes.io/dockerconfigjson \
    --namespace=openshift-catalogd

보안 레지스트리에 대한 로그인 인증 정보가 있는 Docker 구성 파일이 없는 경우 다음 명령을 실행하여 가져오기 보안을 생성합니다.

$ oc create secret docker-registry <pull_secret_name> \
    --docker-server=<registry_server> \
    --docker-username=<username> \
    --docker-password=<password> \
    --docker-email=<email> \
    --namespace=openshift-catalogd

예 7.3. 명령 예

$ oc create secret docker-registry redhat-cred \
    --docker-server=registry.redhat.io \
    --docker-username=username \
    --docker-password=password \
    --docker-email=user@example.com \
    --namespace=openshift-catalogd

7.3.5. 클러스터에 카탈로그 추가

클러스터에 카탈로그를 추가하려면 카탈로그 CR(사용자 정의 리소스)을 생성하여 클러스터에 적용합니다.

사전 요구 사항

registry.redhat.io 의 Red Hat 제공 Operator 카탈로그와 같은 보안 레지스트리에서 호스팅되는 카탈로그를 사용하려면 openshift-catalogd 네임스페이스에 풀 시크릿 범위가 지정되어야 합니다. 자세한 내용은 "보안 레지스트리에서 호스팅되는 카탈로그의 풀 시크릿 생성"을 참조하십시오.

프로세스

다음 예와 유사한 카탈로그 CR(사용자 정의 리소스)을 생성합니다.
예: redhat-operators.yaml
```
apiVersion: catalogd.operatorframework.io/v1alpha1
kind: Catalog
metadata:
  name: redhat-operators
spec:
  source:
    type: image
    image:
      ref: registry.redhat.io/redhat/redhat-operator-index:v4.15 1
      pullSecret: <pull_secret_name> 2
      pollInterval: <poll_interval_duration> 3
```
1
spec.source.image 필드에 카탈로그의 이미지를 지정합니다.
2
카탈로그가 registry.redhat.io 와 같은 보안 레지스트리에서 호스팅되는 경우 openshift-catalog 네임스페이스에 대한 풀 시크릿 범위를 생성해야 합니다.
3
최신 이미지 다이제스트를 위해 원격 레지스트리를 폴링하는 간격을 지정합니다. 기본값은 24h 입니다. 유효한 단위에는 초(s), 분(m) 및 시간(h)이 포함됩니다. 폴링을 비활성화하려면 0s 와 같은 0 값을 설정합니다.

다음 명령을 실행하여 클러스터에 카탈로그를 추가합니다.

$ oc apply -f redhat-operators.yaml

출력 예

catalog.catalogd.operatorframework.io/redhat-operators created

검증

다음 명령을 실행하여 카탈로그 상태를 확인합니다.

다음 명령을 실행하여 카탈로그를 사용할 수 있는지 확인합니다.
```
$ oc get catalog
```
출력 예
```
NAME                  AGE
redhat-operators      20s
```

다음 명령을 실행하여 카탈로그의 상태를 확인합니다.

$ oc describe catalog

출력 예

Name:         redhat-operators
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  catalogd.operatorframework.io/v1alpha1
Kind:         Catalog
Metadata:
  Creation Timestamp:  2024-01-10T16:18:38Z
  Finalizers:
    catalogd.operatorframework.io/delete-server-cache
  Generation:        1
  Resource Version:  57057
  UID:               128db204-49b3-45ee-bfea-a2e6fc8e34ea
Spec:
  Source:
    Image:
      Pull Secret:  redhat-cred
      Ref:          registry.redhat.io/redhat/redhat-operator-index:v4.15
    Type:           image
Status: 1
  Conditions:
    Last Transition Time:  2024-01-10T16:18:55Z
    Message:
    Reason:                UnpackSuccessful 2
    Status:                True
    Type:                  Unpacked
  Content URL:             http://catalogd-catalogserver.openshift-catalogd.svc/catalogs/redhat-operators/all.json
  Observed Generation:     1
  Phase:                   Unpacked 3
  Resolved Source:
    Image:
      Last Poll Attempt:  2024-01-10T16:18:51Z
      Ref:                registry.redhat.io/redhat/redhat-operator-index:v4.15
      Resolved Ref:       registry.redhat.io/redhat/redhat-operator-index@sha256:7b536ae19b8e9f74bb521c4a61e5818e036ac1865a932f2157c6c9a766b2eea5 4
    Type:                 image
Events:                   <none>

1: 카탈로그 상태를 설명합니다.
2: 카탈로그가 현재 상태에 있는 이유를 표시합니다.
3: 설치 프로세스의 단계를 표시합니다.
4: 카탈로그의 이미지 참조를 표시합니다.

추가 리소스

보안 레지스트리에서 호스팅되는 카탈로그의 풀 시크릿 생성

7.3.6. 카탈로그에서 설치할 Operator 찾기

클러스터에 카탈로그를 추가한 후 카탈로그를 쿼리하여 설치할 Operator 및 확장을 찾을 수 있습니다. 카탈로그를 쿼리하려면 먼저 카탈로그 서버 서비스를 전달하도록 포트해야 합니다.

사전 요구 사항

클러스터에 카탈로그를 추가했습니다.
jq CLI 툴을 설치했습니다.

프로세스

포트 다음 명령을 실행하여 openshift-catalogd 네임스페이스에서 카탈로그 서버 서비스를 전달합니다.
```
$ oc -n openshift-catalogd port-forward svc/catalogd-catalogserver 8080:80
```

다음 명령을 실행하여 카탈로그의 JSON 파일을 로컬로 다운로드합니다.

$ curl -L http://localhost:8080/catalogs/<catalog_name>/all.json \
  -C - -o /<path>/<catalog_name>.json

예 7.4. 명령 예

$ curl -L http://localhost:8080/catalogs/redhat-operators/all.json \
  -C - -o /home/username/catalogs/rhoc.json

다음 명령 중 하나를 실행하여 카탈로그의 Operator 및 확장 목록을 반환합니다.

중요

현재 OLM(Operator Lifecycle Manager) 1.0은 Webhook를 사용하지 않고 AllNamespaces 설치 모드를 사용하도록 구성된 확장을 지원합니다. Webhook를 사용하거나 단일 또는 지정된 네임스페이스 집합을 대상으로 하는 확장 프로그램을 설치할 수 없습니다.

다음 명령을 실행하여 로컬 카탈로그 파일에서 모든 Operator 및 확장 프로그램 목록을 가져옵니다.

$ jq -s '.[] | select(.schema == "olm.package") | .name' \
  /<path>/<filename>.json

예 7.5. 명령 예

$ jq -s '.[] | select(.schema == "olm.package") | .name' \
  /home/username/catalogs/rhoc.json

예 7.6. 출력 예

NAME                                                        AGE
"3scale-operator"
"advanced-cluster-management"
"amq-broker-rhel8"
"amq-online"
"amq-streams"
"amq7-interconnect-operator"
"ansible-automation-platform-operator"
"ansible-cloud-addons-operator"
"apicast-operator"
"aws-efs-csi-driver-operator"
"aws-load-balancer-operator"
"bamoe-businessautomation-operator"
"bamoe-kogito-operator"
"bare-metal-event-relay"
"businessautomation-operator"
...

AllNamespaces 설치 모드를 지원하는 패키지 목록을 가져오고 다음 명령을 실행하여 로컬 카탈로그 파일의 Webhook를 사용하지 않습니다.

$ jq -c 'select(.schema == "olm.bundle") | \
  {"package":.package, "version":.properties[] | \
  select(.type == "olm.bundle.object").value.data | @base64d | fromjson | \
  select(.kind == "ClusterServiceVersion" and (.spec.installModes[] | \
  select(.type == "AllNamespaces" and .supported == true) != null) \
  and .spec.webhookdefinitions == null).spec.version}' \
  /<path>/<catalog_name>.json

예 7.7. 출력 예

{"package":"3scale-operator","version":"0.10.0-mas"}
{"package":"3scale-operator","version":"0.10.5"}
{"package":"3scale-operator","version":"0.11.0-mas"}
{"package":"3scale-operator","version":"0.11.1-mas"}
{"package":"3scale-operator","version":"0.11.2-mas"}
{"package":"3scale-operator","version":"0.11.3-mas"}
{"package":"3scale-operator","version":"0.11.5-mas"}
{"package":"3scale-operator","version":"0.11.6-mas"}
{"package":"3scale-operator","version":"0.11.7-mas"}
{"package":"3scale-operator","version":"0.11.8-mas"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-1"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-2"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-3"}
{"package":"amq-broker-rhel8","version":"7.10.0-opr-4"}
{"package":"amq-broker-rhel8","version":"7.10.1-opr-1"}
{"package":"amq-broker-rhel8","version":"7.10.1-opr-2"}
{"package":"amq-broker-rhel8","version":"7.10.2-opr-1"}
{"package":"amq-broker-rhel8","version":"7.10.2-opr-2"}
...

다음 명령을 실행하여 Operator 또는 확장의 메타데이터 콘텐츠를 검사합니다.

$ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "<package_name>")' /<path>/<catalog_name>.json

예 7.8. 명령 예

$ jq -s '.[] | select( .schema == "olm.package") | \
  select( .name == "openshift-pipelines-operator-rh")' \
  /home/username/rhoc.json

예 7.9. 출력 예

{
  "defaultChannel": "stable",
  "icon": {
    "base64data": "PHN2ZyB4bWxu..."
    "mediatype": "image/png"
  },
  "name": "openshift-pipelines-operator-rh",
  "schema": "olm.package"
}

7.3.6.1. 공통 카탈로그 쿼리

jq CLI 툴을 사용하여 카탈로그를 쿼리할 수 있습니다.

표 7.1. 일반적인 패키지 쿼리
쿼리	요청
카탈로그에서 사용 가능한 패키지	$ jq -s '.[] \| select( .schema == "olm.package") \| \ .name' <catalog_name>.json
`AllNamespaces` 설치 모드를 지원하고 Webhook를 사용하지 않는 패키지	$ jq -c 'select(.schema == "olm.bundle") \| \ {"package":.package, "version":.properties[] \| \ select(.type == "olm.bundle.object").value.data \| \ @base64d \| fromjson \| \ select(.kind == "ClusterServiceVersion" and (.spec.installModes[] \| \ select(.type == "AllNamespaces" and .supported == true) != null) \ and .spec.webhookdefinitions == null).spec.version}' \ <catalog_name>.json
패키지 메타데이터	$ jq -s '.[] \| select( .schema == "olm.package") \| \ select( .name == "<package_name>")' <catalog_name>.json
패키지의 카탈로그 Blob	$ jq -s '.[] \| select( .package == "<package_name>")' \ <catalog_name>.json

표 7.2. 공통 채널 쿼리
쿼리	요청
패키지의 채널	$ jq -s '.[] \| select( .schema == "olm.channel" ) \| \ select( .package == "<package_name>") \| .name' \ <catalog_name>.json
채널의 버전	$ jq -s '.[] \| select( .package == "<package_name>" ) \| \ select( .schema == "olm.channel" ) \| \ select( .name == "<channel_name>" ) \| \ .entries \| .[] \| .name' <catalog_name>.json
채널의 최신 버전 업그레이드 경로	$ jq -s '.[] \| select( .schema == "olm.channel" ) \| \ select ( .name == "<channel>") \| \ select( .package == "<package_name>")' \ <catalog_name>.json

표 7.2. 공통 채널 쿼리

쿼리

요청

패키지의 채널

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | .name' \
  <catalog_name>.json

채널의 버전

$ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | \
  .entries | .[] | .name' <catalog_name>.json

채널의 최신 버전
업그레이드 경로

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select ( .name == "<channel>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json

표 7.3. 공통 번들 쿼리
쿼리	요청
패키지의 번들	$ jq -s '.[] \| select( .schema == "olm.bundle" ) \| \ select( .package == "<package_name>") \| .name' \ <catalog_name>.json
번들 종속 항목 사용 가능한 API	$ jq -s '.[] \| select( .schema == "olm.bundle" ) \| \ select ( .name == "<bundle_name>") \| \ select( .package == "<package_name>")' \ <catalog_name>.json

표 7.3. 공통 번들 쿼리

쿼리

요청

패키지의 번들

$ jq -s '.[] | select( .schema == "olm.bundle" ) | \
  select( .package == "<package_name>") | .name' \
  <catalog_name>.json

번들 종속 항목
사용 가능한 API

$ jq -s '.[] | select( .schema == "olm.bundle" ) | \
  select ( .name == "<bundle_name>") | \
  select( .package == "<package_name>")' \
  <catalog_name>.json

7.3.7. 카탈로그에서 Operator 설치

OLM(Operator Lifecycle Manager) 1.0에서는 클러스터에 대한 Operator 및 확장 범위를 지원합니다. CR(사용자 정의 리소스)을 생성하고 클러스터에 적용하여 카탈로그에서 Operator 또는 확장을 설치할 수 있습니다.

중요

현재 OLM 1.0에서는 다음 기준을 충족하는 Operator 및 확장 기능을 설치할 수 있습니다.

Operator 또는 확장에서는 AllNamespaces 설치 모드를 사용해야 합니다.
Operator 또는 확장에서는 Webhook를 사용하지 않아야 합니다.

Webhook를 사용하거나 단일 또는 지정된 네임스페이스 집합을 대상으로 하는 Operator 또는 확장은 설치할 수 없습니다.

사전 요구 사항

클러스터에 카탈로그를 추가했습니다.
카탈로그 파일의 로컬 사본을 다운로드했습니다.
jq CLI 툴을 설치했습니다.

프로세스

다음 단계를 완료하여 카탈로그 파일의 로컬 사본에서 채널 및 버전 정보에 대한 패키지를 검사합니다.

다음 명령을 실행하여 선택한 패키지에서 채널 목록을 가져옵니다.

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | \
  .name' /<path>/<catalog_name>.json

예 7.10. 명령 예

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "openshift-pipelines-operator-rh") | \
  .name' /home/username/rhoc.json

예 7.11. 출력 예

"latest"
"pipelines-1.11"
"pipelines-1.12"
"pipelines-1.13"

다음 명령을 실행하여 채널에 게시된 버전 목록을 가져옵니다.

$ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | .entries | \
  .[] | .name' /<path>/<catalog_name>.json

예 7.12. 명령 예

$ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
.entries | .[] | .name' /home/username/rhoc.json

예 7.13. 출력 예

"openshift-pipelines-operator-rh.v1.11.1"
"openshift-pipelines-operator-rh.v1.12.0"
"openshift-pipelines-operator-rh.v1.12.1"
"openshift-pipelines-operator-rh.v1.12.2"
"openshift-pipelines-operator-rh.v1.13.0"
"openshift-pipelines-operator-rh.v1.13.1"

다음 예와 유사한 CR을 생성합니다.
pipelines-operator.yaml CR의 예
```
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: <channel>
  version: "<version>"
```
다음과 같습니다.
<channel>
선택 사항: 설치 또는 업데이트하려는 패키지에 대해 pipelines-1.11 또는 latest 와 같은 채널을 지정합니다.
<version>
선택 사항: 설치 또는 업데이트하려는 패키지의 1.11.1,1.12.x 또는 > =1.12.1 과 같은 버전 범위를 지정합니다. 자세한 내용은 "대상 버전을 지정하는 CR(사용자 정의 리소스) 예" 및 "버전 범위에 대한 지원"을 참조하십시오.
중요
고유한 이름이 없는 Operator 또는 확장을 설치하려고 하면 설치에 실패하거나 예기치 않은 결과가 발생할 수 있습니다. 이는 다음과 같은 이유로 발생합니다.
mulitple 카탈로그가 클러스터에 설치된 경우 OLM 1.0에는 Operator 또는 확장을 설치할 때 카탈로그를 지정하는 메커니즘이 포함되어 있지 않습니다.
OLM(Operator Lifecycle Manager) 1.0의 종속성 확인에서는 클러스터에 설치할 수 있는 모든 Operator 및 확장이 번들 및 패키지에 고유한 이름을 사용해야 합니다.

다음 명령을 실행하여 클러스터에 CR을 적용합니다.

$ oc apply -f pipeline-operator.yaml

출력 예

operator.operators.operatorframework.io/pipelines-operator created

검증

다음 명령을 실행하여 Operator 또는 확장의 CR을 YAML 형식으로 표시합니다.

$ oc get operator.operators.operatorframework.io pipelines-operator -o yaml

참고

채널을 지정하거나 Operator 또는 확장의 CR에 버전 범위를 정의하면 OLM 1.0에 클러스터에 설치된 확인된 버전이 표시되지 않습니다. CR에 지정된 버전 및 채널 정보만 표시됩니다.

설치된 특정 버전을 찾으려면 spec.source.image.ref 필드의 SHA를 카탈로그의 이미지 참조와 비교해야 합니다.

예 7.14. 출력 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"1.11.x"}}
  creationTimestamp: "2024-01-30T20:06:09Z"
  generation: 1
  name: pipelines-operator
  resourceVersion: "44362"
  uid: 4272d228-22e1-419e-b9a7-986f982ee588
spec:
  channel: latest
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 1.11.x
status:
  conditions:
  - lastTransitionTime: "2024-01-30T20:06:15Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Resolved
  - lastTransitionTime: "2024-01-30T20:06:31Z"
    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
    observedGeneration: 1
    reason: Success
    status: "True"
    type: Installed
  installedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280
  resolvedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280

다음 명령을 실행하여 번들 배포에 대한 정보를 가져옵니다.

$ oc get bundleDeployment pipelines-operator -o yaml

예 7.15. 출력 예

apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  creationTimestamp: "2024-01-30T20:06:15Z"
  generation: 2
  name: pipelines-operator
  ownerReferences:
  - apiVersion: operators.operatorframework.io/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: Operator
    name: pipelines-operator
    uid: 4272d228-22e1-419e-b9a7-986f982ee588
  resourceVersion: "44464"
  uid: 0a0c3525-27e2-4c93-bf57-55920a7707c0
spec:
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata: {}
    spec:
      provisionerClassName: core-rukpak-io-registry
      source:
        image:
          ref: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280
        type: image
status:
  activeBundle: pipelines-operator-29x720cjzx8yiowf13a3j75fil2zs3mfw
  conditions:
  - lastTransitionTime: "2024-01-30T20:06:15Z"
    message: Successfully unpacked the pipelines-operator-29x720cjzx8yiowf13a3j75fil2zs3mfw
      Bundle
    reason: UnpackSuccessful
    status: "True"
    type: HasValidBundle
  - lastTransitionTime: "2024-01-30T20:06:28Z"
    message: Instantiated bundle pipelines-operator-29x720cjzx8yiowf13a3j75fil2zs3mfw
      successfully
    reason: InstallationSucceeded
    status: "True"
    type: Installed
  - lastTransitionTime: "2024-01-30T20:06:40Z"
    message: BundleDeployment is healthy
    reason: Healthy
    status: "True"
    type: Healthy
  observedGeneration: 2

추가 리소스

7.3.8. Operator 업데이트

CR(사용자 정의 리소스)을 수동으로 편집하고 변경 사항을 적용하여 Operator 또는 확장을 업데이트할 수 있습니다.

사전 요구 사항

카탈로그가 설치되어 있어야 합니다.
카탈로그 파일의 로컬 사본을 다운로드했습니다.
Operator 또는 확장이 설치되어 있어야 합니다.
jq CLI 툴을 설치했습니다.

프로세스

다음 단계를 완료하여 카탈로그 파일의 로컬 사본에서 채널 및 버전 정보에 대한 패키지를 검사합니다.

다음 명령을 실행하여 선택한 패키지에서 채널 목록을 가져옵니다.

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "<package_name>") | \
  .name' /<path>/<catalog_name>.json

예 7.16. 명령 예

$ jq -s '.[] | select( .schema == "olm.channel" ) | \
  select( .package == "openshift-pipelines-operator-rh") | \
  .name' /home/username/rhoc.json

예 7.17. 출력 예

"latest"
"pipelines-1.11"
"pipelines-1.12"
"pipelines-1.13"

다음 명령을 실행하여 채널에 게시된 버전 목록을 가져옵니다.

$ jq -s '.[] | select( .package == "<package_name>" ) | \
  select( .schema == "olm.channel" ) | \
  select( .name == "<channel_name>" ) | .entries | \
  .[] | .name' /<path>/<catalog_name>.json

예 7.18. 명령 예

$ jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) | \
select( .schema == "olm.channel" ) | select( .name == "latest" ) | \
.entries | .[] | .name' /home/username/rhoc.json

예 7.19. 출력 예

"openshift-pipelines-operator-rh.v1.11.1"
"openshift-pipelines-operator-rh.v1.12.0"
"openshift-pipelines-operator-rh.v1.12.1"
"openshift-pipelines-operator-rh.v1.12.2"
"openshift-pipelines-operator-rh.v1.13.0"
"openshift-pipelines-operator-rh.v1.13.1"

다음 명령을 실행하여 Operator 또는 확장의 CR에 지정된 버전 또는 채널을 확인합니다.

$ oc get operator.operators.operatorframework.io <operator_name> -o yaml

명령 예

$ oc get operator.operators.operatorframework.io pipelines-operator -o yaml

예 7.20. 출력 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |  {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"1.11.1"}}
  creationTimestamp: "2024-02-06T17:47:15Z"
  generation: 2
  name: pipelines-operator
  resourceVersion: "84528"
  uid: dffe2c89-b9c4-427e-b694-ada0b37fc0a9
spec:
  channel: latest 1
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 1.11.1 2
status:
  conditions:
  - lastTransitionTime: "2024-02-06T17:47:21Z"
    message: bundledeployment status is unknown
    observedGeneration: 2
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  - lastTransitionTime: "2024-02-06T17:50:58Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280"
    observedGeneration: 2
    reason: Success
    status: "True"
    type: Resolved
  resolvedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:e09d37bb1e754db42324fd18c1cb3e7ce77e7b7fcbf4932d0535391579938280

1: Operator 또는 확장의 채널을 지정합니다.
2: Operator 또는 확장의 버전 범위를 지정합니다.

참고

설치된 특정 버전을 찾으려면 spec.source.image.ref 필드의 SHA를 카탈로그의 이미지 참조와 비교해야 합니다.

다음 방법 중 하나를 사용하여 CR을 편집합니다.
- Operator 또는 확장을 1.12.1 과 같은 특정 버전으로 고정하려면 다음 예와 유사한 CR을 편집합니다.
  pipelines-operator.yaml CR의 예
```
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: 1.12.1 1
```
  1
  버전 1.11.1 에서 1.12.1로 업데이트
- 허용 가능한 업데이트 버전의 범위를 정의하려면 다음 예와 유사한 CR을 편집합니다.
  버전 범위가 지정된 CR의 예
```
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: ">1.11.1, <1.13" 1
```
  1
  원하는 버전 범위가 버전 1.11.1 보다 크고 1.13 보다 작도록 지정합니다. 자세한 내용은 "버전 범위 지원" 및 "버전 비교 문자열"을 참조하십시오.
- 채널에서 확인할 수 있는 최신 버전으로 업데이트하려면 다음 예제와 유사한 CR을 편집합니다.
  지정된 채널이 있는 CR의 예
```
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: pipelines-1.13 1
```
  1
  지정된 채널에서 확인할 수 있는 최신 릴리스를 설치합니다. 채널 업데이트가 자동으로 설치됩니다.
- 채널 및 버전 범위를 지정하려면 다음 예와 유사한 CR을 편집합니다.
  지정된 채널 및 버전 범위가 있는 CR의 예
```
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: latest
  version: "<1.13"
```
  자세한 내용은 "대상 버전을 지정하는 CR(사용자 정의 리소스) 예"를 참조하십시오.

다음 명령을 실행하여 클러스터에 업데이트를 적용합니다.

$ oc apply -f pipelines-operator.yaml

출력 예

operator.operators.operatorframework.io/pipelines-operator configured

작은 정보

다음 명령을 실행하여 CLI에서 CR을 패치하고 적용할 수 있습니다.

$ oc patch operator.operators.operatorframework.io/pipelines-operator -p \
  '{"spec":{"version":"1.12.1"}}' \
  --type=merge

출력 예

operator.operators.operatorframework.io/pipelines-operator patched

검증

다음 명령을 실행하여 채널 및 버전 업데이트가 적용되었는지 확인합니다.

$ oc get operator.operators.operatorframework.io pipelines-operator -o yaml

예 7.21. 출력 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"1.12.1"}}
  creationTimestamp: "2024-02-06T19:16:12Z"
  generation: 4
  name: pipelines-operator
  resourceVersion: "58122"
  uid: 886bbf73-604f-4484-9f87-af6ce0f86914
spec:
  channel: latest
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 1.12.1 1
status:
  conditions:
  - lastTransitionTime: "2024-02-06T19:30:57Z"
    message: installed from "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a"
    observedGeneration: 3
    reason: Success
    status: "True"
    type: Installed
  - lastTransitionTime: "2024-02-06T19:30:57Z"
    message: resolved to "registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a"
    observedGeneration: 3
    reason: Success
    status: "True"
    type: Resolved
  installedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a
  resolvedBundleResource: registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2f1b8ef0fd741d1d686489475423dabc07c55633a4dfebc45e1d533183179f6a

1: 버전이 1.12.1 로 업데이트되었는지 확인합니다.

문제 해결

존재하지 않는 대상 버전 또는 채널을 지정하는 경우 다음 명령을 실행하여 Operator 또는 확장 상태를 확인할 수 있습니다.

$ oc get operator.operators.operatorframework.io <operator_name> -o yaml

예 7.22. 출력 예

oc get operator.operators.operatorframework.io pipelines-operator -o yaml
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"pipelines-operator"},"spec":{"channel":"latest","packageName":"openshift-pipelines-operator-rh","version":"2.0.0"}}
  creationTimestamp: "2024-02-06T17:47:15Z"
  generation: 1
  name: pipelines-operator
  resourceVersion: "82667"
  uid: dffe2c89-b9c4-427e-b694-ada0b37fc0a9
spec:
  channel: latest
  packageName: openshift-pipelines-operator-rh
  upgradeConstraintPolicy: Enforce
  version: 2.0.0
status:
  conditions:
  - lastTransitionTime: "2024-02-06T17:47:21Z"
    message: installation has not been attempted due to failure to gather data for
      resolution
    observedGeneration: 1
    reason: InstallationStatusUnknown
    status: Unknown
    type: Installed
  - lastTransitionTime: "2024-02-06T17:47:21Z"
    message: no package "openshift-pipelines-operator-rh" matching version "2.0.0"
      found in channel "latest"
    observedGeneration: 1
    reason: ResolutionFailed
    status: "False"
    type: Resolved

추가 리소스

7.3.8.1. 의미 체계 버전 관리 지원

OLM 1.0에서는 기본적으로 의미 체계 버전 관리(semver) 지원이 활성화됩니다. Operator 및 확장 작성자는 semver 표준을 사용하여 호환 가능한 업데이트를 정의할 수 있습니다.

OLM(Operator Lifecycle Manager) 1.0은 Operator 또는 확장의 버전 번호를 사용하여 업데이트를 성공적으로 해결할 수 있는지 확인할 수 있습니다.

클러스터 관리자는 설치 및 자동 업데이트할 수 있는 다양한 버전을 정의할 수 있습니다. semver 표준을 따르는 Operator 및 확장의 경우 비교 문자열을 사용하여 원하는 버전 범위를 지정할 수 있습니다.

참고

OLM 1.0은 다음 주요 버전에 대한 자동 업데이트를 지원하지 않습니다. 주요 버전 업데이트를 수행하려면 수동으로 업데이트를 확인하고 적용해야 합니다. 자세한 내용은 "업데이트 또는 롤백 요청"을 참조하십시오.

7.3.8.1.1. 메이저 버전 제로 릴리스

semver 표준은 주요 버전 0 릴리스(O.y.z)가 초기 개발을 위해 예약되어 있음을 지정합니다. 초기 개발 단계에서 API는 안정적이지 않으며 변경 사항이 모든 게시된 버전에 도입될 수 있습니다. 결과적으로 메이저 버전 제로 릴리스는 특수 업데이트 조건 세트를 적용합니다.

메이저 버전 제로 릴리스의 업데이트 조건

메이저 버전과 마이너 버전이 모두 0이면 자동 업데이트를 적용할 수 없습니다(예: 0.0.* ). 예를 들어 버전 범위가 >=0. 0.1 <0.1.0 인 자동 업데이트는 허용되지 않습니다.
주요 버전 0 릴리스 내에서 하나의 마이너 버전에서 다른 마이너 버전에 자동 업데이트를 적용할 수 없습니다. 예를 들어 OLM 1.0은 0.1.0 에서 0.2.0 까지의 업데이트를 자동으로 적용하지 않습니다.
패치 버전에서 자동 업데이트를 적용할 수 있습니다 (예: >=0. 1.0 <0.2.0 또는 >=0. 2.0 <0.3.0 ).

OLM 1.0에서 자동 업데이트가 차단되면 Operator 또는 확장의 CR(사용자 정의 리소스)을 편집하여 수동으로 업데이트를 확인하고 강제 적용해야 합니다.

추가 리소스

업데이트 또는 롤백 강제 적용

7.3.8.2. 버전 범위 지원

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

해결된 버전 워크플로

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

OLM 1.0의 종속성 및 제약 조건 확인에 대한 자세한 내용은 " OLM 1.0의 종속성 확인"을 참조하십시오.

추가 리소스

OLM 1.0의 종속성 확인

7.3.8.3. 버전 비교 문자열

Operator 또는 확장의 CR(사용자 정의 리소스)의 spec.version 필드에 비교 문자열을 추가하여 버전 범위를 정의할 수 있습니다. 비교 문자열은 공백 또는 쉼표로 구분된 값 목록과 큰따옴표(")로 묶인 하나 이상의 비교 연산자입니다. OR 또는 double vertical bar ( || ) 비교 연산자를 포함 하 여 다른 비교 문자열을 추가할 수 있습니다.You can add another comparison string by including an OR, or double vertical bar (||), comparison operator between the strings.

표 7.4. 기본 비교
비교 연산자	정의
`=`	동일
`!=`	같지 않음
`>`	보다 큼
`<`	보다 작음
`>=`	크거나 같음
`<=`	작거나 같음

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

버전 범위 비교 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: ">=1.11, <1.13"

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

표 7.5. 비교 문자열에 있는 와일드카드 문자의 예
와일드카드 비교	일치하는 문자열
`1.11.x`	`>=1.11.0, <1.12.0`
`>=1.12.X`	`>=1.12.0`
`<=2.x`	`<3`
`*`	`>=0.0.0`

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

표 7.6. 패치 릴리스 비교의 예
패치 릴리스 비교	일치하는 문자열
`~1.11.0`	`>=1.11.0, <1.12.0`
`~1`	`>=1, <2`
`~1.12`	`>=1.12, <1.13`
`~1.12.x`	`>=1.12.0, <1.13.0`
`~1.x`	`>=1, <2`

caret(^) 비교 연산자를 사용하여 주요 릴리스를 비교할 수 있습니다. 첫 번째 안정적인 릴리스가 게시되기 전에 주요 릴리스 비교를 사용하는 경우 마이너 버전은 API의 안정성 수준을 정의합니다. 의미 체계 버전 관리 (SemVer) 사양에서 첫 번째 안정적인 릴리스가 1.0.0 버전으로 게시됩니다.

표 7.7. 주요 릴리스 비교의 예
주요 릴리스 비교	일치하는 문자열
`^0`	`>=0.0.0, <1.0.0`
`^0.0`	`>=0.0.0, <0.1.0`
`^0.0.3`	`>=0.0.3, <0.0.4`
`^0.2`	`>=0.2.0, <0.3.0`
`^0.2.3`	`>=0.2.3, <0.3.0`
`^1.2.x`	`>= 1.2.0, < 2.0.0`
`^1.2.3`	`>= 1.2.3, < 2.0.0`
`^2.x`	`>= 2.0.0, < 3`
`^2.3`	`>= 2.3, < 3`

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

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

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

채널
버전 번호
버전 범위

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

지정된 채널이 있는 CR의 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  channel: latest 1

1: 지정된 채널에서 확인할 수 있는 최신 릴리스를 설치합니다. 채널 업데이트가 자동으로 설치됩니다.

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

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

대상 버전이 지정된 CR의 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: 1.11.1 1

1: 대상 버전을 지정합니다. 설치된 Operator 또는 확장 버전을 업데이트하려면 CR을 원하는 대상 버전으로 수동으로 업데이트해야 합니다.

Operator 또는 확장에 허용되는 다양한 버전을 정의하려면 비교 문자열을 사용하여 버전 범위를 지정할 수 있습니다. 버전 범위를 지정하면 OLM 1.0은 Operator 컨트롤러가 해결할 수 있는 Operator 또는 확장의 최신 버전을 설치합니다.

버전 범위가 지정된 CR의 예

apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: pipelines-operator
spec:
  packageName: openshift-pipelines-operator-rh
  version: >1.11.1 1

1: 원하는 버전 범위가 버전 1.11.1 보다 크도록 지정합니다. 자세한 내용은 "버전 범위 지원"을 참조하십시오.

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

명령 구문

$ oc apply -f <extension_name>.yaml

7.3.8.5. 업데이트 또는 롤백 강제 적용

OLM 1.0은 다음 주요 버전 또는 롤백에 대한 자동 업데이트를 이전 버전으로 지원하지 않습니다. 주요 버전 업데이트 또는 롤백을 수행하려면 수동으로 업데이트를 확인하고 강제 적용해야 합니다.

주의

수동 업데이트 또는 롤백을 강제 적용하는 결과를 확인해야 합니다. 강제 업데이트 또는 롤백을 확인하지 않으면 데이터 손실과 같은 심각한 결과가 발생할 수 있습니다.

사전 요구 사항

카탈로그가 설치되어 있어야 합니다.
Operator 또는 확장이 설치되어 있어야 합니다.

프로세스

다음 예와 같이 Operator 또는 확장의 CR(사용자 정의 리소스)을 편집합니다.
CR 예
```
apiVersion: olm.operatorframework.io/v1alpha1
kind: Operator
metadata:
  name: <operator_name> 1
spec:
  packageName: <package_name> 2
  version: <version> 3
  upgradeConstraintPolicy: Ignore 4
```
1
Operator 또는 확장의 이름(예: pipelines-operator)을 지정합니다.
2
openshift-pipelines-operator-rh 와 같은 패키지 이름을 지정합니다.
3
차단된 업데이트 또는 롤백 버전을 지정합니다.
4
선택 사항: 업그레이드 제약 조건 정책을 지정합니다. 업데이트 또는 롤백을 강제 적용하려면 필드를 Ignore 로 설정합니다. 지정되지 않은 경우 기본 설정은 Enforce 입니다.
다음 명령을 실행하여 Operator 또는 extensions CR에 변경 사항을 적용합니다.
```
$ oc apply -f <extension_name>.yaml
```

추가 리소스

버전 범위 지원

7.3.9. Operator 삭제

Operator의 CR(사용자 정의 리소스)을 삭제하여 Operator 및 해당 CRD(사용자 정의 리소스 정의)를 삭제할 수 있습니다.

사전 요구 사항

카탈로그가 설치되어 있어야 합니다.
Operator가 설치되어 있어야 합니다.

프로세스

다음 명령을 실행하여 Operator 및 해당 CRD를 삭제합니다.

$ oc delete operator.operators.operatorframework.io <operator_name>

출력 예

operator.operators.operatorframework.io "<operator_name>" deleted

검증

다음 명령을 실행하여 Operator 및 해당 리소스가 삭제되었는지 확인합니다.
- 다음 명령을 실행하여 Operator가 삭제되었는지 확인합니다.
```
$ oc get operator.operators.operatorframework.io
```
  출력 예
```
No resources found
```
- 다음 명령을 실행하여 Operator의 시스템 네임스페이스가 삭제되었는지 확인합니다.
```
$ oc get ns <operator_name>-system
```
  출력 예
```
Error from server (NotFound): namespaces "<operator_name>-system" not found
```

7.3.10. 카탈로그 삭제

CR(사용자 정의 리소스)을 삭제하여 카탈로그를 삭제할 수 있습니다.

사전 요구 사항

카탈로그가 설치되어 있어야 합니다.

프로세스

다음 명령을 실행하여 카탈로그를 삭제합니다.

$ oc delete catalog <catalog_name>

출력 예

catalog.catalogd.operatorframework.io "my-catalog" deleted

검증

다음 명령을 실행하여 카탈로그가 삭제되었는지 확인합니다.
```
$ oc get catalog
```

7.3. OLM 1.0의 카탈로그에서 Operator 설치 (기술 프리뷰)

7.3.1. 사전 요구 사항

7.3.2. OLM 1.0의 카탈로그 정보

7.3.3. OLM 1.0의 Red Hat 제공 Operator 카탈로그

7.3.4. 보안 레지스트리에서 호스팅되는 카탈로그의 풀 시크릿 생성

7.3.5. 클러스터에 카탈로그 추가

7.3.6. 카탈로그에서 설치할 Operator 찾기

7.3.6.1. 공통 카탈로그 쿼리

7.3.7. 카탈로그에서 Operator 설치

7.3.8. Operator 업데이트

7.3.8.1. 의미 체계 버전 관리 지원

7.3.8.1.1. 메이저 버전 제로 릴리스

7.3.8.2. 버전 범위 지원

7.3.8.3. 버전 비교 문자열

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

7.3.8.5. 업데이트 또는 롤백 강제 적용

7.3.9. Operator 삭제

7.3.10. 카탈로그 삭제

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

Red Hat 소개

Red Hat legal and privacy links

Red Hat legal and privacy links