Red Hat Summit Red Hat Summit지원콘솔개발자평가판 시작연락처

확장

OpenShift Container Platform 4.19

Operator Lifecycle Manager(OLM) v1을 사용하여 OpenShift Container Platform에서 확장 기능을 사용합니다.

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 확장 기능과 운영자를 설치, 관리, 구성하는 방법에 대한 정보를 제공합니다.

1장. 확장 개요
링크 복사

확장 기능을 사용하면 클러스터 관리자가 OpenShift Container Platform 클러스터의 사용자 기능을 확장할 수 있습니다.

Operator Lifecycle Manager(OLM)는 최초 릴리스부터 OpenShift Container Platform 4에 포함되었습니다. OpenShift Container Platform 4.19에는 OLM v1 이라는 이름으로 일반적으로 사용 가능한(GA) 기능으로서 차세대 OLM 반복을 위한 구성 요소가 포함되어 있습니다. 이 업데이트된 프레임워크는 이전 버전의 OLM에 포함되었던 많은 개념을 발전시키고 새로운 기능을 추가했습니다.

참고

OpenShift Container Platform 4.19의 경우 OLM v1에 대한 문서화된 절차는 CLI 기반입니다. 또는 관리자는 YAML 가져오기 및 검색 페이지와 같은 일반적인 방법을 사용하여 웹 콘솔에서 관련 객체를 만들고 볼 수 있습니다. 하지만 기존의 OperatorHub 및 설치된 운영자 페이지에는 아직 OLM v1 구성 요소가 표시되지 않습니다.

1.1. 하이라이트
링크 복사

관리자는 다음과 같은 주요 내용을 살펴볼 수 있습니다.

GitOps 워크플로를 지원하는 완전 선언적 모델

OLM v1은 다음 두 가지 주요 API를 통해 확장 관리를 간소화합니다.

  • 새로운 ClusterExtension API는 사용자 중심 API를 단일 객체로 통합하여 registry+v1 번들 형식을 통해 운영자를 포함한 설치된 확장 프로그램의 관리를 간소화합니다. 이 API는 새로운 Operator Controller 구성 요소에 의해 clusterextension.olm.operatorframework.io 로 제공됩니다. 관리자와 SRE는 API를 사용하여 GitOps 원칙을 적용하여 프로세스를 자동화하고 원하는 상태를 정의할 수 있습니다.

    참고

    OLM v1의 이전 기술 미리 보기 단계에서는 새로운 Operator API가 도입되었습니다. 이 API는 다음과 같은 개선 사항을 반영하여 OpenShift Container Platform 4.16에서 ClusterExtension 으로 이름이 변경되었습니다.

    • 클러스터의 기능을 확장하는 단순화된 기능을 보다 정확하게 반영합니다.
    • 더 유연한 패키징 형식을 더 잘 나타냅니다.
    • 클러스터 접두사는 ClusterExtension 개체가 클러스터 범위임을 명확히 나타냅니다. 이는 Operator가 네임스페이스 범위 또는 클러스터 범위일 수 있는 OLM(클래식)에서 변경된 것입니다.
  • 새로운 catalogd 구성 요소에서 제공하는 Catalog API는 OLM v1의 기반 역할을 하며, 클러스터 내 클라이언트에 대한 카탈로그를 압축 해제하여 사용자가 Kubernetes 확장 프로그램 및 Operators와 같은 설치 가능한 콘텐츠를 검색할 수 있도록 합니다. 이를 통해 사용 가능한 모든 Operator 번들 버전에 대한 가시성이 향상되며, 여기에는 세부 정보, 채널, 업데이트 에지가 포함됩니다.

자세한 내용은 운영자 컨트롤러 및 카탈로그를 참조하세요.

확장 업데이트에 대한 향상된 제어
카탈로그 콘텐츠에 대한 통찰력이 향상됨에 따라 관리자는 설치 및 업데이트를 위한 대상 버전을 지정할 수 있습니다. 이를 통해 관리자는 확장 업데이트의 대상 버전을 더 효과적으로 제어할 수 있습니다. 자세한 내용은 클러스터 확장 업데이트를 참조하세요.
유연한 확장 패키징 형식

관리자는 OLM(클래식) 환경과 유사하게 파일 기반 카탈로그를 사용하여 OLM 기반 운영자와 같은 확장 기능을 설치하고 관리할 수 있습니다.

또한, 번들 크기는 더 이상 etcd 값 크기 제한에 의해 제한되지 않습니다. 자세한 내용은 확장 기능 설치를 참조하세요.

보안 카탈로그 통신
OLM v1은 카탈로그화된 서버 응답에 HTTPS 암호화를 사용합니다.
프록시 환경 및 신뢰할 수 있는 CA 인증서에 대한 기본 지원
Operator Controller와 catalogd는 프록시 환경에서 실행될 수 있으며 신뢰할 수 있는 CA 인증서에 대한 기본 지원을 포함합니다.

1.2. 목적
링크 복사

Operator Lifecycle Manager(OLM)의 임무는 Kubernetes 클러스터에서 클러스터 확장의 수명 주기를 중앙에서 선언적으로 관리하는 것입니다. 그 목적은 항상 클러스터 및 PaaS(Platform-as-a-Service) 관리자가 기본 클러스터의 수명 주기 전반에 걸쳐 클러스터에 대한 기능 확장을 설치, 실행 및 업데이트하는 작업을 쉽고 안전하며 재현 가능하게 만드는 것이었습니다.

OpenShift Container Platform 4와 함께 출시되어 기본적으로 포함된 OLM의 초기 버전은 Operator라고 하는 특정 유형의 클러스터 확장에 대한 특정 요구 사항에 대한 고유한 지원을 제공하는 데 중점을 두었습니다. 운영자는 하나 이상의 Kubernetes 컨트롤러로 분류되며, 하나 이상의 API 확장 기능과 CustomResourceDefinition (CRD) 객체로 제공되어 클러스터에 추가 기능을 제공합니다.

여러 릴리스에서 프로덕션 클러스터에서 실행된 후, 차세대 OLM은 단순한 운영자가 아닌 클러스터 확장의 수명 주기를 포괄하는 것을 목표로 합니다.

2장. 아키텍처
링크 복사

2.1. OLM v1 구성 요소 개요
링크 복사

Operator Lifecycle Manager(OLM) v1은 다음과 같은 구성 요소 프로젝트로 구성됩니다.

운영자 컨트롤러
Operator Controller는 사용자가 Operator와 확장 프로그램의 수명 주기를 설치하고 관리할 수 있는 API를 통해 Kubernetes를 확장하는 OLM v1의 핵심 구성 요소입니다. catalogd에서 정보를 사용합니다.
카탈로그화됨
Catalogd는 클러스터 내 클라이언트에서 사용할 수 있도록 컨테이너 이미지로 패키징되어 전송된 파일 기반 카탈로그(FBC) 콘텐츠를 압축 해제하는 Kubernetes 확장 프로그램입니다. OLM v1 마이크로서비스 아키텍처의 구성 요소인 catalogd는 확장 프로그램 작성자가 패키징한 Kubernetes 확장 프로그램의 메타데이터를 호스팅하여 사용자가 설치 가능한 콘텐츠를 검색하는 데 도움을 줍니다.

2.2. 운영자 컨트롤러
링크 복사

Operator Controller는 Operator Lifecycle Manager(OLM) v1의 중심 구성 요소이며, 카탈로그된 다른 OLM v1 구성 요소를 사용합니다. 사용자가 연산자와 확장 기능을 설치할 수 있는 API를 통해 Kubernetes를 확장합니다.

2.2.1. ClusterExtension API
링크 복사

Operator Controller는 registry+v1 번들 형식을 통해 Operator를 포함하는, 설치된 확장 프로그램의 인스턴스를 나타내는 단일 리소스인 새로운 ClusterExtension API 객체를 제공합니다. 이 clusterextension.olm.operatorframework.io API는 사용자 중심 API를 단일 객체로 통합하여 설치된 확장 프로그램의 관리를 간소화합니다.

중요

OLM v1에서는 ClusterExtension 개체가 클러스터 범위입니다. 이는 OLM(클래식)과 다릅니다. OLM(클래식)의 경우 운영자는 관련 구독 및 운영자 그룹 개체의 구성에 따라 네임스페이스 범위나 클러스터 범위가 될 수 있습니다.

이전 동작에 대한 자세한 내용은 다중 테넌시 및 운영자 공동 배치를 참조하세요.

ClusterExtension 오브젝트의 예

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <extension_name>
spec:
  namespace: <namespace_name>
  serviceAccount:
    name: <service_account_name>
  source:
    sourceType: Catalog
    catalog:
      packageName: <package_name>
      channels:
        - <channel>
      version: "<version>"
Copy to Clipboard Toggle word wrap

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

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

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

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

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

지정된 채널이 있는 CR 예

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

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

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

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

대상 버전이 지정된 CR 예

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

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

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

버전 범위가 지정된 CR 예

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

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

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

명령 구문

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

2.2.2. 클러스터 확장에 대한 개체 소유권
링크 복사

Operator Lifecycle Manager(OLM) v1에서는 Kubernetes 객체는 한 번에 하나의 ClusterExtension 객체만 소유할 수 있습니다. 이를 통해 OpenShift Container Platform 클러스터 내의 개체가 일관되게 관리되고 동일한 개체를 제어하려는 여러 클러스터 확장 프로그램 간의 충돌이 방지됩니다.

2.2.2.1. 단일 소유권
링크 복사

OLM v1에서 적용되는 핵심 소유권 원칙은 각 개체가 소유자로서 하나의 클러스터 확장만 가질 수 있다는 것입니다. 이를 통해 여러 클러스터 확장에 의한 중복 또는 충돌하는 관리를 방지하고 각 개체가 단 하나의 번들과만 고유하게 연결되도록 보장합니다.

단일 소유권의 의미

  • CustomResourceDefinition (CRD) 객체를 제공하는 번들은 한 번만 설치할 수 있습니다.

    번들은 ClusterExtension 객체의 일부인 CRD를 제공합니다. 즉, 클러스터에 번들을 한 번만 설치할 수 있습니다. 동일한 CRD를 제공하는 다른 번들을 설치하려고 하면 실패하게 됩니다. 각 사용자 정의 리소스는 소유자로서 하나의 클러스터 확장만 가질 수 있기 때문입니다.

  • 클러스터 확장은 객체를 공유할 수 없습니다.

    OLM v1의 단일 소유자 정책은 클러스터 확장이 어떠한 개체의 소유권도 공유할 수 없음을 의미합니다. 하나의 클러스터 확장이 배포 , CustomResourceDefinition 또는 서비스 개체와 같은 특정 개체를 관리하는 경우 다른 클러스터 확장은 동일한 개체의 소유권을 주장할 수 없습니다. OLM v1은 이러한 시도를 차단합니다.

2.2.2.2. 오류 메시지
링크 복사

여러 클러스터 확장 프로그램이 동일한 객체를 관리하려고 시도하여 충돌이 발생하는 경우 Operator Controller는 다음과 같이 소유권 충돌을 나타내는 오류 메시지를 반환합니다.

오류 메시지의 예

CustomResourceDefinition 'logfilemetricexporters.logging.kubernetes.io' already exists in namespace 'kubernetes-logging' and cannot be managed by operator-controller
Copy to Clipboard Toggle word wrap

이 오류 메시지는 해당 개체가 이미 다른 클러스터 확장 프로그램에서 관리되고 있어 재할당 또는 공유할 수 없음을 나타냅니다.

2.2.2.3. 고려 사항
링크 복사

클러스터 또는 확장 관리자로서 다음 고려 사항을 검토하세요.

번들의 고유성
동일한 CRD를 제공하는 Operator 번들이 두 번 이상 설치되지 않도록 하세요. 이를 통해 소유권 분쟁으로 인한 잠재적인 설치 실패를 방지할 수 있습니다.
객체 공유를 피하세요
유사한 리소스와 상호 작용하기 위해 다른 클러스터 확장이 필요한 경우 별도의 오브젝트를 관리하고 있는지 확인하십시오. 단일 소유자 적용으로 인해 클러스터 확장은 동일한 객체를 공동으로 관리할 수 없습니다.

2.3. 카탈로그화됨
링크 복사

Operator Lifecycle Manager(OLM) v1은 catalogd 구성 요소와 해당 리소스를 사용하여 Operator 및 확장 카탈로그를 관리합니다.

2.3.1. OLM v1의 카탈로그에 관하여
링크 복사

catalogd 구성 요소를 사용하여 운영자 및 컨트롤러와 같은 Kubernetes 확장 기능에 대한 카탈로그를 쿼리하여 설치 가능한 콘텐츠를 검색할 수 있습니다. Catalogd는 클러스터 내 클라이언트를 위한 카탈로그 콘텐츠를 압축 해제하는 Kubernetes 확장 프로그램으로, Operator Lifecycle Manager(OLM) v1 마이크로서비스 제품군의 일부입니다. 현재 catalogd는 컨테이너 이미지로 패키징되어 배포되는 카탈로그 콘텐츠를 압축 해제합니다.

3장. Operator 프레임워크 일반 용어집
링크 복사

다음 용어는 Operator Lifecycle Manager(OLM) v1을 포함한 Operator Framework와 관련이 있습니다.

3.1. 번들
링크 복사

번들 형식에서 번들은 Operator CSV, 매니페스트, 메타데이터로 이루어진 컬렉션입니다. 이러한 구성 요소가 모여 클러스터에 설치할 수 있는 고유한 버전의 Operator를 형성합니다.

3.2. 번들 이미지
링크 복사

번들 형식에서 번들 이미지는 Operator 매니페스트에서 빌드하고 하나의 번들을 포함하는 컨테이너 이미지입니다. 번들 이미지는 Quay.io 또는 DockerHub와 같은 OCI(Open Container Initiative) 사양 컨테이너 레지스트리에서 저장 및 배포합니다.

3.3. 카탈로그 소스
링크 복사

카탈로그 소스는 OLM이 운영자와 해당 종속성을 검색하고 설치하기 위해 쿼리할 수 있는 메타데이터 저장소를 나타냅니다.

3.4. 채널
링크 복사

채널은 Operator의 업데이트 스트림을 정의하고 구독자에게 업데이트를 배포하는 데 사용됩니다. 헤드는 해당 채널의 최신 버전을 가리킵니다. 예를 들어 stable 채널에는 Operator의 모든 안정적인 버전이 가장 오래된 것부터 최신 순으로 정렬되어 있습니다.

Operator에는 여러 개의 채널이 있을 수 있으며 특정 채널에 대한 서브스크립션 바인딩에서는 해당 채널의 업데이트만 찾습니다.

3.5. 채널 헤드
링크 복사

채널 헤드는 알려진 특정 채널의 최신 업데이트를 나타냅니다.

3.6. 클러스터 서비스 버전
링크 복사

CSV(클러스터 서비스 버전)는 Operator 메타데이터에서 생성하는 YAML 매니페스트로, OLM이 클러스터에서 Operator를 실행하는 것을 지원합니다. 로고, 설명, 버전과 같은 정보로 사용자 인터페이스를 채우는 데 사용되는 Operator 컨테이너 이미지와 함께 제공되는 메타데이터입니다.

또한 필요한 RBAC 규칙 및 관리하거나 사용하는 CR(사용자 정의 리소스)과 같이 Operator를 실행하는 데 필요한 기술 정보의 소스이기도 합니다.

3.7. 종속성
링크 복사

Operator는 클러스터에 있는 다른 Operator에 종속되어 있을 수 있습니다. 예를 들어 Vault Operator는 데이터 지속성 계층과 관련하여 etcd Operator에 종속됩니다.

OLM은 설치 단계 동안 지정된 모든 버전의 Operator 및 CRD가 클러스터에 설치되도록 하여 종속 항목을 해결합니다. 이러한 종속성은 필수 CRD API를 충족하고 패키지 또는 번들과 관련이 없는 카탈로그에서 Operator를 찾아 설치함으로써 해결할 수 있습니다.

3.8. 확장
링크 복사

확장 기능을 사용하면 클러스터 관리자가 OpenShift Container Platform 클러스터의 사용자 기능을 확장할 수 있습니다. 확장 기능은 OLM(Operator Lifecycle Manager) v1에서 관리됩니다.

ClusterExtension API는 사용자 중심 API를 단일 객체로 통합하여 registry+v1 번들 형식을 통해 운영자를 포함한 설치된 확장 프로그램의 관리를 간소화합니다. 관리자와 SRE는 API를 사용하여 GitOps 원칙을 적용하여 프로세스를 자동화하고 원하는 상태를 정의할 수 있습니다.

3.9. 인덱스 이미지
링크 복사

번들 형식에서 인덱스 이미지는 모든 버전의 CSV 및 CRD를 포함하여 Operator 번들에 대한 정보를 포함하는 데이터베이스 이미지(데이터베이스 스냅샷)를 나타냅니다. 이 인덱스는 클러스터에서 Operator 기록을 호스팅하고 opm CLI 툴을 사용하여 Operator를 추가하거나 제거하는 방식으로 유지 관리할 수 있습니다.

3.10. 설치 계획
링크 복사

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

3.11. 멀티테넌시
링크 복사

OpenShift Container Platform의 테넌트 는 배포된 워크로드 세트에 대한 공통 액세스 및 권한을 공유하는 사용자 또는 사용자 그룹으로, 일반적으로 네임스페이스 또는 프로젝트로 표현됩니다. 테넌트를 사용하면 서로 다른 그룹이나 팀 간에 일정 수준의 격리를 제공할 수 있습니다.

여러 사용자나 그룹이 클러스터를 공유하는 경우 멀티테넌트 클러스터로 간주됩니다.

3.12. Operator
링크 복사

Operator는 Kubernetes 애플리케이션을 패키징, 배포 및 관리하는 방법입니다. Kubernetes 애플리케이션은 Kubernetes API 및 kubectl 또는 oc 툴링을 사용하여 Kubernetes API에 배포하고 관리하는 앱입니다.

Operator Lifecycle Manager(OLM) v1에서 ClusterExtension API는 레지스트리+v1 번들 형식을 통해 Operator를 포함한 설치된 확장 프로그램의 관리를 간소화합니다.

3.13. Operator group
링크 복사

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

3.14. 패키지
링크 복사

번들 형식에서 패키지는 각 버전과 함께 Operator의 모든 릴리스 내역을 포함하는 디렉터리입니다. 릴리스된 Operator 버전은 CRD와 함께 CSV 매니페스트에 설명되어 있습니다.

3.15. 레지스트리
링크 복사

레지스트리는 각각 모든 채널의 최신 버전 및 이전 버전이 모두 포함된 Operator의 번들 이미지를 저장하는 데이터베이스입니다.

3.16. Subscription
링크 복사

서브스크립션은 패키지의 채널을 추적하여 CSV를 최신 상태로 유지합니다.

3.17. 업데이트 그래프
링크 복사

업데이트 그래프는 패키지된 다른 소프트웨어의 업데이트 그래프와 유사하게 CSV 버전을 함께 연결합니다. Operator를 순서대로 설치하거나 특정 버전을 건너뛸 수 있습니다. 업데이트 그래프는 최신 버전이 추가됨에 따라 앞부분에서만 증가할 것으로 예상됩니다.

update edges 또는 update paths라고도 합니다.

4장. 카탈로그
링크 복사

4.1. 파일 기반 카탈로그
링크 복사

OpenShift Container Platform의 Operator Lifecycle Manager(OLM) v1은 클러스터에서 Operator를 포함한 클러스터 확장을 검색하고 소싱하기 위한 파일 기반 카탈로그를 지원합니다.

4.1.1. 하이라이트
링크 복사

파일 기반 카탈로그는 OLM(Operator Lifecycle Manager) 카탈로그 형식의 최신 버전입니다. 일반 텍스트 기반(JSON 또는 YAML)과 이전 SQLite 데이터베이스 형식의 선언적 구성 진화이며 완전히 이전 버전과 호환됩니다. 이 형식의 목표는 Operator 카탈로그 편집, 구성 가능성 및 확장성을 활성화하는 것입니다.

편집

파일 기반 카탈로그를 사용하면 카탈로그 내용과 상호 작용하는 사용자가 형식을 직접 변경하고 변경 사항이 유효한지 확인할 수 있습니다. 이 형식은 일반 텍스트 JSON 또는 YAML이므로 카탈로그 유지 관리자는 jq CLI와 같이 널리 알려진 지원되는 JSON 또는 YAML 툴을 사용하여 카탈로그 메타데이터를 쉽게 조작할 수 있습니다.

이 편집 기능을 사용하면 다음과 같은 기능 및 사용자 정의 확장 기능을 사용할 수 있습니다.

  • 기존 번들을 새 채널로 승격
  • 패키지의 기본 채널 변경
  • 업그레이드 경로 추가, 업데이트 및 제거를 위한 사용자 정의 알고리즘
호환성

파일 기반 카탈로그는 카탈로그 구성이 가능한 임의의 디렉터리 계층 구조에 저장됩니다. 예를 들어 별도의 파일 기반 카탈로그 디렉터리인 catalogA 및 catalogB를 고려해 보십시오. 카탈로그 관리자는 새 디렉토리 catalogC를 만들고 catalogA 및 catalogB를 복사하여 새로 결합된 카탈로그를 만들 수 있습니다.

이 구성 가능성을 통해 분산된 카탈로그를 사용할 수 있습니다. 이 형식을 사용하면 Operator 작성자가 Operator별 카탈로그를 유지 관리할 수 있으며 유지 관리자가 개별 Operator 카탈로그로 구성된 카탈로그를 단순하게 빌드할 수 있습니다. 파일 기반 카탈로그는 하나의 카탈로그의 하위 집합을 추출하거나 두 개의 카탈로그를 조합하여 다른 여러 카탈로그를 결합하여 구성할 수 있습니다.

참고

패키지 내의 중복 패키지 및 중복 번들은 허용되지 않습니다. opm validate 명령은 중복이 발견되면 오류를 반환합니다.

Operator 작성자는 Operator, 해당 종속 항목 및 업그레이드 호환성에 가장 익숙하므로 자체 Operator별 카탈로그를 유지 관리하고 해당 콘텐츠를 직접 제어할 수 있습니다. Operator 작성자는 파일 기반 카탈로그를 사용하여 카탈로그에서 패키지를 빌드하고 유지 관리하는 작업을 소유합니다. 그러나 복합 카탈로그 유지 관리자만 카탈로그의 패키지를 큐레이션하고 카탈로그를 사용자에게 게시하는 작업만 소유합니다.

확장성

파일 기반 카탈로그 사양은 카탈로그의 하위 수준 형식입니다. 카탈로그 유지 관리자는 낮은 수준의 형식으로 직접 유지 관리할 수 있지만, 카탈로그 유지 관리자는 고유한 사용자 지정 툴링에서 원하는 수의 변경을 수행할 수 있는 확장 기능을 구축할 수 있습니다.

예를 들어, 도구는 (mode=semver) 와 같은 고수준 API를 업그레이드 경로를 위한 저수준 파일 기반 카탈로그 형식으로 변환할 수 있습니다. 또는 카탈로그 유지 관리자는 특정 기준을 충족하는 번들에 새 속성을 추가하여 모든 번들 메타데이터를 사용자 지정해야 할 수 있습니다.

이러한 확장성을 통해 향후 OpenShift Container Platform 릴리스를 위해 하위 수준 API에서 추가 공식 툴을 개발할 수 있지만, 카탈로그 유지 관리자도 이러한 기능을 사용할 수 있다는 것이 가장 큰 장점입니다.

4.1.2. 디렉토리 구조
링크 복사

디렉토리 기반 파일 시스템에서 파일 기반 카탈로그를 저장하고 로드할 수 있습니다. opm CLI는 루트 디렉토리로 이동하고 하위 디렉토리로 재귀하여 카탈로그를 로드합니다. CLI는 발견한 모든 파일을 로드 시도하여 오류가 발생하면 실패합니다.

비카탈로그 파일은 .gitignore 파일과 패턴 및 우선 순위에 대해 동일한 규칙이 있는 .indexignore 파일을 사용하여 무시할 수 있습니다.

.indexignore 파일의 예

# Ignore everything except non-object .json and .yaml files
**/*
!*.json
!*.yaml
**/objects/*.json
**/objects/*.yaml
Copy to Clipboard Toggle word wrap

카탈로그 유지 관리자는 원하는 레이아웃을 선택할 수 있는 유연성을 가지지만 각 패키지의 파일 기반 카탈로그 Blob을 별도의 하위 디렉터리에 저장하는 것이 좋습니다. 각 개별 파일은 JSON 또는 YAML일 수 있습니다. 카탈로그의 모든 파일에서 동일한 형식을 사용할 필요는 없습니다.

기본 권장 구조

catalog
├── packageA
│   └── index.yaml
├── packageB
│   ├── .indexignore
│   ├── index.yaml
│   └── objects
│       └── packageB.v0.1.0.clusterserviceversion.yaml
└── packageC
    └── index.json
    └── deprecations.yaml
Copy to Clipboard Toggle word wrap

이 권장 구조에는 디렉터리 계층 구조의 각 하위 디렉터리가 자체 포함된 카탈로그이므로 카탈로그 구성, 검색 및 탐색 간단한 파일 시스템 작업이 가능합니다. 카탈로그를 부모 카탈로그의 루트 디렉토리에 복사하여 부모 카탈로그에 포함할 수도 있습니다.

4.1.3. 스키마
링크 복사

파일 기반 카탈로그는 임의의 스키마로 확장할 수 있는 CUE 언어 사양을 기반으로 하는 형식을 사용합니다. 다음 _Meta CUE 스키마는 모든 파일 기반 카탈로그 Blob이 준수해야 하는 형식을 정의합니다.

_Meta 스키마

_Meta: {
  // schema is required and must be a non-empty string
  schema: string & !=""

  // package is optional, but if it's defined, it must be a non-empty string
  package?: string & !=""

  // properties is optional, but if it's defined, it must be a list of 0 or more properties
  properties?: [... #Property]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}
Copy to Clipboard Toggle word wrap

참고

이 사양에 나열된 CUE 스키마는 완전한 것으로 간주되어서는 안 됩니다. opm validate 명령에는 CUE에서 간결하게 표현하기가 어렵거나 불가능한 추가 유효성 검사가 있습니다.

OLM(Operator Lifecycle Manager) 카탈로그에서는 현재 OLM의 기존 패키지 및 번들 개념에 해당하는 3개의 스키마 (olm.package, olm.channel, olm.bundle)를 사용합니다.

카탈로그의 각 Operator 패키지에는 정확히 하나의 olm.package blob, 하나 이상의 olm.channel blob, 하나 이상의 olm.bundle blob이 필요합니다.

참고

모든 olm.* 스키마는 OLM 정의 스키마용으로 예약됩니다. 사용자 지정 스키마는 소유한 도메인과 같이 고유한 접두사를 사용해야 합니다.

4.1.3.1. olm.package 스키마
링크 복사

olm.package 스키마는 Operator에 대한 패키지 수준 메타데이터를 정의합니다. 이에는 이름, 설명, 기본 채널 및 아이콘이 포함됩니다.

예 4.1. olm.package 스키마

#Package: {
  schema: "olm.package"

  // Package name
  name: string & !=""

  // A description of the package
  description?: string

  // The package's default channel
  defaultChannel: string & !=""

  // An optional icon
  icon?: {
    base64data: string
    mediatype:  string
  }
}
Copy to Clipboard Toggle word wrap
4.1.3.2. olm.channel 스키마
링크 복사

olm.channel 스키마는 패키지 내의 채널, 채널의 멤버인 번들 항목, 해당 번들의 업그레이드 경로를 정의합니다.

번들 항목이 여러 olm.channel 블롭의 에지를 나타내는 경우 채널당 한 번만 나타날 수 있습니다.

이 카탈로그나 다른 카탈로그에서 찾을 수 없는 다른 번들 이름을 참조하는 항목의 replaces 값은 유효합니다. 그러나 여러 헤드가 없는 채널과 같이 다른 모든 채널 불변성은 true를 유지해야 합니다.

예 4.2. olm.channel 스키마

#Channel: {
  schema: "olm.channel"
  package: string & !=""
  name: string & !=""
  entries: [...#ChannelEntry]
}

#ChannelEntry: {
  // name is required. It is the name of an `olm.bundle` that
  // is present in the channel.
  name: string & !=""

  // replaces is optional. It is the name of bundle that is replaced
  // by this entry. It does not have to be present in the entry list.
  replaces?: string & !=""

  // skips is optional. It is a list of bundle names that are skipped by
  // this entry. The skipped bundles do not have to be present in the
  // entry list.
  skips?: [...string & !=""]

  // skipRange is optional. It is the semver range of bundle versions
  // that are skipped by this entry.
  skipRange?: string & !=""
}
Copy to Clipboard Toggle word wrap
주의

skipRange 필드를 사용하면 건너뛴 연산자 버전이 업데이트 그래프에서 제거되고 더 이상 Subscription 개체의 spec.startingCSV 속성을 사용하여 사용자가 설치할 수 없습니다.

skipRange 필드와 replaces 필드를 모두 사용하면 이전에 설치된 버전을 사용자가 나중에 설치할 수 있도록 유지하면서 연산자를 증분적으로 업데이트할 수 있습니다. replaces 필드가 해당 Operator 버전의 바로 이전 버전을 가리키는지 확인하세요.

4.1.3.3. olm.bundle 스키마
링크 복사

예 4.3. olm.bundle 스키마

#Bundle: {
  schema: "olm.bundle"
  package: string & !=""
  name: string & !=""
  image: string & !=""
  properties: [...#Property]
  relatedImages?: [...#RelatedImage]
}

#Property: {
  // type is required
  type: string & !=""

  // value is required, and it must not be null
  value: !=null
}

#RelatedImage: {
  // image is the image reference
  image: string & !=""

  // name is an optional descriptive name for an image that
  // helps identify its purpose in the context of the bundle
  name?: string & !=""
}
Copy to Clipboard Toggle word wrap
4.1.3.4. olm.deprecations 스키마
링크 복사

선택적인 olm.deprecations 스키마는 카탈로그의 패키지, 번들 및 채널에 대한 사용 중단 정보를 정의합니다. 운영자 작성자는 이 스키마를 사용하여 카탈로그에서 해당 운영자를 실행하는 사용자에게 지원 상태 및 권장 업그레이드 경로와 같은 운영자에 대한 관련 메시지를 제공할 수 있습니다.

이 스키마가 정의되면 OpenShift Container Platform 웹 콘솔은 OperatorHub의 설치 전 및 설치 후 페이지 모두에 사용자 정의 사용 중단 메시지를 포함하여 해당 Operator의 영향을 받는 요소에 대한 경고 배지를 표시합니다.

olm.deprecations 스키마 항목에는 다음 참조 유형 중 하나 이상이 포함되어 있으며, 이는 사용 중단 범위를 나타냅니다. Operator가 설치된 후에는 지정된 모든 메시지를 관련 구독 개체의 상태 조건으로 볼 수 있습니다.

Expand
표 4.1. 사용 중단 reference 유형
유형범위상태 조건

olm.package

전체 패키지를 나타냅니다

PackageDeprecated

olm.channel

하나의 채널을 나타냅니다

ChannelDeprecated

olm.bundle

하나의 번들 버전을 나타냅니다

BundleDeprecated

다음 예시에서 자세히 설명되어 있듯이 각 참조 유형에는 고유한 요구 사항이 있습니다.

예 4.4. 각 참조 유형이 포함된 olm.deprecations 스키마 예시

schema: olm.deprecations
package: my-operator
1 

entries:
  - reference:
      schema: olm.package
2 

    message: |
3 

    The 'my-operator' package is end of life. Please use the
    'my-operator-new' package for support.
  - reference:
      schema: olm.channel
      name: alpha
4 

    message: |
    The 'alpha' channel is no longer supported. Please switch to the
    'stable' channel.
  - reference:
      schema: olm.bundle
      name: my-operator.v1.68.0
5 

    message: |
    my-operator.v1.68.0 is deprecated. Uninstall my-operator.v1.68.0 and
    install my-operator.v1.72.0 for support.
Copy to Clipboard Toggle word wrap
1
각 사용 중단 스키마에는 패키지 값이 있어야 하며, 해당 패키지 참조는 카탈로그 전체에서 고유해야 합니다. 연관된 이름 필드가 없어야 합니다.
2
olm.package 스키마에는 이름 필드가 포함되어서는 안 됩니다. 이름 필드는 스키마에서 앞서 정의한 패키지 필드에 의해 결정되기 때문입니다.
3
모든 참조 유형에 관계없이 모든 message 필드는길이가 0이 아닌 불투명한 텍스트 블롭(opaque text blob)으로 표현되어야 합니다.
4
olm.channel 스키마의 이름 필드는 필수입니다.
5
olm.bundle 스키마의 이름 필드는 필수입니다.
참고

사용 중단 기능은 중복되는 사용 중단(예: 패키지 대 채널 대 번들)을 고려하지 않습니다.

운영자 작성자는 olm.deprecations 스키마 항목을 패키지의 index.yaml 파일과 같은 디렉토리에 deprecations.yaml 파일로 저장할 수 있습니다.

더 이상 사용되지 않는 카탈로그의 디렉토리 구조 예

my-catalog
└── my-operator
    ├── index.yaml
    └── deprecations.yaml
Copy to Clipboard Toggle word wrap

4.1.4. 속성
링크 복사

속성은 파일 기반 카탈로그 스키마에 연결할 수 있는 임의 메타데이터입니다. type 필드는 value 필드의 의미 및 구문 의미를 효과적으로 지정하는 문자열입니다. 이 값은 임의의 JSON 또는 YAML일 수 있습니다.

OLM은 예약된 olm.* 접두사를 사용하여 몇 가지 속성 유형을 다시 정의합니다.

4.1.4.1. olm.package 속성
링크 복사

olm.package 속성은 패키지 이름과 버전을 정의합니다. 이는 번들의 필수 속성이며, 이러한 속성 중 정확히 하나가 있어야 합니다. packageName 필드는 번들의 최상위 package 필드와 일치해야 하며 version 필드는 유효한 의미 체계 버전이어야 합니다.

예 4.5. olm.package 속성

#PropertyPackage: {
  type: "olm.package"
  value: {
    packageName: string & !=""
    version: string & !=""
  }
}
Copy to Clipboard Toggle word wrap
4.1.4.2. olm.gvk 속성
링크 복사

olm.gvk 속성은 이 번들에서 제공하는 Kubernetes API의 GVK(그룹/버전/종류)를 정의합니다. 이 속성은 OLM에서 이 속성이 포함된 번들을 필수 API와 동일한 GVK를 나열하는 다른 번들의 종속성으로 확인하는 데 사용됩니다. GVK는 Kubernetes GVK 검증을 준수해야 합니다.

예 4.6. olm.gvk 속성

#PropertyGVK: {
  type: "olm.gvk"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}
Copy to Clipboard Toggle word wrap
4.1.4.3. olm.package.required
링크 복사

olm.package.required 속성은 이 번들에 필요한 다른 패키지의 패키지 이름 및 버전 범위를 정의합니다. 번들 목록이 필요한 모든 패키지 속성에 대해 OLM은 나열된 패키지 및 필수 버전 범위에 대한 클러스터에 Operator가 설치되어 있는지 확인합니다. versionRange 필드는 유효한 의미 버전(semver) 범위여야 합니다.

예 4.7. olm.package.required 속성

#PropertyPackageRequired: {
  type: "olm.package.required"
  value: {
    packageName: string & !=""
    versionRange: string & !=""
  }
}
Copy to Clipboard Toggle word wrap
4.1.4.4. olm.gvk.required
링크 복사

olm.gvk.required 속성은 이 번들에 필요한 Kubernetes API의 GVK(그룹/버전/종류)를 정의합니다. 번들 목록이 필요한 모든 GVK 속성에 대해 OLM은 이를 제공하는 클러스터에 Operator가 설치되어 있는지 확인합니다. GVK는 Kubernetes GVK 검증을 준수해야 합니다.

예 4.8. olm.gvk.required 속성

#PropertyGVKRequired: {
  type: "olm.gvk.required"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}
Copy to Clipboard Toggle word wrap

4.1.5. 카탈로그의 예
링크 복사

파일 기반 카탈로그를 사용하면 카탈로그 유지 관리자가 Operator 큐레이션 및 호환성에 중점을 둘 수 있습니다. Operator 작성자는 Operator에 대한 Operator별 카탈로그를 이미 생성했기 때문에 카탈로그 유지 관리자는 각 Operator 카탈로그를 카탈로그의 루트 디렉터리의 하위 디렉터리에 렌더링하여 카탈로그를 빌드할 수 있습니다.

파일 기반 카탈로그를 구축하는 방법은 여러 가지가 있습니다. 다음 단계에서는 간단한 접근 방식을 간략하게 설명합니다.

  1. 카탈로그의 각 Operator에 대한 이미지 참조가 포함된 카탈로그의 단일 구성 파일을 유지 관리합니다.

    카탈로그 구성 파일 예

    name: community-operators
repo: quay.io/community-operators/catalog
tag: latest
references:
- name: etcd-operator
  image: quay.io/etcd-operator/index@sha256:5891b5b522d5df086d0ff0b110fbd9d21bb4fc7163af34d08286a2e846f6be03
- name: prometheus-operator
  image: quay.io/prometheus-operator/index@sha256:e258d248fda94c63753607f7c4494ee0fcbe92f1a76bfdac795c9d84101eb317
    Copy to Clipboard Toggle word wrap

  2. 구성 파일을 구문 분석하고 참조에서 새 카탈로그를 생성하는 스크립트를 실행합니다.

    스크립트 예

    name=$(yq eval '.name' catalog.yaml)
mkdir "$name"
yq eval '.name + "/" + .references[].name' catalog.yaml | xargs mkdir
for l in $(yq e '.name as $catalog | .references[] | .image + "|" + $catalog + "/" + .name + "/index.yaml"' catalog.yaml); do
  image=$(echo $l | cut -d'|' -f1)
  file=$(echo $l | cut -d'|' -f2)
  opm render "$image" > "$file"
done
opm generate dockerfile "$name"
indexImage=$(yq eval '.repo + ":" + .tag' catalog.yaml)
docker build -t "$indexImage" -f "$name.Dockerfile" .
docker push "$indexImage"
    Copy to Clipboard Toggle word wrap

4.1.6. 지침
링크 복사

파일 기반 카탈로그를 유지 관리할 때 다음 지침을 고려하십시오.

4.1.6.1. 변경할 수 없는 번들
링크 복사

OLM(Operator Lifecycle Manager)의 일반적인 지침은 번들 이미지 및 해당 메타데이터를 변경할 수 없음으로 간주해야 한다는 것입니다.

손상된 번들이 카탈로그로 푸시된 경우 사용자 중 한 명이 해당 번들로 업그레이드되었다고 가정해야 합니다. 이러한 가정에 따라 손상된 번들을 설치한 사용자가 업그레이드를 받을 수 있도록 손상된 번들에서 업그레이드 경로가 포함된 다른 번들을 출시해야 합니다. 해당 번들의 콘텐츠가 카탈로그에서 업데이트되는 경우 OLM은 설치된 번들을 다시 설치하지 않습니다.

그러나 카탈로그 메타데이터의 변경이 권장되는 몇 가지 사례가 있습니다.

  • 채널 승격: 번들을 이미 릴리스하고 나중에 다른 채널에 추가할 것을 결정한 경우, 다른 olm.channel blob에 번들에 대한 항목을 추가할 수 있습니다.
  • 새로운 업그레이드 경로: 예를 들어 1.2.4 와 같이 새로운 1.2.z 번들 버전을 출시했지만 이미 1.3.0이 출시된 경우 1.3.0 의 카탈로그 메타데이터를 업데이트하여 1.2.4를 건너뛸 수 있습니다.
4.1.6.2. 소스 제어
링크 복사

카탈로그 메타데이터는 소스 제어에 저장되고 정보 소스로 처리되어야 합니다. 카탈로그 이미지 업데이트에는 다음 단계가 포함되어야 합니다.

  1. 소스 제어 카탈로그 디렉터리를 새 커밋으로 업데이트합니다.
  2. 카탈로그 이미지를 빌드하고 내보냅니다. 사용자가 사용 가능하게 되면 카탈로그 업데이트를 수신할 수 있도록 :latest 또는 :<target_cluster_version>과 같은 일관된 태그 지정 용어를 사용합니다.

4.1.7. CLI 사용
링크 복사

opm CLI를 사용하여 파일 기반 카탈로그를 만드는 방법에 대한 지침은 사용자 정의 카탈로그 관리를 참조하세요.

파일 기반 카탈로그 관리와 관련된 opm CLI 명령에 대한 참조 문서는 CLI 도구를 참조하세요.

4.1.8. 자동화
링크 복사

Operator 작성자 및 카탈로그 유지 관리자는 CI/CD 워크플로를 사용하여 카탈로그 유지 관리를 자동화하는 것이 좋습니다. 카탈로그 유지 관리자는 다음 작업을 수행하도록 GitOps 자동화를 빌드하여 이 작업을 추가로 개선할 수 있습니다.

  • 예를 들어 패키지의 이미지 참조를 업데이트하여 해당 PR(pull request) 작성자가 요청된 변경을 수행할 수 있는지 확인합니다.
  • 카탈로그 업데이트가 opm validate 명령을 전달하는지 확인합니다.
  • 업데이트된 번들 또는 카탈로그 이미지 참조가 있는지, 카탈로그 이미지가 클러스터에서 성공적으로 실행되며 해당 패키지의 Operator가 성공적으로 설치될 수 있는지 확인합니다.
  • 이전 검사를 통과하는 PR을 자동으로 병합합니다.
  • 카탈로그 이미지를 자동으로 다시 빌드하고 다시 게시합니다.

4.2. Red Hat에서 제공하는 카탈로그
링크 복사

Red Hat은 기본적으로 OpenShift Container Platform에 포함된 여러 가지 Operator 카탈로그를 제공합니다.

4.2.1. Red Hat 제공 Operator 카탈로그 정보
링크 복사

Red Hat에서 제공하는 카탈로그 소스는 기본적으로 openshift-marketplace 네임스페이스에 설치되므로 모든 네임스페이스의 클러스터 전체에서 카탈로그를 사용할 수 있습니다.

다음은 Red Hat에서 제공하는 Operator 카탈로그입니다.

Expand
카탈로그인덱스 이미지설명

redhat-operators

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

Red Hat에서 Red Hat 제품을 패키지 및 제공합니다. Red Hat에서 지원합니다.

certified-operators

registry.redhat.io/redhat/certified-operator-index:v4.19

선도적인 ISV(독립 소프트웨어 벤더)의 제품입니다. Red Hat은 패키지 및 제공을 위해 ISV와 협력합니다. ISV에서 지원합니다.

community-operators

registry.redhat.io/redhat/community-operator-index:v4.19

redhat-openshift-ecosystem/community-operators-prod/operators GitHub 저장소에서 관련 담당자가 유지 관리하는 소프트웨어입니다. 공식적으로 지원되지 않습니다.

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

registry.redhat.io/redhat/redhat-operator-index:v4.8
Copy to Clipboard Toggle word wrap

다음으로 변경합니다. 

registry.redhat.io/redhat/redhat-operator-index:v4.9
Copy to Clipboard Toggle word wrap

4.3. 카탈로그 관리
링크 복사

클러스터 관리자는 카탈로그 나 운영자 및 Kubernetes 확장 프로그램의 큐레이션된 컬렉션을 클러스터에 추가할 수 있습니다. 운영자 작성자는 이러한 카탈로그에 자신의 제품을 게시합니다. 클러스터에 카탈로그를 추가하면 카탈로그에 게시된 Operator와 확장 프로그램의 버전, 패치, 무선 업데이트에 액세스할 수 있습니다.

사용자 정의 리소스(CR)를 사용하여 CLI에서 카탈로그와 확장을 선언적으로 관리할 수 있습니다.

파일 기반 카탈로그는 OLM(Operator Lifecycle Manager) 카탈로그 형식의 최신 버전입니다. 일반 텍스트 기반(JSON 또는 YAML)과 이전 SQLite 데이터베이스 형식의 선언적 구성 진화이며 완전히 이전 버전과 호환됩니다.

중요

Kubernetes는 후속 릴리스에서 제거된 특정 API를 주기적으로 사용하지 않습니다. 결과적으로 Operator는 API를 제거한 Kubernetes 버전을 사용하는 OpenShift Container Platform 버전에서 시작하여 제거된 API를 사용할 수 없습니다.

4.3.1. OLM v1의 카탈로그에 관하여
링크 복사

catalogd 구성 요소를 사용하여 운영자 및 컨트롤러와 같은 Kubernetes 확장 기능에 대한 카탈로그를 쿼리하여 설치 가능한 콘텐츠를 검색할 수 있습니다. Catalogd는 클러스터 내 클라이언트를 위한 카탈로그 콘텐츠를 압축 해제하는 Kubernetes 확장 프로그램으로, Operator Lifecycle Manager(OLM) v1 마이크로서비스 제품군의 일부입니다. 현재 catalogd는 컨테이너 이미지로 패키징되어 배포되는 카탈로그 콘텐츠를 압축 해제합니다.

4.3.2. OLM v1의 Red Hat 제공 운영자 카탈로그
링크 복사

Operator Lifecycle Manager(OLM) v1에는 기본적으로 클러스터에 다음과 같은 Red Hat 제공 Operator 카탈로그가 포함되어 있습니다. 클러스터에 추가 카탈로그를 추가하려면 카탈로그에 대한 사용자 지정 리소스(CR)를 만들고 클러스터에 적용합니다. 다음 사용자 정의 리소스(CR) 예제는 클러스터에 설치된 기본 카탈로그를 보여줍니다.

Red Hat Operators 카탈로그

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: openshift-redhat-operators
spec:
  priority: -100
  source:
    image:
      pollIntervalMinutes: <poll_interval_duration>
1 

      ref: registry.redhat.io/redhat/redhat-operator-index:v4.19
    type: Image
Copy to Clipboard Toggle word wrap

1
최신 이미지 다이제스트에 대한 원격 레지스트리 폴링 간격을 분 단위로 지정합니다. 폴링을 비활성화하려면 필드를 설정하지 마세요.

인증된 운영자 카탈로그

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: openshift-certified-operators
spec:
priority: -200
  source:
    type: image
    image:
      pollIntervalMinutes: 10
      ref: registry.redhat.io/redhat/certified-operator-index:v4.19
    type: Image
Copy to Clipboard Toggle word wrap

Red Hat Marketplace 카탈로그

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: openshift-redhat-marketplace
spec:
  priority: -300
  source:
    image:
      pollIntervalMinutes: 10
      ref: registry.redhat.io/redhat/redhat-marketplace-index:v4.19
    type: Image
Copy to Clipboard Toggle word wrap

커뮤니티 운영자 카탈로그

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: openshift-community-operators
spec:
  priority: -400
  source:
    image:
      pollIntervalMinutes: 10
      ref: registry.redhat.io/redhat/community-operator-index:v4.19
    type: Image
Copy to Clipboard Toggle word wrap

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

명령 구문

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

1
my-catalog.yaml 과 같은 카탈로그 CR을 지정합니다.

4.3.3. 클러스터에 카탈로그 추가
링크 복사

Operator Lifecycle Manager(OLM) v1 사용을 위해 클러스터에 카탈로그를 추가하려면 ClusterCatalog 사용자 정의 리소스(CR)를 만들고 클러스터에 적용합니다.

프로세스

  1. 다음 예와 유사한 카탈로그 사용자 정의 리소스(CR)를 만듭니다.

    my-redhat-operators.yaml 파일 예시

    apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: my-redhat-operators
    1 
    
spec:
  priority: 1000
    2 
    
  source:
    image:
      pollIntervalMinutes: 10
    3 
    
      ref: registry.redhat.io/redhat/community-operator-index:v4.19
    4 
    
    type: Image
    Copy to Clipboard Toggle word wrap

    1
    카탈로그는 클러스터에 적용되면 자동으로 metadata.name 필드 값으로 레이블이 지정됩니다. 라벨과 카탈로그 선택에 대한 자세한 내용은 "카탈로그 콘텐츠 확인"을 참조하세요.
    2
    선택 사항: 클러스터의 다른 카탈로그와 관련하여 카탈로그의 우선순위를 지정합니다. 자세한 내용은 "우선순위별 카탈로그 선택"을 참조하세요.
    3
    최신 이미지 다이제스트에 대한 원격 레지스트리 폴링 간격을 분 단위로 지정합니다. 폴링을 비활성화하려면 필드를 설정하지 마세요.
    4
    spec.source.image.ref 필드에 카탈로그 이미지를 지정합니다.

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

    $ oc apply -f my-redhat-operators.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    clustercatalog.olm.operatorframework.io/my-redhat-operators created
    Copy to Clipboard Toggle word wrap

검증

  • 카탈로그 상태를 확인하려면 다음 명령을 실행하세요.

    1. 다음 명령을 실행하여 카탈로그를 사용할 수 있는지 확인하세요. 

      $ oc get clustercatalog
      Copy to Clipboard Toggle word wrap

      출력 예

      NAME                            LASTUNPACKED   SERVING   AGE
my-redhat-operators             55s            True      64s
openshift-certified-operators   83m            True      84m
openshift-community-operators   43m            True      84m
openshift-redhat-marketplace    83m            True      84m
openshift-redhat-operators      54m            True      84m
      Copy to Clipboard Toggle word wrap

    2. 다음 명령을 실행하여 카탈로그 상태를 확인하세요. 

      $ oc describe clustercatalog my-redhat-operators
      Copy to Clipboard Toggle word wrap

      출력 예

      Name:         my-redhat-operators
Namespace:
Labels:       olm.operatorframework.io/metadata.name=my-redhat-operators
Annotations:  <none>
API Version:  olm.operatorframework.io/v1
Kind:         ClusterCatalog
Metadata:
  Creation Timestamp:  2025-02-18T20:28:50Z
  Finalizers:
    olm.operatorframework.io/delete-server-cache
  Generation:        1
  Resource Version:  50248
  UID:               86adf94f-d2a8-4e70-895b-31139f2eeab7
Spec:
  Availability Mode:  Available
  Priority:           1000
  Source:
    Image:
      Poll Interval Minutes:  10
      Ref:                    registry.redhat.io/redhat/community-operator-index:v4.19
    Type:                     Image
Status:
      1 
      
  Conditions:
    Last Transition Time:  2025-02-18T20:29:00Z
    Message:               Successfully unpacked and stored content from resolved source
    Observed Generation:   1
    Reason:                Succeeded
      2 
      
    Status:                True
    Type:                  Progressing
    Last Transition Time:  2025-02-18T20:29:00Z
    Message:               Serving desired content from resolved source
    Observed Generation:   1
    Reason:                Available
    Status:                True
    Type:                  Serving
  Last Unpacked:           2025-02-18T20:28:59Z
  Resolved Source:
    Image:
      Ref:  registry.redhat.io/redhat/community-operator-index@sha256:11627ea6fdd06b8092df815076e03cae9b7cede8b353c0b461328842d02896c5
      3 
      
    Type:   Image
  Urls:
    Base:  https://catalogd-service.openshift-catalogd.svc/catalogs/my-redhat-operators
Events:    <none>
      Copy to Clipboard Toggle word wrap

      1
      카탈로그의 상태를 설명합니다.
      2
      카탈로그가 현재 상태인 이유를 표시합니다.
      3
      카탈로그의 이미지 참조를 표시합니다.

4.3.4. 카탈로그 삭제
링크 복사

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

사전 요구 사항

  • 카탈로그가 설치되었습니다.

프로세스

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

    $ oc delete clustercatalog <catalog_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    clustercatalog.olm.operatorframework.io "my-redhat-operators" deleted
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 카탈로그가 삭제되었는지 확인하세요. 

    $ oc get clustercatalog
    Copy to Clipboard Toggle word wrap

4.3.5. 기본 카탈로그 비활성화
링크 복사

기본적으로 OpenShift Container Platform에 포함된 Red Hat 제공 카탈로그를 비활성화할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 기본 카탈로그를 비활성화합니다. 

    $ oc patch clustercatalog openshift-certified-operators -p \
  '{"spec": {"availabilityMode": "Unavailable"}}' --type=merge
    Copy to Clipboard Toggle word wrap

    출력 예

    clustercatalog.olm.operatorframework.io/openshift-certified-operators patched
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 카탈로그가 비활성화되었는지 확인하세요. 

    $ oc get clustercatalog openshift-certified-operators
    Copy to Clipboard Toggle word wrap

    출력 예

    NAME                            LASTUNPACKED   SERVING   AGE
openshift-certified-operators                  False     6h54m
    Copy to Clipboard Toggle word wrap

4.4. 카탈로그 콘텐츠 해결
링크 복사

사용자 정의 리소스(CR)에 설치하려는 클러스터 확장을 지정하면 Operator Lifecycle Manager(OLM) v1은 카탈로그 선택을 사용하여 어떤 콘텐츠를 설치할지 확인합니다.

카탈로그 콘텐츠 선택을 제어하려면 다음 작업을 수행할 수 있습니다.

  • 카탈로그를 선택하려면 라벨을 지정하세요.
  • 복잡한 카탈로그 필터링을 수행하려면 일치 표현식을 사용합니다.
  • 카탈로그 우선순위를 설정합니다.

카탈로그 선택 기준을 지정하지 않으면 Operator Lifecycle Manager(OLM) v1은 요청된 패키지를 제공하는 클러스터의 사용 가능한 카탈로그에서 확장을 선택합니다.

해결 과정에서는 기본적으로 더 이상 사용되지 않는 번들이 더 이상 사용되지 않는 번들보다 우선합니다.

4.4.1. 이름으로 카탈로그 선택
링크 복사

카탈로그가 클러스터에 추가되면 카탈로그 사용자 정의 리소스(CR)의 metadata.name 필드 값을 사용하여 레이블이 생성됩니다. 확장 프로그램의 CR에서 spec.source.catalog.selector.matchLabels 필드를 사용하여 카탈로그 이름을 지정할 수 있습니다. matchLabels 필드의 값은 다음 형식을 사용합니다.

metadata.name 필드에서 파생된 예제 레이블

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <example_extension>
  labels:
    olm.operatorframework.io/metadata.name: <example_extension>
1 

...
Copy to Clipboard Toggle word wrap

1
카탈로그가 적용될 때 자동으로 추가되는 metadata.name 필드에서 파생된 레이블입니다.

다음 예제에서는 openshift-redhat-operators 레이블이 있는 카탈로그에서 <example_extension>-operator 패키지를 확인합니다.

예제 확장 CR

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <example_extension>
spec:
  namespace: <example_namespace>
  serviceAccount:
    name: <example_extension>-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: <example_extension>-operator
      selector:
        matchLabels:
          olm.operatorframework.io/metadata.name: openshift-redhat-operators
Copy to Clipboard Toggle word wrap

4.4.2. 라벨 또는 표현에 따른 카탈로그 선택
링크 복사

클러스터 카탈로그의 사용자 정의 리소스(CR)에 있는 레이블을 사용하여 카탈로그에 메타데이터를 추가할 수 있습니다. 그런 다음 클러스터 확장의 CR에서 할당된 레이블을 지정하거나 표현식을 사용하여 카탈로그 선택을 필터링할 수 있습니다.

다음 클러스터 카탈로그 CR은 카탈로그-a 클러스터 카탈로그에 true 값을 갖는 example.com/support 레이블을 추가합니다.

레이블이 있는 클러스터 카탈로그 CR 예시

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: catalog-a
  labels:
    example.com/support: "true"
spec:
  source:
    type: Image
    image:
      ref: quay.io/example/content-management-a:latest
Copy to Clipboard Toggle word wrap

다음 클러스터 확장 CR은 matchLabels 선택기를 사용하여 example.com/support 레이블과 true 값이 있는 카탈로그를 선택합니다.

matchLabels 선택기를 사용한 클러스터 확장 CR 예시

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <example_extension>
spec:
  namespace: <example_namespace>
  serviceAccount:
    name: <example_extension>-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: <example_extension>-operator
      selector:
        matchLabels:
          example.com/support: "true"
Copy to Clipboard Toggle word wrap

matchExpressions 필드를 사용하면 레이블에 대한 더 복잡한 필터링을 수행할 수 있습니다. 다음 클러스터 확장 CR은 example.com/support 레이블과 production 또는 supported 값을 갖는 카탈로그를 선택합니다.

matchExpression 선택기를 사용한 클러스터 확장 CR 예시

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <example_extension>
spec:
  namespace: <example_namespace>
  serviceAccount:
    name: <example_extension>-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: <example_extension>-operator
      selector:
        matchExpressions:
          - key: example.com/support
            operator: In
            values:
              - "production"
              - "supported"
Copy to Clipboard Toggle word wrap

참고

matchLabels 및 matchExpressions 필드를 모두 사용하는 경우, 선택한 카탈로그는 지정된 모든 기준을 충족해야 합니다.

4.4.3. 라벨 또는 표현에 따른 카탈로그 제외
링크 복사

NotIn 또는 DoesNotExist 연산자와 함께 메타데이터에 일치 표현식을 사용하여 카탈로그를 제외할 수 있습니다.

다음 CR은 unwanted-catalog-1 및 unwanted-catalog-2 클러스터 카탈로그에 example.com/testing 레이블을 추가합니다.

예제 클러스터 카탈로그 CR

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: unwanted-catalog-1
  labels:
    example.com/testing: "true"
spec:
  source:
    type: Image
    image:
      ref: quay.io/example/content-management-a:latest
Copy to Clipboard Toggle word wrap

예제 클러스터 카탈로그 CR

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: unwanted-catalog-2
  labels:
    example.com/testing: "true"
spec:
  source:
    type: Image
    image:
      ref: quay.io/example/content-management-b:latest
Copy to Clipboard Toggle word wrap

다음 클러스터 확장 CR은 unwanted-catalog-1 카탈로그에서 선택을 제외합니다.

특정 카탈로그를 제외하는 클러스터 확장 CR 예

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <example_extension>
spec:
  namespace: <example_namespace>
  serviceAccount:
    name: <example_extension>-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: <example_extension>-operator
      selector:
        matchExpressions:
          - key: olm.operatorframework.io/metadata.name
            operator: NotIn
            values:
              - unwanted-catalog-1
Copy to Clipboard Toggle word wrap

다음 클러스터 확장 CR은 example.com/testing 레이블이 없는 카탈로그에서 선택합니다. 결과적으로, unwanted-catalog-1 과 unwanted-catalog-2 는 모두 카탈로그 선택에서 제외됩니다.

특정 레이블이 있는 카탈로그를 제외하는 클러스터 확장 CR 예

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: <example_extension>
spec:
  namespace: <example_namespace>
  serviceAccount:
    name: <example_extension>-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: <example_extension>-operator
      selector:
        matchExpressions:
          - key: example.com/testing
            operator: DoesNotExist
Copy to Clipboard Toggle word wrap

4.4.4. 우선순위에 따른 카탈로그 선택
링크 복사

여러 카탈로그에서 동일한 패키지를 제공하는 경우 각 카탈로그의 사용자 정의 리소스(CR)에서 우선순위를 지정하여 모호성을 해결할 수 있습니다. 지정하지 않으면 카탈로그의 기본 우선 순위 값은 0 입니다. 우선순위는 양수 또는 음수의 32비트 정수가 될 수 있습니다.

참고
  • 번들 확인 중에 우선순위 값이 높은 카탈로그가 우선순위 값이 낮은 카탈로그보다 선택됩니다.
  • 더 이상 사용되지 않는 번들은 더 이상 사용되지 않는 번들보다 우선합니다.
  • 동일한 우선순위를 가진 여러 번들이 카탈로그에 존재하고 카탈로그 선택이 모호한 경우 오류가 출력됩니다.

더 높은 우선순위를 갖는 예제 클러스터 카탈로그 CR

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: high-priority-catalog
spec:
  priority: 1000
  source:
    type: Image
    image:
      ref: quay.io/example/higher-priority-catalog:latest
Copy to Clipboard Toggle word wrap

우선순위가 낮은 클러스터 카탈로그 CR의 예

apiVersion: olm.operatorframework.io/v1
kind: ClusterCatalog
metadata:
  name: lower-priority-catalog
spec:
  priority: 10
  source:
    type: Image
    image:
      ref: quay.io/example/lower-priority-catalog:latest
Copy to Clipboard Toggle word wrap

4.4.5. 카탈로그 선택 오류 문제 해결
링크 복사

모호함이나 선택된 카탈로그가 없어 번들 확인에 실패하면 클러스터 확장의 status.conditions 필드에 오류 메시지가 인쇄됩니다.

다음 작업을 수행하여 카탈로그 선택 오류 문제를 해결합니다.

  • 라벨이나 표현을 사용하여 선택 기준을 구체화하세요.
  • 카탈로그 우선순위를 조정하세요.
  • 패키지 이름과 버전 요구 사항과 일치하는 번들이 하나만 있는지 확인하세요.

4.5. 카탈로그 만들기
링크 복사

카탈로그 유지 관리자는 OpenShift Container Platform의 Operator Lifecycle Manager(OLM) v1에서 사용할 파일 기반 카탈로그 형식으로 새 카탈로그를 만들 수 있습니다.

4.5.1. 파일 기반 카탈로그 이미지 생성
링크 복사

opm CLI를 사용하면 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 대체하는 일반 텍스트 파일 기반 카탈로그 형식(JSON 또는 YAML)을 사용하는 카탈로그 이미지를 만들 수 있습니다.

사전 요구 사항

  • opm CLI를 설치했습니다.
  • podman 버전 1.9.3+이 있습니다.
  • 번들 이미지가 빌드되어 Docker v2-2 를 지원하는 레지스트리로 푸시됩니다.

프로세스

  1. 카탈로그를 초기화합니다.

    1. 다음 명령을 실행하여 카탈로그에 대한 디렉토리를 만듭니다. 

      $ mkdir <catalog_dir>
      Copy to Clipboard Toggle word wrap

    2. opm generate dockerfile 명령을 실행하여 카탈로그 이미지를 빌드할 수 있는 Dockerfile을 생성합니다. 

      $ opm generate dockerfile <catalog_dir> \
    -i registry.redhat.io/openshift4/ose-operator-registry-rhel9:v4.19
      1
      Copy to Clipboard Toggle word wrap
      1
      -i 플래그를 사용하여 공식 Red Hat 기본 이미지를 지정하세요. 그렇지 않으면 Dockerfile은 기본 업스트림 이미지를 사용합니다.

      Dockerfile은 이전 단계에서 생성한 카탈로그 디렉터리와 동일한 상위 디렉터리에 있어야 합니다.

      디렉터리 구조의 예

      .
      1 
      
├── <catalog_dir>
      2 
      
└── <catalog_dir>.Dockerfile
      3
      Copy to Clipboard Toggle word wrap

      1
      상위 디렉토리
      2
      카탈로그 디렉토리
      3
      opm generate dockerfile 명령으로 생성된 Dockerfile

    3. opm init 명령을 실행하여 카탈로그를 Operator의 패키지 정의로 채웁니다. 

      $ opm init <operator_name> \
      1 
      
    --default-channel=preview \
      2 
      
    --description=./README.md \
      3 
      
    --icon=./operator-icon.svg \
      4 
      
    --output yaml \
      5 
      
    > <catalog_dir>/index.yaml
      6
      Copy to Clipboard Toggle word wrap
      1
      운영자 또는 패키지 이름
      2
      지정되지 않은 경우 구독이 기본적으로 적용되는 채널
      3
      운영자의 README.md 또는 기타 문서에 대한 경로
      4
      운영자 아이콘으로 가는 경로
      5
      출력 형식: JSON 또는 YAML
      6
      카탈로그 구성 파일을 생성하기 위한 경로

      이 명령은 지정된 카탈로그 구성 파일에 olm.package 선언적 구성 blob을 생성합니다.

  2. opm render 명령을 실행하여 카탈로그에 번들을 추가합니다. 

    $ opm render <registry>/<namespace>/<bundle_image_name>:<tag> \
    1 
    
    --output=yaml \
    >> <catalog_dir>/index.yaml
    2
    Copy to Clipboard Toggle word wrap
    1
    번들 이미지에 대한 풀 스펙
    2
    카탈로그 구성 파일 경로
    참고

    채널에는 하나 이상의 번들이 포함되어야 합니다.

  3. 번들에 채널 항목을 추가합니다. 예를 들어, 다음 예를 귀하의 사양에 맞게 수정하고 <catalog_dir>/index.yaml 파일에 추가하세요.

    채널 항목 예

    ---
schema: olm.channel
package: <operator_name>
name: preview
entries:
  - name: <operator_name>.v0.1.0
    1
    Copy to Clipboard Toggle word wrap

    1
    <operator_name> 뒤의 마침표(.)를 버전 v 앞에 포함해야 합니다. 그렇지 않으면 해당 항목은 opm validate 명령을 통과하지 못합니다.

  4. 파일 기반 카탈로그를 확인합니다.

    1. 카탈로그 디렉터리에 대해 opm validate 명령을 실행합니다. 

      $ opm validate <catalog_dir>
      Copy to Clipboard Toggle word wrap

    2. 오류 코드가 0인지 확인합니다. 

      $ echo $?
      Copy to Clipboard Toggle word wrap

      출력 예

      0
      Copy to Clipboard Toggle word wrap

  5. podman build 명령을 실행하여 카탈로그 이미지를 빌드합니다. 

    $ podman build . \
    -f <catalog_dir>.Dockerfile \
    -t <registry>/<namespace>/<catalog_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

  6. 카탈로그 이미지를 레지스트리로 푸시합니다.

    1. 필요한 경우 podman login 명령을 실행하여 대상 레지스트리에 인증합니다. 

      $ podman login <registry>
      Copy to Clipboard Toggle word wrap

    2. podman push 명령을 실행하여 카탈로그 이미지를 푸시합니다. 

      $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
      Copy to Clipboard Toggle word wrap

4.5.2. 파일 기반 카탈로그 이미지 업데이트 또는 필터링
링크 복사

opm CLI를 사용하면 파일 기반 카탈로그 형식을 사용하는 카탈로그 이미지를 업데이트하거나 필터링할 수 있습니다. 기존 카탈로그 이미지의 내용을 추출하면 필요에 따라 카탈로그를 수정할 수 있습니다. 예:

  • 패키지 추가
  • 패키지 제거
  • 기존 패키지 항목 업데이트
  • 패키지, 채널 및 번들별 사용 중단 메시지 세부 정보

그런 다음 카탈로그의 업데이트된 버전으로 이미지를 다시 빌드할 수 있습니다.

참고

또는 미러 레지스트리에 이미 카탈로그 이미지가 있는 경우 oc-mirror CLI 플러그인을 사용하여 해당 카탈로그 이미지의 업데이트된 소스 버전에서 제거된 모든 이미지를 자동으로 정리한 다음 대상 레지스트리에 미러링할 수 있습니다.

oc-mirror 플러그인과 이 사용 사례에 대한 자세한 내용은 "미러 레지스트리 콘텐츠를 최신 상태로 유지하기" 섹션과 특히 "oc-mirror 플러그인을 사용하여 연결이 끊긴 설치에 대한 이미지 미러링"의 "이미지 정리" 하위 섹션을 참조하세요.

사전 요구 사항

  • 귀하의 워크스테이션에는 다음이 있습니다.

    • opm CLI.
    • podman 버전 1.9.3+.
    • 파일 기반 카탈로그 이미지.

    • 이 카탈로그와 관련된 카탈로그 디렉토리 구조가 최근 귀하의 워크스테이션에서 초기화되었습니다.

      초기화된 카탈로그 디렉터리가 없는 경우 디렉터리를 생성하고 Dockerfile을 생성합니다. 자세한 내용은 "파일 기반 카탈로그 이미지 만들기" 절차의 "카탈로그 초기화" 단계를 참조하세요.

프로세스

  1. 카탈로그 이미지의 내용을 YAML 형식으로 추출하여 카탈로그 디렉토리의 index.yaml 파일에 저장합니다. 

    $ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \
    -o yaml > <catalog_dir>/index.yaml
    Copy to Clipboard Toggle word wrap
    참고

    또는 -o json 플래그를 사용하여 JSON 형식으로 출력할 수 있습니다.

  2. 결과 index.yaml 파일의 내용을 사양에 맞게 수정하세요.

    중요

    카탈로그에 번들이 게시된 후 사용자 중 한 명이 해당 번들을 설치했다고 가정합니다. 해당 버전을 설치한 사용자가 고립되는 것을 방지하기 위해 카탈로그에 게시된 모든 번들에 현재 또는 최신 채널 헤드에 대한 업데이트 경로가 있는지 확인하세요.

    • 운영자를 추가하려면 "파일 기반 카탈로그 이미지 만들기" 절차에서 패키지, 번들 및 채널 항목을 만드는 단계를 따르세요.

    • 운영자를 제거하려면 패키지와 관련된 olm.package , olm.channel , olm.bundle 블롭 세트를 삭제합니다. 다음 예에서는 카탈로그에서 example-operator 패키지를 제거하기 위해 삭제해야 하는 세트를 보여줍니다.

      예 4.9. 제거된 항목의 예

      ---
defaultChannel: release-2.7
icon:
  base64data: <base64_string>
  mediatype: image/svg+xml
name: example-operator
schema: olm.package
---
entries:
- name: example-operator.v2.7.0
  skipRange: '>=2.6.0 <2.7.0'
- name: example-operator.v2.7.1
  replaces: example-operator.v2.7.0
  skipRange: '>=2.6.0 <2.7.1'
- name: example-operator.v2.7.2
  replaces: example-operator.v2.7.1
  skipRange: '>=2.6.0 <2.7.2'
- name: example-operator.v2.7.3
  replaces: example-operator.v2.7.2
  skipRange: '>=2.6.0 <2.7.3'
- name: example-operator.v2.7.4
  replaces: example-operator.v2.7.3
  skipRange: '>=2.6.0 <2.7.4'
name: release-2.7
package: example-operator
schema: olm.channel
---
image: example.com/example-inc/example-operator-bundle@sha256:<digest>
name: example-operator.v2.7.0
package: example-operator
properties:
- type: olm.gvk
  value:
    group: example-group.example.io
    kind: MyObject
    version: v1alpha1
- type: olm.gvk
  value:
    group: example-group.example.io
    kind: MyOtherObject
    version: v1beta1
- type: olm.package
  value:
    packageName: example-operator
    version: 2.7.0
- type: olm.bundle.object
  value:
    data: <base64_string>
- type: olm.bundle.object
  value:
    data: <base64_string>
relatedImages:
- image: example.com/example-inc/example-related-image@sha256:<digest>
  name: example-related-image
schema: olm.bundle
---
      Copy to Clipboard Toggle word wrap
    • Operator에 대한 사용 중단 메시지를 추가하거나 업데이트하려면 패키지의 index.yaml 파일과 같은 디렉토리에 deprecations.yaml 파일이 있는지 확인하세요. deprecations.yaml 파일 형식에 대한 자세한 내용은 "olm.deprecations 스키마"를 참조하세요.
  3. 변경 사항을 저장하십시오.

  4. 카탈로그 검증: 

    $ opm validate <catalog_dir>
    Copy to Clipboard Toggle word wrap

  5. 카탈로그를 다시 작성하세요: 

    $ podman build . \
    -f <catalog_dir>.Dockerfile \
    -t <registry>/<namespace>/<catalog_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

  6. 업데이트된 카탈로그 이미지를 레지스트리에 푸시합니다. 

    $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>
    Copy to Clipboard Toggle word wrap

검증

  1. 웹 콘솔에서 관리 → 클러스터 설정 → 구성 페이지에 있는 OperatorHub 구성 리소스로 이동합니다.

  2. 업데이트된 카탈로그 이미지에 대한 풀 사양을 사용하도록 카탈로그 소스를 추가하거나 기존 카탈로그 소스를 업데이트합니다.

    자세한 내용은 이 섹션의 "추가 리소스"에서 "클러스터에 카탈로그 소스 추가"를 참조하세요.

  3. 카탈로그 소스가 준비 상태가 되면 운영자 → 운영자 허브 페이지로 이동하여 변경 사항이 운영자 목록에 반영되었는지 확인하세요.

4.6. OLM v1의 연결 해제된 환경 지원
링크 복사

특히 임무 수행에 중요한 프로덕션 워크로드를 위해 인터넷에 연결되지 않은 환경에서 클러스터를 실행하여 높은 보안을 우선시하는 클러스터 관리자를 지원하기 위해 Operator Lifecycle Manager(OLM) v1에는 이러한 연결되지 않은 환경에서 작동하는 클러스터 확장 수명 주기 관리 기능이 포함되어 있으며, 이는 OpenShift Container Platform 4.18부터 제공됩니다.

4.6.1. OLM v1의 연결 해제된 지원 및 oc-mirror 플러그인에 관하여
링크 복사

Operator Lifecycle Manager(OLM) v1은 OpenShift Container Platform 4.18부터 연결이 끊긴 환경을 지원합니다. OpenShift CLI( oc )용 oc-mirror 플러그인을 사용하여 클러스터에 필요한 이미지를 완전히 또는 부분적으로 연결이 끊긴 환경의 미러 레지스트리로 미러링한 후, 사용하는 oc-mirror 플러그인 버전에 따라 다음 리소스 세트 중 하나를 활용하여 OLM v1이 이러한 환경에서 제대로 작동할 수 있습니다.

  • oc-mirror 플러그인 v1에 의해 자동으로 생성되는 ImageContentSourcePolicy 리소스와 oc-mirror 플러그인 v1을 사용한 후 수동으로 생성해야 하는 ClusterCatalog 리소스
  • oc-mirror 플러그인 v2에서 자동으로 생성되는 ImageDigestMirrorSet , ImageTagMirrorSet 및 ClusterCatalog 리소스
참고

OpenShift Container Platform 4.18부터 미러링을 위해 권장되는 버전은 oc-mirror 플러그인 v2입니다.

자세한 내용과 절차는 사용하려는 oc-mirror 플러그인 버전의 연결 해제된 환경 가이드를 참조하세요.

5장. 클러스터 확장
링크 복사

5.1. 클러스터 확장 관리
링크 복사

카탈로그가 클러스터에 추가되면 카탈로그에 게시된 확장 기능과 운영자의 버전, 패치, 무선 업데이트에 액세스할 수 있습니다.

CLI에서 사용자 정의 리소스(CR)를 사용하여 확장을 선언적으로 관리할 수 있습니다.

참고

OpenShift Container Platform 4.19의 경우 OLM v1에 대한 문서화된 절차는 CLI 기반입니다. 또는 관리자는 YAML 가져오기 및 검색 페이지와 같은 일반적인 방법을 사용하여 웹 콘솔에서 관련 객체를 만들고 볼 수 있습니다. 하지만 기존의 OperatorHub 및 설치된 운영자 페이지에는 아직 OLM v1 구성 요소가 표시되지 않습니다.

5.1.1. 지원되는 확장 프로그램
링크 복사

현재 Operator Lifecycle Manager(OLM) v1은 다음 모든 기준을 충족하는 클러스터 확장 프로그램을 설치하는 것을 지원합니다.

  • 확장 기능은 OLM(클래식)에서 도입된 registry+v1 번들 형식을 사용해야 합니다.

  • 확장 기능은 AllNamespaces 설치 모드를 통한 설치를 지원해야 합니다.

    • SingleNamespace 및 OwnNamespace 설치 모드에 대한 지원은 OpenShift Container Platform 4.19에 기술 미리 보기 기능으로 포함되었습니다.
  • 확장 프로그램은 웹후크를 사용하면 안 됩니다.

  • 확장 프로그램은 다음 파일 기반 카탈로그 속성을 사용하여 종속성을 선언해서는 안 됩니다.

    • olm.gvk.required
    • olm.package.required
    • olm.constraint

OLM v1은 설치하려는 확장 프로그램이 이러한 제약 조건을 충족하는지 확인합니다. 설치하려는 확장 프로그램이 이러한 제약 조건을 충족하지 못하면 클러스터 확장 프로그램의 조건에 오류 메시지가 인쇄됩니다.

중요

Operator Lifecycle Manager(OLM) v1은 OLM(클래식)에 도입된 OperatorConditions API를 지원하지 않습니다.

확장 프로그램이 업데이트를 관리하기 위해 OperatorConditions API에만 의존하는 경우 확장 프로그램이 올바르게 설치되지 않을 수 있습니다. 이 API를 사용하는 대부분의 확장 프로그램은 시작 시 실패하지만, 일부는 조정 중에 실패할 수 있습니다.

해결 방법으로 확장 프로그램을 특정 버전으로 고정할 수 있습니다. 확장 프로그램을 업데이트하려는 경우 확장 프로그램의 설명서를 참조하여 확장 프로그램을 새 버전으로 고정하는 것이 안전한 시기를 확인하세요.

5.1.2. 카탈로그에서 설치할 운영자 찾기
링크 복사

클러스터에 카탈로그를 추가한 후에는 카탈로그를 쿼리하여 설치할 연산자와 확장 프로그램을 찾을 수 있습니다.

현재 Operator Lifecycle Manager(OLM) v1에서는 catalogd가 관리하는 클러스터 내 카탈로그를 쿼리할 수 없습니다. OLM v1에서는 카탈로그 레지스트리를 쿼리하려면 opm 및 jq CLI 도구를 사용해야 합니다.

사전 요구 사항

  • 클러스터에 카탈로그를 추가했습니다.
  • jq CLI 도구를 설치했습니다.
  • opm CLI 도구를 설치했습니다.

프로세스

  1. AllNamespaces 설치 모드를 지원하고 웹훅을 사용하지 않는 확장 프로그램 목록을 반환하려면 다음 명령을 입력하세요. 

    $ opm render <catalog_registry_url>:<tag> \
  | jq -cs '[.[] | select(.schema == "olm.bundle" \
  and (.properties[] | select(.type == "olm.csv.metadata").value.installModes[] \
  | select(.type == "AllNamespaces" and .supported == true)) \
  and .spec.webhookdefinitions == null) | .package] | unique[]'
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    catalog_registry_url
    registry.redhat.io/redhat/redhat-operator-index 와 같이 카탈로그 레지스트리의 URL을 지정합니다.
    tag

    카탈로그의 태그나 버전(예: v4.19 또는 최신)을 지정합니다.

    예 5.1. 명령 예

    $ opm render \
  registry.redhat.io/redhat/redhat-operator-index:v4.19 \
  | jq -cs '[.[] | select(.schema == "olm.bundle" \
  and (.properties[] | select(.type == "olm.csv.metadata").value.installModes[] \
  | select(.type == "AllNamespaces" and .supported == true)) \
  and .spec.webhookdefinitions == null) | .package] | unique[]'
    Copy to Clipboard Toggle word wrap

    예 5.2. 출력 예

    "3scale-operator"
"amq-broker-rhel8"
"amq-online"
"amq-streams"
"amq-streams-console"
"ansible-automation-platform-operator"
"ansible-cloud-addons-operator"
"apicast-operator"
"authorino-operator"
"aws-load-balancer-operator"
"bamoe-kogito-operator"
"cephcsi-operator"
"cincinnati-operator"
"cluster-logging"
"cluster-observability-operator"
"compliance-operator"
"container-security-operator"
"cryostat-operator"
"datagrid"
"devspaces"
...
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 확장 프로그램의 메타데이터 내용을 검사하세요. 

    $ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.package") \
  | select( .name == "<package_name>")'
    Copy to Clipboard Toggle word wrap

    예 5.3. 명령 예

    $ opm render \
  registry.redhat.io/redhat/redhat-operator-index:v4.19 \
  | jq -s '.[] | select( .schema == "olm.package") \
  | select( .name == "openshift-pipelines-operator-rh")'
    Copy to Clipboard Toggle word wrap

    예 5.4. 출력 예

    {
  "schema": "olm.package",
  "name": "openshift-pipelines-operator-rh",
  "defaultChannel": "latest",
  "icon": {
    "base64data": "iVBORw0KGgoAAAANSUhE...",
    "mediatype": "image/png"
  }
}
    Copy to Clipboard Toggle word wrap
5.1.2.1. 일반적인 카탈로그 쿼리
링크 복사

opm 및 jq CLI 도구를 사용하여 카탈로그를 쿼리할 수 있습니다. 다음 표에서는 확장 프로그램의 수명 주기를 설치, 업데이트, 관리할 때 사용할 수 있는 일반적인 카탈로그 쿼리를 보여줍니다.

명령 구문

$ opm render <catalog_registry_url>:<tag> | <jq_request>
Copy to Clipboard Toggle word wrap

다음과 같습니다.

catalog_registry_url
registry.redhat.io/redhat/redhat-operator-index 와 같이 카탈로그 레지스트리의 URL을 지정합니다.
tag
카탈로그의 태그나 버전(예: v4.19 또는 최신)을 지정합니다.
jq_request
카탈로그에서 실행할 쿼리를 지정합니다.

예 5.5. 명령 예

$ opm render \
  registry.redhat.io/redhat/redhat-operator-index:v4.19 \
  | jq -cs '[.[] | select(.schema == "olm.bundle" and (.properties[] \
  | select(.type == "olm.csv.metadata").value.installModes[] \
  | select(.type == "AllNamespaces" and .supported == true)) \
  and .spec.webhookdefinitions == null) \
  | .package] | unique[]'
Copy to Clipboard Toggle word wrap
Expand
표 5.1. 일반적인 패키지 쿼리
쿼리요청

카탈로그에서 사용 가능한 패키지 

$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.package")'
Copy to Clipboard Toggle word wrap

AllNamespaces 설치 모드를 지원하고 웹훅을 사용하지 않는 패키지 

$ opm render <catalog_registry_url>:<tag> \
  | jq -cs '[.[] | select(.schema == "olm.bundle" and (.properties[] \
  | select(.type == "olm.csv.metadata").value.installModes[] \
  | select(.type == "AllNamespaces" and .supported == true)) \
  and .spec.webhookdefinitions == null) \
  | .package] | unique[]'
Copy to Clipboard Toggle word wrap

패키지 메타데이터 

$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.package") \
  | select( .name == "<package_name>")'
Copy to Clipboard Toggle word wrap

패키지의 카탈로그 블롭 

$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .package == "<package_name>")'
Copy to Clipboard Toggle word wrap
Expand
표 5.2. 공통 채널 쿼리
쿼리요청

패키지의 채널 

$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.channel" ) \
  | select( .package == "<package_name>") | .name'
Copy to Clipboard Toggle word wrap

채널의 버전 

$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .package == "<package_name>" ) \
  | select( .schema == "olm.channel" ) \
  | select( .name == "<channel_name>" ) .entries \
  | .[] | .name'
Copy to Clipboard Toggle word wrap
  • 채널의 최신 버전
  • 업그레이드 경로 
$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.channel" ) \
  | select ( .name == "<channel_name>") \
  | select( .package == "<package_name>")'
Copy to Clipboard Toggle word wrap
Expand
표 5.3. 일반적인 번들 쿼리
쿼리요청

패키지의 번들 

$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.bundle" ) \
  | select( .package == "<package_name>") | .name'
Copy to Clipboard Toggle word wrap
  • 번들 종속성
  • 사용 가능한 API 
$ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.bundle" ) \
  | select ( .name == "<bundle_name>") \
  | select( .package == "<package_name>")'
Copy to Clipboard Toggle word wrap

5.1.3. 클러스터 확장 권한
링크 복사

Operator Lifecycle Manager(OLM) Classic에서는 클러스터 관리자 권한이 있는 단일 서비스 계정으로 모든 클러스터 확장을 관리합니다.

OLM v1은 기본적으로 OLM(Classic)보다 더 안전하도록 설계되었습니다. OLM v1은 확장의 사용자 지정 리소스(CR)에 지정된 서비스 계정을 사용하여 클러스터 확장을 관리합니다. 클러스터 관리자는 각 클러스터 확장에 대한 서비스 계정을 만들 수 있습니다. 결과적으로 관리자는 최소 권한의 원칙을 따르고 역할 기반 액세스 제어(RBAC)만 할당하여 해당 확장 프로그램을 설치하고 관리할 수 있습니다.

각 권한은 클러스터 역할이나 역할에 추가해야 합니다. 그런 다음 클러스터 역할 바인딩이나 역할 바인딩을 사용하여 클러스터 역할이나 역할을 서비스 계정에 바인딩해야 합니다.

RBAC 범위를 클러스터나 네임스페이스로 지정할 수 있습니다. 클러스터 역할과 클러스터 역할 바인딩을 사용하여 클러스터에 대한 권한 범위를 지정합니다. 역할과 역할 바인딩을 사용하여 네임스페이스에 대한 권한 범위를 지정합니다. 설치하고 관리하려는 확장 프로그램의 디자인에 따라 권한 범위를 클러스터 또는 네임스페이스로 지정할지 여부가 달라집니다.

중요

다음 절차를 간소화하고 가독성을 높이기 위해 다음 예제 매니페스트는 클러스터에 범위가 지정된 권한을 사용합니다. 클러스터 대신 확장의 네임스페이스로 범위를 지정하여 일부 권한을 추가로 제한할 수 있습니다.

설치된 확장 프로그램의 새 버전에 추가 권한이 필요한 경우 OLM v1은 클러스터 관리자가 해당 권한을 부여할 때까지 업데이트 프로세스를 중단합니다.

5.1.3.1. 네임스페이스 생성
링크 복사

클러스터 확장을 설치하고 관리하기 위한 서비스 계정을 만들기 전에 네임스페이스를 만들어야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

프로세스

  • 다음 명령을 실행하여 설치하려는 확장 프로그램의 서비스 계정에 대한 새 네임스페이스를 만듭니다. 

    $ oc adm new-project <new_namespace>
    Copy to Clipboard Toggle word wrap
5.1.3.2. 확장 프로그램에 대한 서비스 계정 생성
링크 복사

클러스터 확장을 설치, 관리 및 업데이트하려면 서비스 계정을 만들어야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

프로세스

  1. 다음 예와 유사하게 서비스 계정을 만듭니다. 

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: <extension>-installer
  namespace: <namespace>
    Copy to Clipboard Toggle word wrap

    예 5.6. extension-service-account.yaml 파일 예시

    apiVersion: v1
kind: ServiceAccount
metadata:
  name: pipelines-installer
  namespace: pipelines
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 서비스 계정을 적용합니다. 

    $ oc apply -f extension-service-account.yaml
    Copy to Clipboard Toggle word wrap
5.1.3.3. 확장 프로그램의 번들 매니페스트 다운로드
링크 복사

opm CLI 도구를 사용하여 설치하려는 확장 프로그램의 번들 매니페스트를 다운로드합니다. 원하는 CLI 도구나 텍스트 편집기를 사용하여 매니페스트를 보고 확장 프로그램을 설치하고 관리하는 데 필요한 권한을 찾으세요.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 어떤 확장 프로그램을 설치할지 결정했습니다.
  • opm CLI 도구를 설치했습니다.

프로세스

  1. 다음 명령을 실행하여 설치하려는 확장 프로그램의 사용 가능한 버전과 이미지를 검사하세요. 

    $ opm render <registry_url>:<tag_or_version> | \
  jq -cs '.[] | select( .schema == "olm.bundle" ) | \
  select( .package == "<extension_name>") | \
  {"name":.name, "image":.image}'
    Copy to Clipboard Toggle word wrap

    예 5.7. 명령 예

    $ opm render registry.redhat.io/redhat/redhat-operator-index:v4.19 | \
  jq -cs '.[] | select( .schema == "olm.bundle" ) | \
  select( .package == "openshift-pipelines-operator-rh") | \
  {"name":.name, "image":.image}'
    Copy to Clipboard Toggle word wrap

    예 5.8. 출력 예

    {"name":"openshift-pipelines-operator-rh.v1.14.3","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:3f64b29f6903981470d0917b2557f49d84067bccdba0544bfe874ec4412f45b0"}
{"name":"openshift-pipelines-operator-rh.v1.14.4","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:dd3d18367da2be42539e5dde8e484dac3df33ba3ce1d5bcf896838954f3864ec"}
{"name":"openshift-pipelines-operator-rh.v1.14.5","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838"}
{"name":"openshift-pipelines-operator-rh.v1.15.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:22be152950501a933fe6e1df0e663c8056ca910a89dab3ea801c3bb2dc2bf1e6"}
{"name":"openshift-pipelines-operator-rh.v1.15.1","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:64afb32e3640bb5968904b3d1a317e9dfb307970f6fda0243e2018417207fd75"}
{"name":"openshift-pipelines-operator-rh.v1.15.2","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd"}
{"name":"openshift-pipelines-operator-rh.v1.16.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:a46b7990c0ad07dae78f43334c9bd5e6cba7b50ca60d3f880099b71e77bed214"}
{"name":"openshift-pipelines-operator-rh.v1.16.1","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:29f27245e93b3f605647993884751c490c4a44070d3857a878d2aee87d43f85b"}
{"name":"openshift-pipelines-operator-rh.v1.16.2","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:2037004666526c90329f4791f14cb6cc06e8775cb84ba107a24cc4c2cf944649"}
{"name":"openshift-pipelines-operator-rh.v1.17.0","image":"registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:d75065e999826d38408049aa1fde674cd1e45e384bfdc96523f6bad58a0e0dbc"}
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 설치하려는 번들 이미지를 추출할 디렉토리를 만듭니다. 

    $ mkdir <new_dir>
    Copy to Clipboard Toggle word wrap

  3. 다음 명령을 실행하여 디렉토리로 변경하세요. 

    $ cd <new_dir>
    Copy to Clipboard Toggle word wrap

  4. 설치하려는 버전의 이미지 참조를 찾아 다음 명령을 실행하세요. 

    $ oc image extract <full_path_to_registry_image>@sha256:<sha>
    Copy to Clipboard Toggle word wrap

    명령 예

    $ oc image extract registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
    Copy to Clipboard Toggle word wrap

  5. 다음 명령을 실행하여 매니페스트 디렉토리로 변경하세요. 

    $ cd manifests
    Copy to Clipboard Toggle word wrap

  6. 다음 명령을 입력하여 매니페스트 디렉토리의 내용을 확인하세요. 출력에는 확장 프로그램을 설치, 관리, 운영하는 데 필요한 리소스 매니페스트가 나열됩니다. 

    $ tree
    Copy to Clipboard Toggle word wrap

    예 5.9. 출력 예

    .
├── manifests
│   ├── config-logging_v1_configmap.yaml
│   ├── openshift-pipelines-operator-monitor_monitoring.coreos.com_v1_servicemonitor.yaml
│   ├── openshift-pipelines-operator-prometheus-k8s-read-binding_rbac.authorization.k8s.io_v1_rolebinding.yaml
│   ├── openshift-pipelines-operator-read_rbac.authorization.k8s.io_v1_role.yaml
│   ├── openshift-pipelines-operator-rh.clusterserviceversion.yaml
│   ├── operator.tekton.dev_manualapprovalgates.yaml
│   ├── operator.tekton.dev_openshiftpipelinesascodes.yaml
│   ├── operator.tekton.dev_tektonaddons.yaml
│   ├── operator.tekton.dev_tektonchains.yaml
│   ├── operator.tekton.dev_tektonconfigs.yaml
│   ├── operator.tekton.dev_tektonhubs.yaml
│   ├── operator.tekton.dev_tektoninstallersets.yaml
│   ├── operator.tekton.dev_tektonpipelines.yaml
│   ├── operator.tekton.dev_tektonresults.yaml
│   ├── operator.tekton.dev_tektontriggers.yaml
│   ├── tekton-config-defaults_v1_configmap.yaml
│   ├── tekton-config-observability_v1_configmap.yaml
│   ├── tekton-config-read-rolebinding_rbac.authorization.k8s.io_v1_clusterrolebinding.yaml
│   ├── tekton-config-read-role_rbac.authorization.k8s.io_v1_clusterrole.yaml
│   ├── tekton-operator-controller-config-leader-election_v1_configmap.yaml
│   ├── tekton-operator-info_rbac.authorization.k8s.io_v1_rolebinding.yaml
│   ├── tekton-operator-info_rbac.authorization.k8s.io_v1_role.yaml
│   ├── tekton-operator-info_v1_configmap.yaml
│   ├── tekton-operator_v1_service.yaml
│   ├── tekton-operator-webhook-certs_v1_secret.yaml
│   ├── tekton-operator-webhook-config-leader-election_v1_configmap.yaml
│   ├── tekton-operator-webhook_v1_service.yaml
│   ├── tekton-result-read-rolebinding_rbac.authorization.k8s.io_v1_clusterrolebinding.yaml
│   └── tekton-result-read-role_rbac.authorization.k8s.io_v1_clusterrole.yaml
├── metadata
│   ├── annotations.yaml
│   └── properties.yaml
└── root
    └── buildinfo
        ├── content_manifests
        │   └── openshift-pipelines-operator-bundle-container-v1.16.2-3.json
        └── Dockerfile-openshift-pipelines-pipelines-operator-bundle-container-v1.16.2-3
    Copy to Clipboard Toggle word wrap

다음 단계

  • 선호하는 CLI 도구나 텍스트 편집기를 사용하여 매니페스트 디렉토리에 있는 클러스터 서비스 버전(CSV) 파일의 install.spec.clusterpermissions 절의 내용을 봅니다. 다음 예제에서는 Red Hat OpenShift Pipelines Operator의 openshift-pipelines-operator-rh.clusterserviceversion.yaml 파일을 참조합니다.
  • 다음 절차에서 클러스터 역할 파일에 권한을 할당하는 동안 참조로 이 파일을 열어 두세요.
5.1.3.4. 클러스터 확장을 설치하고 관리하는 데 필요한 권한
링크 복사

클러스터 확장의 번들 이미지에 포함된 매니페스트를 검사하여 필요한 권한을 할당해야 합니다. 서비스 계정에는 다음 리소스를 생성하고 관리하기 위해 충분한 역할 기반 액세스 제어(RBAC)가 필요합니다.

중요

최소 권한 원칙을 따르고 실행에 필요한 최소 RBAC를 사용하여 특정 리소스 이름에 대한 권한 범위를 지정합니다.

승인 플러그인
OpenShift Container Platform 클러스터는 OwnerReferencesPermissionEnforcement 입장 플러그인을 사용하므로 클러스터 확장에는 blockOwnerDeletion 및 ownerReferences 종료자를 업데이트할 수 있는 권한이 있어야 합니다.
확장 컨트롤러에 대한 클러스터 역할 및 클러스터 역할 바인딩
설치 서비스 계정이 확장 컨트롤러에 대한 클러스터 역할과 클러스터 역할 바인딩을 만들고 관리할 수 있도록 RBAC를 정의해야 합니다.
클러스터 서비스 버전(CSV)
클러스터 확장의 CSV에 정의된 리소스에 대해 RBAC를 정의해야 합니다.
클러스터 범위 번들 리소스
번들에 포함된 클러스터 범위 리소스를 만들고 관리하려면 RBAC를 정의해야 합니다. 클러스터 범위 리소스가 ClusterRole 과 같은 다른 리소스 유형과 일치하는 경우 resources 또는 resourceNames 필드 아래의 기존 규칙에 리소스를 추가할 수 있습니다.
사용자 정의 리소스 정의(CRD)
확장에 대한 CRD를 생성하고 관리할 수 있도록 설치 서비스 계정에서 RBAC를 정의해야 합니다. 또한 확장 컨트롤러의 서비스 계정에 CRD를 관리할 RBAC 권한을 부여해야 합니다.
배포
확장 컨트롤러에 필요한 서비스 및 구성 맵과 같은 배포를 생성하고 관리하려면 설치 서비스 계정에 대한 RBAC를 정의해야 합니다.
확장 권한
CSV에 정의된 권한 및 클러스터 권한에 대해 RBAC를 포함해야 합니다. 설치 서비스 계정에는 이러한 권한이 필요한 확장 컨트롤러에 이러한 권한을 부여할 수 있는 권한이 필요합니다.
네임스페이스 범위 번들 리소스
모든 네임스페이스 범위 번들 리소스에 대해 RBAC를 정의해야 합니다. 설치 서비스 계정에는 구성 맵 또는 서비스와 같은 리소스를 생성하고 관리할 수 있는 권한이 필요합니다.
역할 및 역할 바인딩
CSV에 정의된 모든 역할이나 역할 바인딩에 대해 RBAC를 정의해야 합니다. 설치 서비스 계정에는 해당 역할과 역할 바인딩을 만들고 관리할 수 있는 권한이 필요합니다.
Service accounts
설치 서비스 계정이 확장 컨트롤러에 대한 서비스 계정을 만들고 관리할 수 있도록 RBAC를 정의해야 합니다.
5.1.3.5. 확장에 대한 클러스터 역할 생성
링크 복사

설치하려는 확장 프로그램의 필수 역할 기반 액세스 제어(RBAC)를 정의하려면 클러스터 서비스 버전(CSV)의 install.spec.clusterpermissions 절과 확장 프로그램의 매니페스트를 주의 깊게 검토해야 합니다. CSV에서 새 매니페스트로 필요한 RBAC를 복사하여 클러스터 역할을 만들어야 합니다.

작은 정보

OLM v1에서 확장 프로그램을 설치하고 업데이트하는 프로세스를 테스트하려면 다음 클러스터 역할을 사용하여 클러스터 관리자 권한을 부여할 수 있습니다. 이 매니페스트는 테스트 목적으로만 사용됩니다. 프로덕션 클러스터에서는 사용하면 안 됩니다. 

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <extension>-installer-clusterrole
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]
Copy to Clipboard Toggle word wrap

다음 절차에서는 Red Hat OpenShift Pipelines Operator의 openshift-pipelines-operator-rh.clusterserviceversion.yaml 파일을 예로 들어 설명합니다. 이 예시에는 OpenShift Pipelines Operator를 설치하고 관리하는 데 필요한 RBAC의 일부가 포함되어 있습니다. 전체 매니페스트를 보려면 "Red Hat OpenShift Pipelines Operator에 대한 클러스터 역할 예"를 참조하세요.

중요

다음 절차를 간소화하고 가독성을 높이기 위해 다음 예제 매니페스트는 클러스터에 범위가 지정된 권한을 사용합니다. 클러스터 대신 확장의 네임스페이스로 범위를 지정하여 일부 권한을 추가로 제한할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 설치하려는 확장 프로그램의 이미지 참조에서 매니페스트를 다운로드했습니다.

프로세스

  1. 다음 예와 유사하게 새로운 클러스터 역할 매니페스트를 만듭니다.

    예제 <확장자>-cluster-role.yaml 파일

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: <extension>-installer-clusterrole
    Copy to Clipboard Toggle word wrap

  2. 다음 예와 유사하게 확장 프로그램의 종료자를 업데이트할 수 있는 권한을 포함하도록 클러스터 역할 매니페스트를 편집합니다.

    Example <extension>-cluster-role.yaml

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
- apiGroups:
  - olm.operatorframework.io
  resources:
  - clusterextensions/finalizers
  verbs:
  - update
  # Scoped to the name of the ClusterExtension
  resourceNames:
  - <metadata_name>
    1
    Copy to Clipboard Toggle word wrap

    1
    확장의 사용자 정의 리소스(CR)에서 metadata.name 필드의 값을 지정합니다.

  3. 확장 프로그램의 CSV 파일에 있는 rules.resources 필드에서 clusterrole 및 clusterrolebindings 값을 검색합니다.

    • 다음 예와 유사하게 API 그룹, 리소스, 동사 및 리소스 이름을 매니페스트에 복사합니다.

      클러스터 역할 매니페스트 예시

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
# ...
# ClusterRoles and ClusterRoleBindings for the controllers of the extension
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterroles
  verbs:
  - create
      1 
      
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterroles
  verbs:
  - get
  - update
  - patch
  - delete
  resourceNames:
      2 
      
  - "*"
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  verbs:
  - get
  - update
  - patch
  - delete
  resourceNames:
  - "*"
# ...
      Copy to Clipboard Toggle word wrap

      1
      create , list , watch 권한은 특정 리소스 이름( resourceNames 필드)에 대해서만 적용될 수 없습니다. 이러한 권한의 범위를 해당 리소스( 리소스 필드)로 지정해야 합니다.
      2
      일부 리소스 이름은 <package_name>.<hash> 형식을 사용하여 생성됩니다. 확장 프로그램을 설치한 후 확장 프로그램 컨트롤러의 클러스터 역할과 클러스터 역할 바인딩에 대한 리소스 이름을 찾아보세요. 이 예에서 와일드카드 문자를 생성된 이름으로 바꾸고 최소 권한의 원칙을 따르세요.

  4. 확장 프로그램의 CSV 파일에 있는 rules.resources 필드에서 customresourcedefinitions 값을 검색합니다.

    • 다음 예와 유사하게 API 그룹, 리소스, 동사 및 리소스 이름을 매니페스트에 복사합니다. 

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
# ...
# Custom resource definitions of the extension
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - update
  - patch
  - delete
  resourceNames:
  - manualapprovalgates.operator.tekton.dev
  - openshiftpipelinesascodes.operator.tekton.dev
  - tektonaddons.operator.tekton.dev
  - tektonchains.operator.tekton.dev
  - tektonconfigs.operator.tekton.dev
  - tektonhubs.operator.tekton.dev
  - tektoninstallersets.operator.tekton.dev
  - tektonpipelines.operator.tekton.dev
  - tektonresults.operator.tekton.dev
  - tektontriggers.operator.tekton.dev
# ...
      Copy to Clipboard Toggle word wrap

  5. rules.resources 사양에 있는 permissions 및 clusterPermissions 값이 있는 절을 CSV 파일에서 검색합니다.

    • 다음 예와 유사하게 API 그룹, 리소스, 동사 및 리소스 이름을 매니페스트에 복사합니다. 

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
# ...
# Excerpt from install.spec.clusterPermissions
- apiGroups:
  - ''
  resources:
  - nodes
  - pods
  - services
  - endpoints
  - persistentvolumeclaims
  - events
  - configmaps
  - secrets
  - pods/log
  - limitranges
  verbs:
  - create
  - list
  - watch
  - delete
  - deletecollection
  - patch
  - get
  - update
- apiGroups:
  - extensions
  - apps
  resources:
  - ingresses
  - ingresses/status
  verbs:
  - create
  - list
  - watch
  - delete
  - patch
  - get
  - update
 # ...
      Copy to Clipboard Toggle word wrap

  6. install.spec.deployments 절에서 CSV 파일의 리소스를 검색합니다.

    • 다음 예와 유사하게 API 그룹, 리소스, 동사 및 리소스 이름을 매니페스트에 복사합니다. 

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
# ...
# Excerpt from install.spec.deployments
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - get
  - update
  - patch
  - delete
  # scoped to the extension controller deployment name
  resourceNames:
  - openshift-pipelines-operator
  - tekton-operator-webhook
# ...
      Copy to Clipboard Toggle word wrap

  7. 확장 프로그램의 CSV 파일에 있는 rules.resources 필드에서 services 및 configmaps 값을 검색합니다.

    • 다음 예와 유사하게 API 그룹, 리소스, 동사 및 리소스 이름을 매니페스트에 복사합니다. 

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
# ...
# Services
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
  - update
  - patch
  - delete
  # scoped to the service name
  resourceNames:
  - openshift-pipelines-operator-monitor
  - tekton-operator
  - tekton-operator-webhook
# configmaps
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - update
  - patch
  - delete
  # scoped to the configmap name
  resourceNames:
  - config-logging
  - tekton-config-defaults
  - tekton-config-observability
  - tekton-operator-controller-config-leader-election
  - tekton-operator-info
  - tekton-operator-webhook-config-leader-election
- apiGroups:
  - operator.tekton.dev
  resources:
  - tekton-config-read-role
  - tekton-result-read-role
  verbs:
  - get
  - watch
  - list
      Copy to Clipboard Toggle word wrap

  8. 다음 명령을 실행하여 클러스터 역할 매니페스트를 클러스터에 추가합니다. 

    $ oc apply -f <extension>-installer-clusterrole.yaml
    Copy to Clipboard Toggle word wrap

    명령 예

    $ oc apply -f pipelines-installer-clusterrole.yaml
    Copy to Clipboard Toggle word wrap

5.1.3.6. Red Hat OpenShift Pipelines Operator에 대한 클러스터 역할 예
링크 복사

OpenShift Pipelines Operator에 대한 전체 클러스터 역할 매니페스트는 다음 예를 참조하세요. 

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pipelines-installer-clusterrole
rules:
- apiGroups:
  - olm.operatorframework.io
  resources:
  - clusterextensions/finalizers
  verbs:
  - update
  # Scoped to the name of the ClusterExtension
  resourceNames:
  - pipes # the value from <metadata.name> from the extension's custom resource (CR)
# ClusterRoles and ClusterRoleBindings for the controllers of the extension
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterroles
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterroles
  verbs:
  - get
  - update
  - patch
  - delete
  resourceNames:
  - "*"
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  verbs:
  - get
  - update
  - patch
  - delete
  resourceNames:
  - "*"
# Extension's custom resource definitions
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  verbs:
  - get
  - update
  - patch
  - delete
  resourceNames:
  - manualapprovalgates.operator.tekton.dev
  - openshiftpipelinesascodes.operator.tekton.dev
  - tektonaddons.operator.tekton.dev
  - tektonchains.operator.tekton.dev
  - tektonconfigs.operator.tekton.dev
  - tektonhubs.operator.tekton.dev
  - tektoninstallersets.operator.tekton.dev
  - tektonpipelines.operator.tekton.dev
  - tektonresults.operator.tekton.dev
  - tektontriggers.operator.tekton.dev
- apiGroups:
  - ''
  resources:
  - nodes
  - pods
  - services
  - endpoints
  - persistentvolumeclaims
  - events
  - configmaps
  - secrets
  - pods/log
  - limitranges
  verbs:
  - create
  - list
  - watch
  - delete
  - deletecollection
  - patch
  - get
  - update
- apiGroups:
  - extensions
  - apps
  resources:
  - ingresses
  - ingresses/status
  verbs:
  - create
  - list
  - watch
  - delete
  - patch
  - get
  - update
- apiGroups:
  - ''
  resources:
  - namespaces
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  - deployments/finalizers
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - monitoring.coreos.com
  resources:
  - servicemonitors
  verbs:
  - get
  - create
  - delete
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterroles
  - roles
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
  - bind
  - escalate
- apiGroups:
  - ''
  resources:
  - serviceaccounts
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
  - impersonate
- apiGroups:
  - rbac.authorization.k8s.io
  resources:
  - clusterrolebindings
  - rolebindings
  verbs:
  - get
  - update
  - delete
  - patch
  - create
  - list
  - watch
- apiGroups:
  - apiextensions.k8s.io
  resources:
  - customresourcedefinitions
  - customresourcedefinitions/status
  verbs:
  - get
  - create
  - update
  - delete
  - list
  - patch
  - watch
- apiGroups:
  - admissionregistration.k8s.io
  resources:
  - mutatingwebhookconfigurations
  - validatingwebhookconfigurations
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
- apiGroups:
  - build.knative.dev
  resources:
  - builds
  - buildtemplates
  - clusterbuildtemplates
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
- apiGroups:
  - extensions
  resources:
  - deployments
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
- apiGroups:
  - extensions
  resources:
  - deployments/finalizers
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
- apiGroups:
  - operator.tekton.dev
  resources:
  - '*'
  - tektonaddons
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - tekton.dev
  - triggers.tekton.dev
  - operator.tekton.dev
  - pipelinesascode.tekton.dev
  resources:
  - '*'
  verbs:
  - add
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - dashboard.tekton.dev
  resources:
  - '*'
  - tektonaddons
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - security.openshift.io
  resources:
  - securitycontextconstraints
  verbs:
  - use
  - get
  - list
  - create
  - update
  - delete
- apiGroups:
  - events.k8s.io
  resources:
  - events
  verbs:
  - create
- apiGroups:
  - route.openshift.io
  resources:
  - routes
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - get
  - list
  - create
  - update
  - delete
  - patch
  - watch
- apiGroups:
  - console.openshift.io
  resources:
  - consoleyamlsamples
  - consoleclidownloads
  - consolequickstarts
  - consolelinks
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - autoscaling
  resources:
  - horizontalpodautoscalers
  verbs:
  - delete
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - policy
  resources:
  - poddisruptionbudgets
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - monitoring.coreos.com
  resources:
  - servicemonitors
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - batch
  resources:
  - jobs
  - cronjobs
  verbs:
  - delete
  - deletecollection
  - create
  - patch
  - get
  - list
  - update
  - watch
- apiGroups:
  - ''
  resources:
  - namespaces/finalizers
  verbs:
  - update
- apiGroups:
  - resolution.tekton.dev
  resources:
  - resolutionrequests
  - resolutionrequests/status
  verbs:
  - get
  - list
  - watch
  - create
  - delete
  - update
  - patch
- apiGroups:
  - console.openshift.io
  resources:
  - consoleplugins
  verbs:
  - get
  - list
  - watch
  - create
  - delete
  - update
  - patch
# Deployments specified in install.spec.deployments
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - apps
  resources:
  - deployments
  verbs:
  - get
  - update
  - patch
  - delete
  # scoped to the extension controller deployment name
  resourceNames:
  - openshift-pipelines-operator
  - tekton-operator-webhook
# Service accounts in the CSV
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - create
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - serviceaccounts
  verbs:
  - get
  - update
  - patch
  - delete
  # scoped to the extension controller's deployment service account
  resourceNames:
  - openshift-pipelines-operator
# Services
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
  - update
  - patch
  - delete
  # scoped to the service name
  resourceNames:
  - openshift-pipelines-operator-monitor
  - tekton-operator
  - tekton-operator-webhook
# configmaps
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - update
  - patch
  - delete
  # scoped to the configmap name
  resourceNames:
  - config-logging
  - tekton-config-defaults
  - tekton-config-observability
  - tekton-operator-controller-config-leader-election
  - tekton-operator-info
  - tekton-operator-webhook-config-leader-election
- apiGroups:
  - operator.tekton.dev
  resources:
  - tekton-config-read-role
  - tekton-result-read-role
  verbs:
  - get
  - watch
  - list
---
Copy to Clipboard Toggle word wrap
5.1.3.7. 확장에 대한 클러스터 역할 바인딩 생성
링크 복사

서비스 계정과 클러스터 역할을 만든 후에는 클러스터 역할 바인딩 매니페스트를 사용하여 클러스터 역할을 서비스 계정에 바인딩해야 합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.

  • 설치하려는 확장 프로그램에 대해 다음 리소스를 만들고 적용했습니다.

    • 네임스페이스
    • 서비스 계정
    • 클러스터 역할

프로세스

  1. 다음 예와 유사하게 클러스터 역할을 서비스 계정에 바인딩하기 위해 클러스터 역할 바인딩을 만듭니다. 

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: <extension>-installer-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: <extension>-installer-clusterrole
subjects:
- kind: ServiceAccount
  name: <extension>-installer
  namespace: <namespace>
    Copy to Clipboard Toggle word wrap

    예 5.10. 파이프라인-클러스터-역할-바인딩.yaml 파일 예시

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: pipelines-installer-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: pipelines-installer-clusterrole
subjects:
- kind: ServiceAccount
  name: pipelines-installer
  namespace: pipelines
    Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 클러스터 역할 바인딩을 적용합니다. 

    $ oc apply -f pipelines-cluster-role-binding.yaml
    Copy to Clipboard Toggle word wrap

5.1.4. 모든 네임스페이스에 클러스터 확장 설치
링크 복사

사용자 정의 리소스(CR)를 만들고 클러스터에 적용하여 카탈로그에서 확장을 설치할 수 있습니다. Operator Lifecycle Manager(OLM) v1은 클러스터에 범위가 지정된 registry+v1 번들 형식의 OLM(클래식) Operator를 포함한 클러스터 확장 설치를 지원합니다. 자세한 내용은 지원되는 확장 프로그램을 참조하세요.

참고

OpenShift Container Platform 4.19의 경우 OLM v1에 대한 문서화된 절차는 CLI 기반입니다. 또는 관리자는 YAML 가져오기 및 검색 페이지와 같은 일반적인 방법을 사용하여 웹 콘솔에서 관련 객체를 만들고 볼 수 있습니다. 하지만 기존의 OperatorHub 및 설치된 운영자 페이지에는 아직 OLM v1 구성 요소가 표시되지 않습니다.

사전 요구 사항

  • 설치하려는 확장 프로그램을 설치, 업데이트, 관리하는 데 필요한 서비스 계정을 만들고 역할 기반 액세스 제어(RBAC)를 충분히 할당했습니다. 자세한 내용은 "클러스터 확장 권한"을 참조하세요.

프로세스

  1. 다음 예와 유사한 CR을 만듭니다. 

    apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    name: <clusterextension_name>
  spec:
    namespace: <installed_namespace>
    1 
    
    serviceAccount:
      name: <service_account_installer_name>
    2 
    
    source:
      sourceType: Catalog
      catalog:
        packageName: <package_name>
        channels:
          - <channel_name>
    3 
    
        version: <version_or_version_range>
    4 
    
        upgradeConstraintPolicy: CatalogProvided
    5
    Copy to Clipboard Toggle word wrap
    1
    번들을 설치할 네임스페이스(예: 파이프라인 또는 my-extension ) 를 지정합니다. 확장 프로그램은 여전히 클러스터 범위이며 다른 네임스페이스에 설치된 리소스를 포함할 수 있습니다.
    2
    확장 프로그램을 설치, 업데이트, 관리하기 위해 만든 서비스 계정의 이름을 지정합니다.
    3
    선택 사항: 파이프라인-1.14 또는 최신 과 같이 채널 이름을 배열로 지정합니다.
    4
    선택 사항: 설치 또는 업데이트하려는 패키지의 버전 또는 버전 범위(예: 1.14.0 , 1.14.x 또는 >=1.16 )를 지정합니다. 자세한 내용은 "대상 버전을 지정하는 사용자 정의 리소스(CR) 예시" 및 "버전 범위 지원"을 참조하세요.
    5
    선택 사항: 업그레이드 제약 정책을 지정합니다. 지정하지 않으면 기본 설정은 CatalogProvided 입니다. CatalogProvided 설정은 새 버전이 패키지 작성자가 설정한 업그레이드 제약 조건을 충족하는 경우에만 업데이트됩니다. 업데이트나 롤백을 강제로 실행하려면 필드를 SelfCertified 로 설정합니다. 자세한 내용은 "업데이트 또는 롤백 강제 실행"을 참조하세요.

예제 pipelines-operator.yaml CR

apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: openshift-pipelines-operator-rh
      version: "1.14.x"
Copy to Clipboard Toggle word wrap

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

    $ oc apply -f pipeline-operator.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    clusterextension.olm.operatorframework.io/pipelines-operator created
    Copy to Clipboard Toggle word wrap

검증

  1. 다음 명령을 실행하여 YAML 형식으로 운영자 또는 확장 프로그램의 CR을 확인하세요. 

    $ oc get clusterextension pipelines-operator -o yaml
    Copy to Clipboard Toggle word wrap

    예 5.11. 출력 예

    apiVersion: v1
items:
- apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"1.14.x"},"sourceType":"Catalog"}}}
    creationTimestamp: "2025-02-18T21:48:13Z"
    finalizers:
    - olm.operatorframework.io/cleanup-unpack-cache
    - olm.operatorframework.io/cleanup-contentmanager-cache
    generation: 1
    name: pipelines-operator
    resourceVersion: "72725"
    uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
  spec:
    namespace: pipelines
    serviceAccount:
      name: pipelines-installer
    source:
      catalog:
        packageName: openshift-pipelines-operator-rh
        upgradeConstraintPolicy: CatalogProvided
        version: 1.14.x
      sourceType: Catalog
  status:
    conditions:
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: Deprecated
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: PackageDeprecated
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: ChannelDeprecated
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: BundleDeprecated
    - lastTransitionTime: "2025-02-18T21:48:16Z"
      message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
        successfully
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Installed
    - lastTransitionTime: "2025-02-18T21:48:16Z"
      message: desired state reached
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Progressing
    install:
      bundle:
        name: openshift-pipelines-operator-rh.v1.14.5
        version: 1.14.5
kind: List
metadata:
  resourceVersion: ""
    Copy to Clipboard Toggle word wrap

    다음과 같습니다.

    spec.channel
    확장 프로그램의 CR에 정의된 채널을 표시합니다.
    spec.version
    확장 프로그램의 CR에 정의된 버전 또는 버전 범위를 표시합니다.
    status.conditions
    확장 프로그램의 상태 및 건강에 대한 정보를 표시합니다.
    유형: 더 이상 사용되지 않음

    다음 중 하나 이상이 더 이상 사용되지 않는지 여부를 표시합니다.

    유형: 패키지 더 이상 사용되지 않음
    해결된 패키지가 더 이상 사용되지 않는지 여부를 표시합니다.
    유형: 채널더 이상 사용되지 않음
    해결된 채널이 더 이상 사용되지 않는지 여부를 표시합니다.
    유형: 번들더 이상 사용되지 않음
    해결된 번들이 더 이상 사용되지 않는지 여부를 표시합니다.

    상태 필드의 False 값은 이유가 "더 이상 사용되지 않는 조건"임을 나타냅니다. 상태 필드의 값이 True인 경우 이유가 "더 이상 사용되지 않는 조건은 더 이상 사용되지 않습니다."임을 나타냅니다.

    installedBundle.name
    설치된 번들의 이름을 표시합니다.
    installedBundle.version
    설치된 번들의 버전을 표시합니다.

5.1.5. 특정 네임스페이스에 클러스터 확장 배포(기술 미리 보기)
링크 복사

설치 모드는 Operator Lifecycle Manager(OLM) Classic의 멀티 테넌시 기능입니다. OLM v1은 다중 테넌시를 지원하지 않으며 기본적으로 AllNamespaces 설치 모드를 사용하여 클러스터 확장을 클러스터에 배포합니다.

하지만 일부 기존 클러스터 확장 프로그램은 AllNamespaces 설치 모드를 지원하지 않습니다. registry+v1 Operator 번들의 기술 미리 보기 기능으로 OwnNamespace 또는 SingleNamespace 설치 모드를 사용하여 특정 네임스페이스에 확장 프로그램을 배포할 수 있습니다.

MultiNamespace 설치 모드는 지원되지 않습니다. 따라서 클러스터에 동일한 Operator를 여러 번 설치할 수 없습니다.

중요

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

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

자세한 내용은 "지원되는 확장 프로그램"을 참조하세요.

사전 요구 사항

  • 클러스터 관리자 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스
  • 클러스터에서 활성화된 TechPreviewNoUpgrade 기능 세트
  • OwnNamespace 또는 SingleNamespace 설치 모드를 지원하는 연산자

프로세스

  1. 다음 예와 유사한 사용자 정의 리소스(CR)를 만듭니다.

    <cluster-extension-cr>.yaml 파일 예시

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

    다음과 같습니다.

    네임스페이스

    클러스터 확장을 배포할 네임스페이스를 지정합니다.

    • 네임스페이스 매개변수가 비어 있거나 주석이 없으면 확장은 AllNamespaces 설치 모드를 사용하여 배포됩니다.
    • 네임스페이스 매개변수가 spec.namespace 필드의 installed_namespace 매개변수와 동일한 값인 경우 확장은 OwnNamespace 설치 모드를 사용하여 배포됩니다.
    • 네임스페이스 매개변수가 installed_namespace 매개변수와 다른 네임스페이스를 지정하는 경우 확장은 SingleNamespace 설치 모드를 사용하여 배포됩니다.

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

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

5.1.6. 클러스터 확장에 대한 사전 권한 확인(기술 미리 보기)
링크 복사

확장 프로그램을 설치하려고 하면 운영자 컨트롤러가 설치 프로세스의 테스트 실행을 수행합니다. 이 연습 실행은 지정된 서비스 계정이 확장 프로그램을 설치하는 데 필요한 모든 작업을 수행할 수 있는지 확인합니다. 여기에는 번들의 모든 Kubernetes 객체를 생성하는 것과 번들에서 정의한 역할과 바인딩에 대한 역할 기반 액세스 제어(RBAC) 규칙을 생성하는 것이 포함됩니다.

중요

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

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

서비스 계정에 필요한 RBAC 규칙이 없으면 실제 설치가 진행되기 전에 사전 검사가 실패합니다. 사전 비행 검사에 실패하면 운영자 컨트롤러는 확장 프로그램의 상태 조건과 운영자 컨트롤러의 로그에 오류를 보고합니다.

설치를 진행하려면 역할과 바인딩을 업데이트하여 서비스 계정에 누락된 권한을 부여하고 변경 사항을 적용합니다. 오류가 없으면 운영자 컨트롤러가 업데이트된 권한을 조정하고 설치를 완료합니다.

5.1.6.1. 사전 비행 권한 확인의 보고서 예
링크 복사

다음 보고서는 서비스 계정에 다음과 같은 누락된 권한이 필요하다는 것을 나타냅니다.

  • 클러스터 전체의 핵심 API 그룹에서 서비스 리소스에 대한 목록 및 감시 작업을 수행하기 위한 RBAC 규칙
  • 파이프라인 네임스페이스에 대한 앱 API 그룹의 배포 리소스에 대한 작업 생성 을 수행하기 위한 RBAC 규칙

클러스터 확장의 상태 조건에서 사전 권한 확인을 통해 보고서에 액세스할 수 있습니다. oc describe clusterextension 명령은 상태 조건을 포함하여 클러스터 확장에 대한 정보를 출력합니다.

명령 예

$ oc describe clusterextension <extension_name>
Copy to Clipboard Toggle word wrap

보고서 예시

apiVersion: v1
items:
- apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
...
Conditions:
  Type:    Progressing
  Status:  False
  Reason:  Retrying
  Message: pre-authorization failed: service account requires the following permissions to manage cluster extension:
           Namespace:"" APIGroups:[] Resources:[services] Verbs:[list,watch]
           Namespace:"pipelines" APIGroups:["apps"] Resources:[deployments] Verbs:[create]
Copy to Clipboard Toggle word wrap

네임스페이스
예를 들어 파이프라인 네임스페이스와 같이 네임스페이스 수준에서 필요한 RBAC 규칙의 범위를 지정합니다. 빈 네임스페이스 값 "" 은 클러스터에 대한 권한 범위를 지정해야 함을 나타냅니다.
API그룹

필요한 권한이 적용되는 API 그룹의 이름을 지정합니다. API 그룹의 빈 값 [] 은 권한이 핵심 API 그룹에 적용됨을 나타냅니다. 예를 들어, 서비스, 비밀, 구성 맵은 모두 핵심 리소스입니다.

리소스가 지정된 API 그룹에 속하는 경우 보고서는 해당 이름을 괄호 사이에 나열합니다. 예를 들어, APIGroups:[apps] 의 값은 확장 프로그램에 앱 API 그룹의 리소스에 대한 RBAC 규칙이 필요함을 나타냅니다.

Resources
권한이 필요한 리소스 유형을 지정합니다. 예를 들어, 서비스, 비밀, 사용자 지정 리소스 정의는 일반적인 리소스 유형입니다.
동사
서비스 계정에 수행 권한이 필요한 작업 또는 동사를 지정합니다. 보고서에 여러 동사가 나열된 경우 나열된 모든 동사에 RBAC 규칙이 필요합니다.
5.1.6.2. 일반적인 권한 오류
링크 복사
동사가 누락되었습니다
서비스 계정에는 필요한 작업을 수행할 수 있는 권한이 없습니다. 이 문제를 해결하려면 역할과 바인딩을 업데이트하거나 생성하여 필요한 권한을 부여하세요. 역할과 역할 바인딩은 네임스페이스에 대한 리소스 권한을 정의합니다. 클러스터 역할과 클러스터 역할 바인딩은 클러스터에 대한 리소스 권한을 정의합니다.
권한 상승
서비스 계정에는 확장 기능에 필요한 역할이나 클러스터 역할을 생성할 수 있는 권한이 없습니다. 이런 일이 발생하면 사전 검사에서 권한 상승을 방지하기 위해 동사가 누락되었다고 보고합니다. 이 문제를 해결하려면 서비스 계정에 역할을 만들 수 있는 충분한 권한을 부여하세요.
역할 참조가 누락되었습니다
확장 기능은 Operator Controller가 찾을 수 없는 역할이나 클러스터 역할을 참조합니다. 이런 일이 발생하면 사전 검사에서 누락된 역할이 나열되고 권한 평가 오류 가 보고됩니다. 이 문제를 해결하려면 역할 및 클러스터 역할을 만들거나 업데이트하여 모든 역할 참조가 존재하는지 확인하세요.

5.1.7. 클러스터 확장 업데이트
링크 복사

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

사전 요구 사항

  • Operator나 확장 프로그램이 설치되어 있습니다.
  • jq CLI 도구를 설치했습니다.
  • opm CLI 도구를 설치했습니다.

프로세스

  1. 다음 단계를 완료하여 카탈로그 파일의 로컬 복사본에서 채널 및 버전 정보를 확인하기 위해 패키지를 검사하세요.

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

      $ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .schema == "olm.channel" ) \
  | select( .package == "openshift-pipelines-operator-rh") | .name'
      Copy to Clipboard Toggle word wrap

      예 5.12. 명령 예

      $ opm render registry.redhat.io/redhat/redhat-operator-index:v4.19 \
  | jq -s '.[] | select( .schema == "olm.channel" ) \
  | select( .package == "openshift-pipelines-operator-rh") | .name'
      Copy to Clipboard Toggle word wrap

      예 5.13. 출력 예

      "latest"
"pipelines-1.14"
"pipelines-1.15"
"pipelines-1.16"
"pipelines-1.17"
      Copy to Clipboard Toggle word wrap

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

      $ opm render <catalog_registry_url>:<tag> \
  | jq -s '.[] | select( .package == "<package_name>" ) \
  | select( .schema == "olm.channel" ) \
  | select( .name == "<channel_name>" ) | .entries \
  | .[] | .name'
      Copy to Clipboard Toggle word wrap

      예 5.14. 명령 예

      $ opm render registry.redhat.io/redhat/redhat-operator-index:v4.19 \
  | jq -s '.[] | select( .package == "openshift-pipelines-operator-rh" ) \
  | select( .schema == "olm.channel" ) | select( .name == "latest" ) \
  | .entries | .[] | .name'
      Copy to Clipboard Toggle word wrap

      예 5.15. 출력 예

      "openshift-pipelines-operator-rh.v1.15.0"
"openshift-pipelines-operator-rh.v1.16.0"
"openshift-pipelines-operator-rh.v1.17.0"
"openshift-pipelines-operator-rh.v1.17.1"
      Copy to Clipboard Toggle word wrap

  2. 다음 명령을 실행하여 운영자 또는 확장 프로그램의 CR에 지정된 버전이나 채널을 확인하세요. 

    $ oc get clusterextension <operator_name> -o yaml
    Copy to Clipboard Toggle word wrap

    명령 예

    $ oc get clusterextension pipelines-operator -o yaml
    Copy to Clipboard Toggle word wrap

    예 5.16. 출력 예

    apiVersion: v1
items:
- apiVersion: olm.operatorframework.io/v1
  kind: ClusterExtension
  metadata:
    annotations:
      kubectl.kubernetes.io/last-applied-configuration: |
        {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"1.14.x"},"sourceType":"Catalog"}}}
    creationTimestamp: "2025-02-18T21:48:13Z"
    finalizers:
    - olm.operatorframework.io/cleanup-unpack-cache
    - olm.operatorframework.io/cleanup-contentmanager-cache
    generation: 1
    name: pipelines-operator
    resourceVersion: "72725"
    uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
  spec:
    namespace: pipelines
    serviceAccount:
      name: pipelines-installer
    source:
      catalog:
        packageName: openshift-pipelines-operator-rh
        upgradeConstraintPolicy: CatalogProvided
        version: 1.14.x
      sourceType: Catalog
  status:
    conditions:
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: Deprecated
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: PackageDeprecated
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: ChannelDeprecated
    - lastTransitionTime: "2025-02-18T21:48:13Z"
      message: ""
      observedGeneration: 1
      reason: Deprecated
      status: "False"
      type: BundleDeprecated
    - lastTransitionTime: "2025-02-18T21:48:16Z"
      message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:f7b19ce26be742c4aaa458d37bc5ad373b5b29b20aaa7d308349687d3cbd8838
        successfully
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Installed
    - lastTransitionTime: "2025-02-18T21:48:16Z"
      message: desired state reached
      observedGeneration: 1
      reason: Succeeded
      status: "True"
      type: Progressing
    install:
      bundle:
        name: openshift-pipelines-operator-rh.v1.14.5
        version: 1.14.5
kind: List
metadata:
  resourceVersion: ""
    Copy to Clipboard Toggle word wrap

  3. 다음 방법 중 하나를 사용하여 CR을 편집하세요.

    • 운영자나 확장 프로그램을 1.15.0 과 같은 특정 버전으로 고정하려면 다음 예와 비슷하게 CR을 편집하세요.

      예제 pipelines-operator.yaml CR

      apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: openshift-pipelines-operator-rh
      version: "1.15.0"
      1
      Copy to Clipboard Toggle word wrap

      1
      버전을 1.14.x 에서 1.15.0 으로 업데이트하세요

    • 허용되는 업데이트 버전 범위를 정의하려면 다음 예와 유사하게 CR을 편집하세요.

      버전 범위가 지정된 CR 예

      apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: openshift-pipelines-operator-rh
      version: ">1.15, <1.17"
      1
      Copy to Clipboard Toggle word wrap

      1
      원하는 버전 범위가 버전 1.15 보다 크고 1.17 보다 작음을 지정합니다. 자세한 내용은 "버전 범위 지원" 및 "버전 비교 문자열"을 참조하세요.

    • 채널에서 확인할 수 있는 최신 버전으로 업데이트하려면 다음 예와 유사하게 CR을 편집하세요.

      지정된 채널이 있는 CR 예

      apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: openshift-pipelines-operator-rh
      channels:
        - latest
      1
      Copy to Clipboard Toggle word wrap

      1
      지정된 채널에서 해결 가능한 최신 릴리스를 설치합니다. 채널 업데이트는 자동으로 설치됩니다. 값을 배열로 입력합니다.

    • 채널과 버전 또는 버전 범위를 지정하려면 다음 예와 유사하게 CR을 편집하세요.

      지정된 채널 및 버전 범위가 있는 CR 예

      apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: pipelines-operator
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    sourceType: Catalog
    catalog:
      packageName: openshift-pipelines-operator-rh
      channels:
        - latest
      version: "<1.16"
      Copy to Clipboard Toggle word wrap

      자세한 내용은 "대상 버전을 지정하는 사용자 정의 리소스(CR) 예시"를 참조하세요.

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

    $ oc apply -f pipelines-operator.yaml
    Copy to Clipboard Toggle word wrap

    출력 예

    clusterextension.olm.operatorframework.io/pipelines-operator configured
    Copy to Clipboard Toggle word wrap

검증

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

    $ oc get clusterextension pipelines-operator -o yaml
    Copy to Clipboard Toggle word wrap

    예 5.17. 출력 예

    apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"\u003c1.16"},"sourceType":"Catalog"}}}
  creationTimestamp: "2025-02-18T21:48:13Z"
  finalizers:
  - olm.operatorframework.io/cleanup-unpack-cache
  - olm.operatorframework.io/cleanup-contentmanager-cache
  generation: 2
  name: pipes
  resourceVersion: "90693"
  uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    catalog:
      packageName: openshift-pipelines-operator-rh
      upgradeConstraintPolicy: CatalogProvided
      version: <1.16
    sourceType: Catalog
status:
  conditions:
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: Deprecated
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: PackageDeprecated
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: ChannelDeprecated
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: BundleDeprecated
  - lastTransitionTime: "2025-02-18T21:48:16Z"
    message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd
      successfully
    observedGeneration: 2
    reason: Succeeded
    status: "True"
    type: Installed
  - lastTransitionTime: "2025-02-18T21:48:16Z"
    message: desired state reached
    observedGeneration: 2
    reason: Succeeded
    status: "True"
    type: Progressing
  install:
    bundle:
      name: openshift-pipelines-operator-rh.v1.15.2
      version: 1.15.2
    Copy to Clipboard Toggle word wrap

문제 해결

  • 더 이상 사용되지 않거나 존재하지 않는 대상 버전이나 채널을 지정한 경우 다음 명령을 실행하여 확장 프로그램의 상태를 확인할 수 있습니다. 

    $ oc get clusterextension <operator_name> -o yaml
    Copy to Clipboard Toggle word wrap

    예 5.18. 존재하지 않는 버전에 대한 예시 출력

    apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"olm.operatorframework.io/v1","kind":"ClusterExtension","metadata":{"annotations":{},"name":"pipes"},"spec":{"namespace":"pipelines","serviceAccount":{"name":"pipelines-installer"},"source":{"catalog":{"packageName":"openshift-pipelines-operator-rh","version":"9.x"},"sourceType":"Catalog"}}}
  creationTimestamp: "2025-02-18T21:48:13Z"
  finalizers:
  - olm.operatorframework.io/cleanup-unpack-cache
  - olm.operatorframework.io/cleanup-contentmanager-cache
  generation: 3
  name: pipes
  resourceVersion: "93334"
  uid: e18b13fb-a96d-436f-be75-a9a0f2b07993
spec:
  namespace: pipelines
  serviceAccount:
    name: pipelines-installer
  source:
    catalog:
      packageName: openshift-pipelines-operator-rh
      upgradeConstraintPolicy: CatalogProvided
      version: 9.x
    sourceType: Catalog
status:
  conditions:
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: Deprecated
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: PackageDeprecated
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: ChannelDeprecated
  - lastTransitionTime: "2025-02-18T21:48:13Z"
    message: ""
    observedGeneration: 2
    reason: Deprecated
    status: "False"
    type: BundleDeprecated
  - lastTransitionTime: "2025-02-18T21:48:16Z"
    message: Installed bundle registry.redhat.io/openshift-pipelines/pipelines-operator-bundle@sha256:8a593c1144709c9aeffbeb68d0b4b08368f528e7bb6f595884b2474bcfbcafcd
      successfully
    observedGeneration: 3
    reason: Succeeded
    status: "True"
    type: Installed
  - lastTransitionTime: "2025-02-18T21:48:16Z"
    message: 'error upgrading from currently installed version "1.15.2": no bundles
      found for package "openshift-pipelines-operator-rh" matching version "9.x"'
    observedGeneration: 3
    reason: Retrying
    status: "True"
    type: Progressing
  install:
    bundle:
      name: openshift-pipelines-operator-rh.v1.15.2
      version: 1.15.2
    Copy to Clipboard Toggle word wrap

5.1.8. 운영자 삭제
링크 복사

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

사전 요구 사항

  • 카탈로그가 설치되었습니다.
  • Operator가 설치되어 있습니다.

프로세스

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

    $ oc delete clusterextension <operator_name>
    Copy to Clipboard Toggle word wrap

    출력 예

    clusterextension.olm.operatorframework.io "<operator_name>" deleted
    Copy to Clipboard Toggle word wrap

검증

  • 다음 명령을 실행하여 Operator와 해당 리소스가 삭제되었는지 확인하세요.

    • 다음 명령을 실행하여 Operator가 삭제되었는지 확인하세요. 

      $ oc get clusterextensions
      Copy to Clipboard Toggle word wrap

      출력 예

      No resources found
      Copy to Clipboard Toggle word wrap

    • 다음 명령을 실행하여 Operator의 시스템 네임스페이스가 삭제되었는지 확인합니다. 

      $ oc get ns <operator_name>-system
      Copy to Clipboard Toggle word wrap

      출력 예

      Error from server (NotFound): namespaces "<operator_name>-system" not found
      Copy to Clipboard Toggle word wrap

5.2. 확장 리소스에 대한 사용자 액세스
링크 복사

클러스터 확장이 설치되고 Operator Lifecycle Manager(OLM) v1에서 관리되면 확장은 클러스터에서 새로운 API 리소스를 노출하는 CustomResourceDefinition 개체(CRD)를 제공하는 경우가 많습니다. 클러스터 관리자는 일반적으로 이러한 리소스에 대한 전체 관리 액세스 권한을 가지고 있는 반면, 클러스터 관리자가 아닌 사용자나 일반 사용자는 충분한 권한이 부족할 수 있습니다.

OLM v1은 설치된 확장 프로그램에서 제공하는 API와 일반 사용자가 상호 작용할 수 있도록 역할 기반 액세스 제어(RBAC)를 자동으로 구성하거나 관리하지 않습니다. 클러스터 관리자는 이러한 사용자에 대한 사용자 정의 리소스(CR)를 생성, 보기 또는 편집하기 위해 필요한 RBAC 정책을 정의해야 합니다.

참고

확장 리소스에 대한 사용자 액세스에 대해 설명된 RBAC 권한은 클러스터 확장 자체의 OLM v1 기반 초기 설치를 활성화하기 위해 서비스 계정에 추가해야 하는 권한과 다릅니다. 확장을 설치하는 동안 RBAC 요구 사항에 대한 자세한 내용은 확장 관리의 "클러스터 확장 권한"을 참조하십시오.

5.2.1. 사용자를 위한 공통 기본 클러스터 역할
링크 복사

설치된 클러스터 확장에는 확장에서 제공하는 API 리소스에 대한 일반 사용자의 역할 기반 액세스 제어(RBAC)를 결정하기 위한 기본 클러스터 역할이 포함될 수 있습니다. 일반적인 클러스터 역할 집합은 다음 정책과 유사할 수 있습니다.

클러스터 역할 보기
클러스터 전체의 지정된 API 리소스의 모든 사용자 정의 리소스(CR) 개체에 대한 읽기 전용 액세스 권한을 부여합니다. 수정 권한 없이 리소스에 대한 가시성이 필요한 일반 사용자를 대상으로 합니다. 모니터링 목적이나 제한된 접근 권한으로 보기에 이상적입니다.
클러스터 역할 편집
사용자가 클러스터 내의 모든 CR 오브젝트를 수정할 수 있습니다. 사용자가 리소스를 생성, 업데이트, 삭제할 수 있으므로 리소스를 관리해야 하지만 RBAC를 제어하거나 다른 사람의 권한을 관리해서는 안 되는 팀 구성원에게 적합합니다.
관리자 클러스터 역할
클러스터 전체의 지정된 API 리소스에 대한 모든 사용자 정의 리소스 개체에 대한 생성 , 업데이트 , 삭제 동사를 포함한 전체 권한을 제공합니다.

5.2.2. 클러스터 확장에서 노출된 API 그룹 및 리소스 찾기
링크 복사

사용자에게 클러스터 확장 리소스에 대한 액세스 권한을 부여하기 위한 적절한 RBAC 정책을 만들려면 설치된 확장에서 어떤 API 그룹과 리소스가 노출되는지 알아야 합니다. 관리자는 OpenShift CLI( oc )를 사용하여 클러스터에 설치된 사용자 정의 리소스 정의(CRD)를 검사할 수 있습니다.

사전 요구 사항

  • 클러스터에 클러스터 확장이 설치되었습니다.

프로세스

  • 해당 확장에서 소유한 CRD만 찾으려면 이름으로 특정 클러스터 확장을 대상으로 하는 라벨 선택기를 지정하는 동안 설치된 CRD를 나열하려면 다음 명령을 실행합니다. 

    $ oc get crds -l 'olm.operatorframework.io/owner-kind=ClusterExtension,olm.operatorframework.io/owner-name=<cluster_extension_name>'
    Copy to Clipboard Toggle word wrap

  • 또는 설치된 모든 CRD를 검색하여 CRD 이름으로 개별적으로 검사할 수 있습니다.

    1. 다음 명령을 실행하여 현재 클러스터에 설치된 모든 사용 가능한 사용자 정의 리소스 정의(CRD)를 나열합니다. 

      $ oc get crds
      Copy to Clipboard Toggle word wrap

      출력에서 원하는 CRD를 찾으세요.

    2. 다음 명령을 실행하여 개별 CRD를 추가로 검사하여 API 그룹을 찾습니다. 

      $ oc get crd <crd_name> -o yaml
      Copy to Clipboard Toggle word wrap

클러스터 관리자는 사용자 지정 역할 바인딩을 사용하여 확장 리소스에 대한 사용자 액세스 권한을 부여하도록 RBAC(역할 기반 액세스 제어) 정책을 수동으로 생성하고 구성할 수 있습니다.

사전 요구 사항

  • 클러스터에 클러스터 확장이 설치되어 있습니다.
  • "클러스터 확장에 의해 노출되는 API 그룹 및 리소스 찾기"에 설명된 대로 API 그룹 및 리소스 이름 목록이 있습니다.

프로세스

  1. 설치된 클러스터 확장에서 기본 클러스터 역할을 제공하지 않는 경우 하나 이상의 역할을 수동으로 생성합니다.

    1. "사용자를 위한 공통 기본 클러스터 역할"에 설명된 역할 세트에 대한 사용 사례를 고려하십시오.

      예를 들어 다음 ClusterRole 오브젝트 정의 중 하나 이상을 생성하여 < cluster_extension_api_group > 및 < cluster_extension_custom_resource >를 설치된 클러스터 확장에서 제공하는 실제 API 그룹 및 리소스 이름으로 교체합니다.

      view-custom-resource.yaml 파일 예

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-custom-resource
rules:
- apiGroups:
  - <cluster_extension_api_group>
  resources:
  - <cluster_extension_custom_resources>
  verbs:
  - get
  - list
  - watch
      Copy to Clipboard Toggle word wrap

      edit-custom-resource.yaml 파일 예

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: edit-custom-resource
rules:
- apiGroups:
  - <cluster_extension_api_group>
  resources:
  - <cluster_extension_custom_resources>
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
      Copy to Clipboard Toggle word wrap

      admin-custom-resource.yaml 파일의 예

      apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: admin-custom-resource
rules:
- apiGroups:
  - <cluster_extension_api_group>
  resources:
  - <cluster_extension_custom_resources>
  verbs:
  - '*'
      1
      Copy to Clipboard Toggle word wrap

      1
      동사 에서 와일드카드(*)를 설정하면 지정된 리소스에 대한 모든 작업을 수행할 수 있습니다.

    2. 생성한 YAML 파일에 대해 다음 명령을 실행하여 클러스터 역할을 생성합니다. 

      $ oc create -f <filename>.yaml
      Copy to Clipboard Toggle word wrap

  2. 클러스터 역할을 특정 사용자 또는 그룹에 연결하여 클러스터 역할을 개별 사용자 또는 그룹 이름에 바인딩하여 리소스에 필요한 권한을 부여합니다.

    1. 모든 네임스페이스 또는 특정 네임스페이스 내에서 액세스 권한을 부여할 역할 바인딩에 대한 액세스 권한을 부여하는 클러스터 역할 바인딩에 대한 오브젝트 정의를 생성합니다.

      • 다음 예제 클러스터 역할 바인딩은 모든 네임스페이스의 사용자 정의 리소스에 대한 읽기 전용 보기 액세스 권한을 부여합니다.

        사용자에 대한 ClusterRoleBinding 오브젝트의 예

        apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-custom-resource-binding
subjects:
- kind: User
  name: <user_name>
roleRef:
  kind: ClusterRole
  name: view-custom-resource
  apiGroup: rbac.authorization.k8s.io
        Copy to Clipboard Toggle word wrap

        사용자에 대한 ClusterRoleBinding 오브젝트의 예

        apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: view-custom-resource-binding
subjects:
- kind: Group
  name: <group_name>
roleRef:
  kind: ClusterRole
  name: view-custom-resource
  apiGroup: rbac.authorization.k8s.io
        Copy to Clipboard Toggle word wrap

      • 다음 역할 바인딩에서는 특정 네임스페이스에 대한 편집 권한을 제한합니다.

        사용자에 대한 RoleBinding 오브젝트의 예

        apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: edit-custom-resource-edit-binding
  namespace: <namespace>
subjects:
- kind: User
  name: <username>
roleRef:
  kind: Role
  name: custom-resource-edit
  apiGroup: rbac.authorization.k8s.io
        Copy to Clipboard Toggle word wrap

    2. 오브젝트 정의를 YAML 파일에 저장합니다.

    3. 다음 명령을 실행하여 오브젝트를 생성합니다. 

      $ oc create -f <filename>.yaml
      Copy to Clipboard Toggle word wrap

클러스터 관리자는 집계된 클러스터 역할을 사용하여 확장 리소스에 대한 사용자 액세스 권한을 부여하도록 역할 기반 액세스 제어(RBAC) 정책을 구성할 수 있습니다.

기존 기본 클러스터 역할을 자동으로 확장하려면 다음 레이블 중 하나 이상을 ClusterRole 개체에 추가하여 aggregation labels을 추가할 수 있습니다.

ClusterRole 오브젝트의 집계 라벨

# ..
metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
# ..
Copy to Clipboard Toggle word wrap

이를 통해 이미 보기,편집 또는 관리자 역할이 있는 사용자는 특정 사용자 또는 그룹에 대한 추가 역할 또는 클러스터 역할 바인딩 없이도 ClusterRole 오브젝트에서 지정한 사용자 정의 리소스와 상호 작용할 수 있습니다.

사전 요구 사항

  • 클러스터에 클러스터 확장이 설치되었습니다.
  • "클러스터 확장에서 노출된 API 그룹 및 리소스 찾기"에 설명된 대로 API 그룹 및 리소스 이름 목록이 있습니다.

프로세스

  1. 클러스터 확장에서 제공하는 API 그룹과 리소스를 지정하는 클러스터 역할에 대한 개체 정의를 만들고 하나 이상의 기존 기본 클러스터 역할을 확장하기 위한 집계 레이블을 추가합니다.

    집계 레이블이 있는 ClusterRole 개체의 예

    apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: view-custom-resource-aggregated
  labels:
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
  - apiGroups:
      - <cluster_extension_api_group>
    resources:
      - <cluster_extension_custom_resource>
    verbs:
      - get
      - list
      - watch
    Copy to Clipboard Toggle word wrap

    create , update , delete 와 같은 적절한 동사를 사용하여 edit 및 admin에 대한 유사한 ClusterRole 객체를 만들 수 있습니다. 집계 레이블을 사용하면 사용자 지정 리소스에 대한 권한이 기본 역할에 추가됩니다.

  2. 개체 정의를 YAML 파일에 저장합니다.

  3. 다음 명령을 실행하여 객체를 생성합니다. 

    $ oc create -f <filename>.yaml
    Copy to Clipboard Toggle word wrap

5.3. 경로 업데이트
링크 복사

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

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

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

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

    • OLM(클래식)에서는 채널 헤드에 가장 가까운 후속 채널이 선택됩니다.
    • OLM v1에서는 가장 높은 의미 버전(semver)을 가진 후속 버전이 선택됩니다.

  • 다음의 파일 기반 카탈로그(FBC) 채널 항목 세트를 고려하세요. 

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

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

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

5.3.1. 버전 범위 지원
링크 복사

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

해결된 버전 워크플로

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

5.3.2. 버전 비교 문자열
링크 복사

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

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

=

동일하다

!=

같지 않다

>

보다 크다

<

미만

>=

이상 또는 같음

<=

이하

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

예제 버전 범위 비교

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

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

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

1.11.x

>=1.11.0, <1.12.0

>=1.12.X

>=1.12.0

<=2.x

<3

*

>=0.0.0

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

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

~1.11.0

>=1.11.0, <1.12.0

~1

>=1, <2

~1.12

>=1.12, <1.13

~1.12.x

>=1.12.0, <1.13.0

~1.x

>=1, <2

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

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

^0

>=0.0.0, <1.0.0

^0.0

>=0.0.0, <0.1.0

^0.0.3

>=0.0.3, <0.0.4

^0.2

>=0.2.0, <0.3.0

^0.2.3

>=0.2.3, <0.3.0

^1.2.x

>= 1.2.0, < 2.0.0

^1.2.3

>= 1.2.3, < 2.0.0

^2.x

>= 2.0.0, < 3

^2.3

>= 2.3, < 3

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

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

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

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

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

지정된 채널이 있는 CR 예

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

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

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

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

대상 버전이 지정된 CR 예

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

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

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

버전 범위가 지정된 CR 예

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

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

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

명령 구문

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

5.3.4. 업데이트 또는 롤백 강제 실행
링크 복사

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

주의

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

사전 요구 사항

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

프로세스

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

    CR 예시

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

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

  2. 다음 명령을 실행하여 Operator 또는 확장 프로그램 CR에 변경 사항을 적용하세요. 

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

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

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

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

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

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

olm.maxOpenShiftVersion 주석이 있는 CSV의 예

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

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

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

참고

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

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

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

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

5.4. 사용자 정의 리소스 정의(CRD) 업그레이드 안전
링크 복사

클러스터 확장 프로그램에서 제공하는 사용자 지정 리소스 정의(CRD)를 업데이트하면 Operator Lifecycle Manager(OLM) v1이 CRD 업그레이드 안전 사전 검사를 실행하여 해당 CRD의 이전 버전과의 하위 호환성을 보장합니다. CRD 업데이트는 변경 사항이 클러스터에서 진행되기 전에 유효성 검사를 통과해야 합니다.

5.4.1. 금지된 CRD 업그레이드 변경
링크 복사

기존 사용자 정의 리소스 정의(CRD)에 대한 다음과 같은 변경 사항은 CRD 업그레이드 안전 사전 검사에서 발견되어 업그레이드가 방지됩니다.

  • 기존 CRD 버전에 새로운 필수 필드가 추가되었습니다.
  • 기존 버전의 CRD에서 기존 필드가 제거되었습니다.
  • 기존 버전의 CRD에서 기존 필드 유형이 변경되었습니다.
  • 이전에 기본값이 없었던 필드에 새로운 기본값이 추가되었습니다.
  • 필드의 기본값이 변경됩니다
  • 필드의 기존 기본값이 제거됩니다.
  • 이전에 열거형 제한이 없었던 기존 필드에 새로운 열거형 제한이 추가됩니다.
  • 기존 필드의 기존 enum 값이 제거됩니다.
  • 기존 필드의 최소값이 기존 버전에서 증가합니다.
  • 기존 버전에서는 기존 필드의 최대값이 감소합니다.
  • 최소 또는 최대 필드 제약 조건이 이전에 제약 조건이 없었던 필드에 추가되었습니다.
참고

최소값과 최대값 변경 규칙은 minimum , minLength , minProperties , minItems , maximum , maxLength , maxProperties 및 maxItems 제약 조건에 적용됩니다.

기존 CRD에 대한 다음과 같은 변경 사항은 CRD 업그레이드 안전 사전 검사에서 보고되며 업그레이드를 방지하지만 해당 작업은 기술적으로 Kubernetes API 서버에서 처리합니다.

  • 범위가 클러스터 에서 네임스페이스 로 또는 네임스페이스 에서 클러스터 로 변경됩니다.
  • 저장된 CRD의 기존 버전이 제거됩니다.

CRD 업그레이드 안전 사전 검사에서 금지된 업그레이드 변경 사항 중 하나를 발견하면 CRD 업그레이드에서 감지된 각 금지된 변경 사항에 대한 오류가 기록됩니다.

작은 정보

CRD 변경 사항이 금지된 변경 범주에 속하지 않지만 허용된 변경 사항으로 적절히 감지할 수 없는 경우, CRD 업그레이드 안전 사전 검사에서 업그레이드가 차단되고 "알 수 없는 변경 사항"에 대한 오류가 기록됩니다.

5.4.2. 허용된 CRD 업그레이드 변경 사항
링크 복사

기존 사용자 정의 리소스 정의(CRD)에 대한 다음 변경 사항은 이전 버전과의 호환성을 위해 안전하며 CRD 업그레이드 안전 사전 검사로 인해 업그레이드가 중단되지 않습니다.

  • 필드에서 허용되는 열거형 값 목록에 새 열거형 값 추가
  • 기존 필수 필드가 기존 버전에서 선택 사항으로 변경되었습니다.
  • 기존 버전에서 기존 필드의 최소값이 감소합니다.
  • 기존 버전에서 기존 필드의 최대값이 증가합니다.
  • 기존 버전을 수정하지 않고 새 버전의 CRD가 추가되었습니다.

5.4.3. CRD 업그레이드 안전 사전 비행 확인 비활성화
링크 복사

사용자 정의 리소스 정의(CRD) 업그레이드 안전 사전 검사를 비활성화할 수 있습니다. CRD를 제공하는 ClusterExtension 개체에서 install.preflight.crdUpgradeSafety.enforcement 필드를 None 값으로 설정합니다.

주의

CRD 업그레이드 안전 사전 검사를 비활성화하면 저장된 CRD 버전과의 하위 호환성이 끊어질 수 있으며 클러스터에서 다른 의도치 않은 결과가 발생할 수 있습니다.

개별 필드 검증기를 비활성화할 수 없습니다. CRD 업그레이드 안전 사전 검사를 비활성화하면 모든 필드 검증기가 비활성화됩니다.

참고

Operator Lifecycle Manager(OLM) v1에서 CRD 업그레이드 안전 사전 검사를 비활성화해도 Kubernetes API 서버는 여전히 다음 작업을 차단합니다.

  • 클러스터 에서 네임스페이스 로 또는 네임스페이스 에서 클러스터 로 범위 변경
  • CRD의 기존 저장된 버전 제거

사전 요구 사항

  • 클러스터 확장이 설치되어 있습니다.

프로세스

  1. CRD의 ClusterExtension 객체를 편집합니다. 

    $ oc edit clusterextension <clusterextension_name>
    Copy to Clipboard Toggle word wrap

  2. install.preflight.crdUpgradeSafety.enforcement 필드를 없음 으로 설정합니다.

    ClusterExtension 오브젝트의 예

    apiVersion: olm.operatorframework.io/v1
kind: ClusterExtension
metadata:
  name: clusterextension-sample
spec:
  namespace: default
  serviceAccount:
    name: sa-example
  source:
    sourceType: "Catalog"
    catalog:
      packageName: argocd-operator
      version: 0.6.0
  install:
    preflight:
      crdUpgradeSafety:
        enforcement: None
    Copy to Clipboard Toggle word wrap

5.4.4. 안전하지 않은 CRD 변경의 예
링크 복사

다음 예제에서는 CRD 업그레이드 안전 사전 검사에서 발견될 수 있는 사용자 정의 리소스 정의(CRD) 섹션의 특정 변경 사항을 보여줍니다.

다음 예제에서는 다음 시작 상태의 CRD 객체를 고려합니다.

예 5.19. CRD 객체 예

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.13.0
  name: example.test.example.com
spec:
  group: test.example.com
  names:
    kind: Sample
    listKind: SampleList
    plural: samples
    singular: sample
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        properties:
          apiVersion:
            type: string
          kind:
            type: string
          metadata:
            type: object
          spec:
            type: object
          status:
            type: object
          pollInterval:
            type: string
        type: object
    served: true
    storage: true
    subresources:
      status: {}
Copy to Clipboard Toggle word wrap
5.4.4.1. 범위 변경
링크 복사

다음 사용자 정의 리소스 정의(CRD) 예에서 범위 필드는 네임스페이스 에서 클러스터 로 변경되었습니다.

예 5.20. CRD의 범위 변경 예

    spec:
      group: test.example.com
      names:
        kind: Sample
        listKind: SampleList
        plural: samples
        singular: sample
      scope: Cluster
      versions:
      - name: v1alpha1
Copy to Clipboard Toggle word wrap

예 5.21. 오류 출력 예

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoScopeChange" validation failed: scope changed from "Namespaced" to "Cluster"
Copy to Clipboard Toggle word wrap
5.4.4.2. 저장된 버전 제거
링크 복사

다음 사용자 정의 리소스 정의(CRD) 예에서는 기존에 저장된 버전인 v1alpha1 이 제거됩니다.

예 5.22. CRD에 저장된 버전 제거 예

      versions:
      - name: v1alpha2
        schema:
          openAPIV3Schema:
            properties:
              apiVersion:
                type: string
              kind:
                type: string
              metadata:
                type: object
              spec:
                type: object
              status:
                type: object
              pollInterval:
                type: string
            type: object
Copy to Clipboard Toggle word wrap

예 5.23. 오류 출력 예

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoStoredVersionRemoved" validation failed: stored version "v1alpha1" removed
Copy to Clipboard Toggle word wrap
5.4.4.3. 기존 필드 제거
링크 복사

다음 사용자 정의 리소스 정의(CRD) 예에서 pollInterval 속성 필드는 v1alpha1 스키마에서 제거되었습니다.

예 5.24. CRD에서 기존 필드 제거 예

      versions:
      - name: v1alpha1
        schema:
          openAPIV3Schema:
            properties:
              apiVersion:
                type: string
              kind:
                type: string
              metadata:
                type: object
              spec:
                type: object
              status:
                type: object
            type: object
Copy to Clipboard Toggle word wrap

예 5.25. 오류 출력 예

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "NoExistingFieldRemoved" validation failed: crd/test.example.com version/v1alpha1 field/^.spec.pollInterval may not be removed
Copy to Clipboard Toggle word wrap
5.4.4.4. 필수 필드 추가
링크 복사

다음 사용자 정의 리소스 정의(CRD) 예에서 pollInterval 속성은 필수 필드로 변경되었습니다.

예 5.26. CRD에 필수 필드 추가 예시

      versions:
      - name: v1alpha2
        schema:
          openAPIV3Schema:
            properties:
              apiVersion:
                type: string
              kind:
                type: string
              metadata:
                type: object
              spec:
                type: object
              status:
                type: object
              pollInterval:
                type: string
            type: object
            required:
            - pollInterval
Copy to Clipboard Toggle word wrap

예 5.27. 오류 출력 예

validating upgrade for CRD "test.example.com" failed: CustomResourceDefinition test.example.com failed upgrade safety validation. "ChangeValidator" validation failed: version "v1alpha1", field "^": new required fields added: [pollInterval]
Copy to Clipboard Toggle word wrap

Legal Notice
링크 복사

Copyright © 2025 Red Hat

OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).

Modified versions must remove all Red Hat trademarks.

Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.

Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.

Linux® is the registered trademark of Linus Torvalds in the United States and other countries.

Java® is a registered trademark of Oracle and/or its affiliates.

XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.

MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.

Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.

The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.

All other trademarks are the property of their respective owners.

맨 위로 이동
Red Hat logoGithubredditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

Theme

© 2025 Red Hat