검색

Operator

download PDF
OpenShift Container Platform 4.15

OpenShift Container Platform의 Operator 작업

Red Hat OpenShift Documentation Team

초록

이 문서에서는 OpenShift Container Platform에서 Operator를 사용하는 방법에 대해 설명합니다. 여기에는 클러스터 관리자를 위한 Operator 설치 및 관리 방법과 설치된 Operator에서 애플리케이션을 생성하는 방법에 대한 지침이 포함됩니다. 또한 Operator SDK를 사용하여 자체 Operator를 빌드하는 방법에 대한 지침이 포함되어 있습니다.

1장. Operator 개요

Operator는 OpenShift Container Platform의 가장 중요한 구성 요소 중 하나입니다. Operator는 컨트롤 플레인에서 서비스를 패키징, 배포 및 관리하는 기본 방법입니다. 또한 사용자가 실행하는 애플리케이션에 이점을 제공할 수 있습니다.

Operator는 kubectl 및 oc 명령과 같은 CLI 툴 및 Kubernetes API와 통합됩니다. 애플리케이션을 모니터링하고, 상태 점검 수행, OTA(Over-the-Air) 업데이트를 관리하며 애플리케이션이 지정된 상태로 유지되도록 합니다.

두 가지 모두 유사한 Operator 개념과 목표를 따르지만 OpenShift Container Platform의 Operator는 목적에 따라 두 가지 다른 시스템에서 관리합니다.

  • CVO(Cluster Version Operator)에서 관리하는 클러스터 Operator는 기본적으로 클러스터 기능을 수행하기 위해 설치됩니다.
  • 사용자가 애플리케이션에서 실행할 수 있도록 OLM(Operator Lifecycle Manager)에서 관리하는 선택적 애드온 Operator를 사용할 수 있습니다.

Operator를 사용하면 애플리케이션을 생성하여 클러스터에서 실행 중인 서비스를 모니터링할 수 있습니다. Operator는 애플리케이션을 위해 특별히 설계되었습니다. Operator는 설치 및 구성과 같은 일반적인 Day 1 작업과 자동 스케일링 및 백업 생성과 같은 2일차 작업을 구현하고 자동화합니다. 이러한 모든 작업은 클러스터 내에서 실행되는 소프트웨어입니다.

1.1. 개발자의 경우

개발자는 다음 Operator 작업을 수행할 수 있습니다.

1.2. 관리자의 경우

클러스터 관리자는 다음 Operator 작업을 수행할 수 있습니다.

Red Hat에서 제공하는 클러스터 Operator에 대한 모든 정보를 보려면 Cluster Operators 참조를 참조하십시오.

1.3. 다음 단계

Operator에 대한 자세한 내용은 Operator의 내용을 참조하십시오. ???

2장. Operator 이해

2.1. Operator란 무엇인가?

개념적으로 Operator는 사람의 운영 지식을 소비자와 더 쉽게 공유할 수 있는 소프트웨어로 인코딩합니다.

Operator는 다른 소프트웨어를 실행하는 데 따르는 운영의 복잡성을 완화해주는 소프트웨어입니다. 이는 소프트웨어 벤더의 엔지니어링 팀의 확장 기능으로, Kubernetes 환경(예: OpenShift Container Platform)을 모니터링하고 현재 상태를 사용하여 실시간으로 의사 결정을 내립니다. 고급 Operator는 업그레이드를 원활하게 처리하고 오류에 자동으로 대응하며 시간을 절약하기 위해 소프트웨어 백업 프로세스를 생략하는 등의 바로 가기를 실행하지 않습니다.

Operator는 Kubernetes 애플리케이션을 패키징, 배포, 관리하는 메서드입니다.

Kubernetes 애플리케이션은 Kubernetes API 및 kubectl 또는 oc 툴링을 사용하여 Kubernetes API에 배포하고 관리하는 앱입니다. Kubernetes를 최대한 활용하기 위해서는 Kubernetes에서 실행되는 앱을 제공하고 관리하기 위해 확장할 응집력 있는 일련의 API가 필요합니다. Operator는 Kubernetes에서 이러한 유형의 앱을 관리하는 런타임으로 생각할 수 있습니다.

2.1.1. Operator를 사용하는 이유는 무엇입니까?

Operator는 다음과 같은 기능을 제공합니다.

  • 반복된 설치 및 업그레이드.
  • 모든 시스템 구성 요소에 대한 지속적인 상태 점검.
  • OpenShift 구성 요소 및 ISV 콘텐츠에 대한 OTA(Over-The-Air) 업데이트
  • 필드 엔지니어의 지식을 캡슐화하여 한두 명이 아닌 모든 사용자에게 전파.
Kubernetes에 배포하는 이유는 무엇입니까?
Kubernetes(및 확장에 따라 OpenShift Container Platform)에는 시크릿 처리, 로드 밸런싱, 서비스 검색, 자동 스케일링 - 온프레미스 및 클라우드 공급자 전반에서 작동하는 복잡한 분산 시스템을 빌드하는 데 필요한 모든 기본 기능이 포함되어 있습니다.
Kubernetes API 및 kubectl 툴링으로 앱을 관리하는 이유는 무엇입니까?
이러한 API는 기능이 다양하고 모든 플랫폼에 대한 클라이언트가 있으며 클러스터의 액세스 제어/감사에 연결됩니다. Operator는 Kubernetes 확장 메커니즘인 CRD(사용자 정의 리소스 정의)를 사용하므로 사용자 정의 오브젝트(예: MongoDB)가 기본 제공되는 네이티브 Kubernetes 오브젝트처럼 보이고 작동합니다.
Operator는 서비스 브로커와 어떻게 다릅니까?
서비스 브로커는 앱의 프로그래밍 방식 검색 및 배포를 위한 단계입니다. 그러나 오래 실행되는 프로세스가 아니므로 업그레이드, 장애 조치 또는 스케일링과 같은 2일 차 작업을 실행할 수 없습니다. 튜닝할 수 있는 항목에 대한 사용자 정의 및 매개변수화는 설치 시 제공되지만 Operator는 클러스터의 현재 상태를 지속적으로 관찰합니다. 클러스터 외부 서비스는 서비스 브로커에 적합하지만 해당 서비스를 위한 Operator도 있습니다.

2.1.2. Operator 프레임워크

Operator 프레임워크는 위에서 설명한 고객 경험을 제공하는 툴 및 기능 제품군입니다. 코드를 작성하는 데 그치지 않고 Operator를 테스트, 제공, 업데이트하는 것이 중요합니다. Operator 프레임워크 구성 요소는 이러한 문제를 해결하는 오픈 소스 툴로 구성됩니다.

Operator SDK
Operator SDK는 Operator 작성자가 Kubernetes API 복잡성에 대한 지식이 없어도 전문 지식을 기반으로 자체 Operator를 부트스트랩, 빌드, 테스트, 패키지할 수 있도록 지원합니다.
Operator Lifecycle Manager
OLM(Operator Lifecycle Manager)은 클러스터에서 Operator의 설치, 업그레이드, RBAC(역할 기반 액세스 제어)를 제어합니다. OpenShift Container Platform 4.15에 기본적으로 배포됩니다.
Operator 레지스트리
Operator 레지스트리는 CSV(클러스터 서비스 버전) 및 CRD(사용자 정의 리소스 정의)를 클러스터에 생성하기 위해 저장하고 패키지 및 채널에 대한 Operator 메타데이터를 저장합니다. 이 Operator 카탈로그 데이터를 OLM에 제공하기 위해 Kubernetes 또는 OpenShift 클러스터에서 실행됩니다.
OperatorHub
OperatorHub는 클러스터 관리자가 클러스터에 설치할 Operator를 검색하고 선택할 수 있는 웹 콘솔입니다. OpenShift Container Platform에 기본적으로 배포됩니다.

이러한 툴은 구성 가능하도록 설계되어 있어 유용한 툴을 모두 사용할 수 있습니다.

2.1.3. Operator 완성 모델

Operator 내에 캡슐화된 관리 논리의 세분화 수준은 다를 수 있습니다. 이 논리는 일반적으로 Operator에서 표시하는 서비스 유형에 따라 크게 달라집니다.

그러나 대부분의 Operator에 포함될 수 있는 특정 기능 세트의 경우 캡슐화된 Operator 작업의 완성 정도를 일반화할 수 있습니다. 이를 위해 다음 Operator 완성 모델에서는 Operator의 일반적인 2일 차 작업에 대해 5단계의 완성도를 정의합니다.

그림 2.1. Operator 완성 모델

Operator 완성 모델

또한 위 모델은 Operator SDK의 Helm, Go, Ansible 기능을 통해 이러한 기능을 가장 잘 개발할 수 있는 방법을 보여줍니다.

2.2. Operator 프레임워크 패키지 형식

이 가이드에서는 OpenShift Container Platform의 OLM(Operator Lifecycle Manager)에서 지원하는 Operator의 패키지 형식에 대해 간단히 설명합니다.

2.2.1. 번들 형식

Operator의 번들 형식은 Operator 프레임워크에서 도입한 패키지 형식입니다. 번들 형식 사양에서는 확장성을 개선하고 자체 카탈로그를 호스팅하는 업스트림 사용자를 더 효과적으로 지원하기 위해 Operator 메타데이터의 배포를 단순화합니다.

Operator 번들은 단일 버전의 Operator를 나타냅니다. 디스크상의 번들 매니페스트는 컨테이너화되어 번들 이미지(Kubernetes 매니페스트와 Operator 메타데이터를 저장하는 실행 불가능한 컨테이너 이미지)로 제공됩니다. 그런 다음 podmandocker와 같은 기존 컨테이너 툴과 Quay와 같은 컨테이너 레지스트리를 사용하여 번들 이미지의 저장 및 배포를 관리합니다.

Operator 메타데이터에는 다음이 포함될 수 있습니다.

  • Operator 확인 정보(예: 이름 및 버전)
  • UI를 구동하는 추가 정보(예: 아이콘 및 일부 예제 CR(사용자 정의 리소스))
  • 필요한 API 및 제공된 API.
  • 관련 이미지.

Operator 레지스트리 데이터베이스에 매니페스트를 로드할 때 다음 요구 사항이 검증됩니다.

  • 번들의 주석에 하나 이상의 채널이 정의되어 있어야 합니다.
  • 모든 번들에 정확히 하나의 CSV(클러스터 서비스 버전)가 있습니다.
  • CSV에 CRD(사용자 정의 리소스 정의)가 포함된 경우 해당 CRD가 번들에 있어야 합니다.

2.2.1.1. 매니페스트

번들 매니페스트는 Operator의 배포 및 RBAC 모델을 정의하는 Kubernetes 매니페스트 세트를 나타냅니다.

번들에는 디렉터리당 하나의 CSV와 일반적으로 /manifests 디렉터리에서 CSV의 고유 API를 정의하는 CRD가 포함됩니다.

Bundle 형식 레이아웃의 예

etcd
├── manifests
│   ├── etcdcluster.crd.yaml
│   └── etcdoperator.clusterserviceversion.yaml
│   └── secret.yaml
│   └── configmap.yaml
└── metadata
    └── annotations.yaml
    └── dependencies.yaml

추가 지원 오브젝트

다음과 같은 오브젝트 유형도 번들의 /manifests 디렉터리에 선택적으로 포함될 수 있습니다.

지원되는 선택적 오브젝트 유형

  • ClusterRole
  • ClusterRoleBinding
  • ConfigMap
  • ConsoleCLIDownload
  • ConsoleLink
  • ConsoleQuickStart
  • ConsoleYamlSample
  • PodDisruptionBudget
  • PriorityClass
  • PrometheusRule
  • Role
  • RoleBinding
  • Secret
  • Service
  • ServiceAccount
  • ServiceMonitor
  • VerticalPodAutoscaler

이러한 선택적 오브젝트가 번들에 포함된 경우 OLM(Operator Lifecycle Manager)은 번들에서 해당 오브젝트를 생성하고 CSV와 함께 해당 라이프사이클을 관리할 수 있습니다.

선택적 오브젝트의 라이프사이클

  • CSV가 삭제되면 OLM은 선택적 오브젝트를 삭제합니다.
  • CSV가 업그레이드되면 다음을 수행합니다.

    • 선택적 오브젝트의 이름이 동일하면 OLM에서 해당 오브젝트를 대신 업데이트합니다.
    • 버전 간 선택적 오브젝트의 이름이 변경된 경우 OLM은 해당 오브젝트를 삭제하고 다시 생성합니다.

2.2.1.2. 주석

번들의 /metadata 디렉터리에는 annotations.yaml 파일도 포함되어 있습니다. 이 파일에서는 번들을 번들 인덱스에 추가하는 방법에 대한 형식 및 패키지 정보를 설명하는 데 도움이 되는 고급 집계 데이터를 정의합니다.

예제 annotations.yaml

annotations:
  operators.operatorframework.io.bundle.mediatype.v1: "registry+v1" 1
  operators.operatorframework.io.bundle.manifests.v1: "manifests/" 2
  operators.operatorframework.io.bundle.metadata.v1: "metadata/" 3
  operators.operatorframework.io.bundle.package.v1: "test-operator" 4
  operators.operatorframework.io.bundle.channels.v1: "beta,stable" 5
  operators.operatorframework.io.bundle.channel.default.v1: "stable" 6

1
Operator 번들의 미디어 유형 또는 형식입니다. registry+v1 형식은 CSV 및 관련 Kubernetes 오브젝트가 포함됨을 나타냅니다.
2
Operator 매니페스트가 포함된 디렉터리의 이미지 경로입니다. 이 라벨은 나중에 사용할 수 있도록 예약되어 있으며 현재 기본값은 manifests/입니다. 값 manifests.v1은 번들에 Operator 매니페스트가 포함되어 있음을 나타냅니다.
3
번들에 대한 메타데이터 파일이 포함된 디렉터리의 이미지의 경로입니다. 이 라벨은 나중에 사용할 수 있도록 예약되어 있으며 현재 기본값은 metadata/입니다. 값 metadata.v1은 이 번들에 Operator 메타데이터가 있음을 나타냅니다.
4
번들의 패키지 이름입니다.
5
Operator 레지스트리에 추가될 때 번들이 서브스크립션되는 채널 목록입니다.
6
레지스트리에서 설치할 때 Operator를 서브스크립션해야 하는 기본 채널입니다.
참고

불일치하는 경우 이러한 주석을 사용하는 클러스터상의 Operator 레지스트리만 이 파일에 액세스할 수 있기 때문에 annotations.yaml 파일을 신뢰할 수 있습니다.

2.2.1.3. 종속 항목

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

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

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

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

dependencies.yaml 파일의 예

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

2.2.1.4. opm CLI 정보

opm CLI 툴은 Operator 번들 형식과 함께 사용할 수 있도록 Operator 프레임워크에서 제공합니다. 이 툴을 사용하면 소프트웨어 리포지토리와 유사한 Operator 번들 목록에서 Operator 카탈로그를 생성하고 유지 관리할 수 있습니다. 결과적으로 컨테이너 레지스트리에 저장한 다음 클러스터에 설치할 수 있는 컨테이너 이미지가 생성됩니다.

카탈로그에는 컨테이너 이미지가 실행될 때 제공되는 포함된 API를 통해 쿼리할 수 있는 Operator 매니페스트 콘텐츠에 대한 포인터 데이터베이스가 포함되어 있습니다. OpenShift Container Platform에서 OLM(Operator Lifecycle Manager)은 CatalogSource 오브젝트에서 정의한 카탈로그 소스의 이미지를 참조할 수 있으며 주기적으로 이미지를 폴링하여 클러스터에 설치된 Operator를 자주 업데이트할 수 있습니다.

2.2.2. 파일 기반 카탈로그

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

편집

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

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

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

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

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

참고

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

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

확장성

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

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

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

중요

OpenShift Container Platform 4.11부터 파일 기반 카탈로그 형식으로 기본 Red Hat 제공 Operator 카탈로그 릴리스입니다. 더 이상 사용되지 않는 SQLite 데이터베이스 형식으로 릴리스된 OpenShift Container Platform 4.6에 대한 기본 Red Hat 제공 Operator 카탈로그입니다.

SQLite 데이터베이스 형식과 관련된 opm 하위 명령, 플래그 및 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이 기능은 계속 지원되며 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 사용하는 카탈로그에 사용해야 합니다.

opm index prune 와 같은 SQLite 데이터베이스 형식을 사용하기 위한 opm 하위 명령 및 플래그는 파일 기반 카탈로그 형식에서는 작동하지 않습니다. 파일 기반 카탈로그 작업에 대한 자세한 내용은 oc-mirror 플러그인을 사용하여 사용자 정의 카탈로그 관리 및 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.

2.2.2.1. 디렉토리 구조

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

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

.indexignore 파일의 예

# Ignore everything except non-object .json and .yaml files
**/*
!*.json
!*.yaml
**/objects/*.json
**/objects/*.yaml

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

기본 권장 구조

catalog
├── packageA
│   └── index.yaml
├── packageB
│   ├── .indexignore
│   ├── index.yaml
│   └── objects
│       └── packageB.v0.1.0.clusterserviceversion.yaml
└── packageC
    └── index.json
    └── deprecations.yaml

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

2.2.2.2. 스키마

파일 기반 카탈로그는 임의의 스키마로 확장할 수 있는 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
}

참고

이 사양에 나열된 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 정의 스키마용으로 예약됩니다. 사용자 지정 스키마는 소유한 도메인과 같이 고유한 접두사를 사용해야 합니다.

2.2.2.2.1. olm.package 스키마

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

예 2.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
  }
}
2.2.2.2.2. olm.channel 스키마

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

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

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

예 2.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 & !=""
}
주의

skipRange 필드를 사용하는 경우 건너뛰는 Operator 버전이 업데이트 그래프에서 정리되며 Subscription 오브젝트의 spec.startingCSV 속성이 있는 사용자가 더 오래 설치할 수 있습니다.

skipRangereplaces 필드를 모두 사용하여 향후 설치를 위해 사용자가 이전에 설치한 버전을 사용할 수 있는 동안 Operator를 점진적으로 업데이트할 수 있습니다. replaces 필드가 해당 Operator 버전의 즉시 이전 버전을 가리키는지 확인합니다.

2.2.2.2.3. olm.bundle 스키마

예 2.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 & !=""
}
2.2.2.2.4. olm.deprecations 스키마

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

olm.deprecations 스키마 항목에는 사용 중단 범위를 나타내는 다음 참조 유형 중 하나 이상이 포함되어 있습니다. Operator가 설치되면 지정된 메시지를 관련 Subscription 오브젝트에서 상태 조건으로 볼 수 있습니다.

표 2.1. 사용 중단 참조 유형
유형범위상태 조건

olm.package

전체 패키지를 나타냅니다.

PackageDeprecated

olm.channel

하나의 채널을 나타냅니다.

ChannelDeprecated

olm.bundle

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

BundleDeprecated

참조 유형에는 다음 예에 설명된 대로 자체 요구 사항이 있습니다.

예 2.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.
1
각 사용 중단 스키마에는 패키지 값이 있어야 하며 해당 패키지 참조는 카탈로그 전체에서 고유해야 합니다. 연결된 이름 필드가 없어야 합니다.
2
olm.package 스키마는 스키마의 앞부분에서 정의한 package 필드에 의해 결정되므로 name 필드를 포함하지 않아야 합니다.
3
모든 참조 유형에 대한 모든 메시지 필드는 0이 아닌 길이이고 불투명 텍스트 Blob으로 표현되어야 합니다.
4
olm.channel 스키마의 name 필드가 필요합니다.
5
olm.bundle 스키마의 name 필드가 필요합니다.
참고

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

Operator 작성자는 olm.deprecations 스키마 항목을 패키지의 index.yaml 파일과 동일한 디렉터리에 deprecations.yaml 파일로 저장할 수 있습니다.

사용 중단이 있는 카탈로그의 디렉터리 구조 예

my-catalog
└── my-operator
    ├── index.yaml
    └── deprecations.yaml

2.2.2.3. 속성

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

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

2.2.2.3.1. olm.package 속성

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

예 2.5. olm.package 속성

#PropertyPackage: {
  type: "olm.package"
  value: {
    packageName: string & !=""
    version: string & !=""
  }
}
2.2.2.3.2. olm.gvk 속성

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

예 2.6. olm.gvk 속성

#PropertyGVK: {
  type: "olm.gvk"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}
2.2.2.3.3. olm.package.required

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

예 2.7. olm.package.required 속성

#PropertyPackageRequired: {
  type: "olm.package.required"
  value: {
    packageName: string & !=""
    versionRange: string & !=""
  }
}
2.2.2.3.4. olm.gvk.required

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

예 2.8. olm.gvk.required 속성

#PropertyGVKRequired: {
  type: "olm.gvk.required"
  value: {
    group: string & !=""
    version: string & !=""
    kind: string & !=""
  }
}

2.2.2.4. 카탈로그의 예

파일 기반 카탈로그를 사용하면 카탈로그 유지 관리자가 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

  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"

2.2.2.5. 지침

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

2.2.2.5.1. 변경할 수 없는 번들

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

손상된 번들이 카탈로그로 푸시된 경우 사용자 중 한 명이 해당 번들로 업그레이드되었다고 가정해야 합니다. 이러한 가정에 따라 손상된 번들이 설치된 사용자에게 업그레이드를 수신하려면 손상된 번들에서 업그레이드 엣지를 사용하여 다른 번들을 릴리스해야 합니다. 해당 번들의 콘텐츠가 카탈로그에서 업데이트되는 경우 OLM은 설치된 번들을 다시 설치하지 않습니다.

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

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

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

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

2.2.2.6. CLI 사용

opm CLI를 사용하여 파일 기반 카탈로그를 생성하는 방법에 대한 자세한 내용은 사용자 정의 카탈로그 관리를 참조하십시오.

파일 기반 카탈로그 관리와 관련된 opm CLI 명령에 대한 참조 문서는 CLI 툴 을 참조하십시오.

2.2.2.7. 자동화

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

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

2.2.3. RukPak (기술 프리뷰)

중요

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

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

OpenShift Container Platform 4.12에는 플랫폼 Operator 유형이 기술 프리뷰 기능으로 도입되었습니다. 플랫폼 Operator 메커니즘은 OpenShift Container Platform 4.12에도 도입된 RukPak 구성 요소와 해당 리소스를 사용하여 콘텐츠를 관리합니다.

OpenShift Container Platform 4.14에서는 OLM(Operator Lifecycle Manager) 1.0을 기술 프리뷰 기능으로 도입하여 RukPak 구성 요소도 사용합니다.

RukPak은 클라우드 네이티브 콘텐츠를 패키징하고 배포하기 위한 플러그형 솔루션입니다. 설치, 업데이트 및 정책을 위한 고급 전략을 지원합니다.

RukPak은 Kubernetes 클러스터에 다양한 아티팩트를 설치하기 위한 콘텐츠 에코시스템을 제공합니다. 아티팩트 예제에는 Git 리포지토리, Helm 차트 및 OLM 번들이 포함됩니다. RukPak은 강력한 클러스터 확장을 가능하게 하는 안전한 방법으로 이러한 아티팩트를 관리, 확장 및 업그레이드할 수 있습니다.

RukPak은 핵심에서 작은 API 및 컨트롤러 세트입니다. API는 클러스터에 설치할 콘텐츠를 나타내는 CRD(사용자 정의 리소스 정의)와 실행 중인 콘텐츠 배포를 생성하는 방법을 나타내는 CRD(사용자 정의 리소스 정의)로 패키징됩니다. 컨트롤러는 API를 감시합니다.

일반적인 용어

번들
클러스터에 배포할 콘텐츠를 정의하는 Kubernetes 매니페스트 컬렉션입니다.
번들 이미지
파일 시스템 내에 번들을 포함하는 컨테이너 이미지
번들 Git 리포지토리
디렉터리 내에 번들을 포함하는 Git 리포지토리
프로비저너
Kubernetes 클러스터에서 콘텐츠를 설치하고 관리하는 컨트롤러
번들 배포
번들의 배포된 인스턴스 생성

2.2.3.1. 번들

RukPak Bundle 오브젝트는 클러스터의 다른 사용자가 사용할 수 있도록 콘텐츠를 나타냅니다. 포드를 사용하려면 컨테이너 이미지의 콘텐츠를 가져와서 압축 해제해야 하는 것과 마찬가지로 Bundle 오브젝트는 가져와서 압축 해제해야 하는 콘텐츠를 참조하는 데 사용됩니다. 이러한 점에서 번들은 이미지 개념을 일반화하고 모든 유형의 콘텐츠를 나타내는 데 사용할 수 있습니다.

번들은 자체적으로 아무것도 수행할 수 없습니다. 프로비저닝 프로그램이 클러스터에서 콘텐츠를 사용할 수 있도록 압축을 풀고 사용할 수 있도록 해야 합니다. 프로비저너 Pod에 마운트된 디렉터리의 tar.gz 파일과 같은 임의의 스토리지 미디어에 압축을 해제할 수 있습니다. 각 Bundle 오브젝트에는 특정 번들 유형을 감시하고 압축 해제하는 Provisioner 오브젝트를 나타내는 관련 spec.provisionerClassName 필드가 있습니다.

일반 프로비저너에서 작동하도록 구성된 Bundle 오브젝트의 예

apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: my-bundle
spec:
  source:
    type: image
    image:
      ref: my-bundle@sha256:xyz123
  provisionerClassName: core-rukpak-io-plain

참고

번들은 생성 후 변경 불가능한 것으로 간주됩니다.

2.2.3.1.1. 번들 불변성

Bundle 오브젝트가 API 서버에서 승인되면 번들은 RukPak 시스템의 나머지 부분에 의해 변경 불가능한 아티팩트로 간주됩니다. 이 동작은 번들이 클러스터로 소스를 위해 몇 가지 고유한 정적 콘텐츠를 나타내는 개념을 적용합니다. 사용자는 특정 번들이 특정 매니페스트 세트를 가리키며 새 번들을 생성하지 않고 업데이트할 수 없음을 확신할 수 있습니다. 이 속성은 포함된 BundleTemplate 오브젝트에서 생성한 독립 실행형 번들과 동적 번들 모두에 적용됩니다.

번들 불변성은 코어 RukPak 웹 후크에 의해 적용됩니다. 이 Webhook는 Bundle 오브젝트 이벤트를 감시하고 번들에 대한 업데이트를 위해 기존 번들의 spec 필드가 제안된 업데이트된 번들의 사양 필드와 동일한지 확인합니다. 동일하지 않으면 Webhook에서 업데이트가 거부됩니다. 메타데이터 또는 상태와 같은 기타 번들 오브젝트 필드는 번들의 라이프사이클 중에 업데이트됩니다. 이는 변경할 수 없는 것으로 간주되는 spec 필드입니다.

Bundle 오브젝트를 적용한 다음 사양을 업데이트하려고 하면 실패합니다. 예를 들어 다음 예제에서는 번들을 생성합니다.

$ oc apply -f -<<EOF
apiVersion: core.rukpak.io/v1alpha1
kind: Bundle
metadata:
  name: combo-tag-ref
spec:
  source:
    type: git
    git:
      ref:
        tag: v0.0.2
      repository: https://github.com/operator-framework/combo
  provisionerClassName: core-rukpak-io-plain
EOF

출력 예

bundle.core.rukpak.io/combo-tag-ref created

그런 다음 최신 태그를 가리키도록 번들 패치를 패치하면 오류가 반환됩니다.

$ oc patch bundle combo-tag-ref --type='merge' -p '{"spec":{"source":{"git":{"ref":{"tag":"v0.0.3"}}}}}'

출력 예

Error from server (bundle.spec is immutable): admission webhook "vbundles.core.rukpak.io" denied the request: bundle.spec is immutable

번들 사양을 변경할 수 없기 때문에 코어 RukPak 승인 Webhook가 패치를 거부했습니다. 번들의 콘텐츠를 변경하는 데 권장되는 방법은 인플레이스에서 업데이트하는 대신 새 Bundle 오브젝트를 생성하는 것입니다.

추가 불변성 고려 사항

Bundle 오브젝트의 spec 필드는 변경할 수 없지만 BundleDeployment 오브젝트에서 기본 spec 필드를 변경하지 않고 최신 버전의 번들 콘텐츠로 피벗할 수 있습니다. 이러한 의도하지 않은 피벗은 다음 시나리오에서 발생할 수 있습니다.

  1. 사용자가 Bundle 오브젝트의 spec.source 필드에 이미지 태그, Git 분기 또는 Git 태그를 설정합니다.
  2. 이미지 태그는 새 다이제스트로 이동하거나, 사용자가 변경 사항을 Git 분기로 내보내거나, 사용자가 삭제한 후 다른 커밋에서 Git 태그를 다시 가져옵니다.
  3. 사용자가 압축 풀기 Pod를 삭제하는 등 번들 압축 해제 Pod를 다시 생성하도록 하는 작업을 수행합니다.

이 시나리오가 발생하면 3단계의 새 콘텐츠의 압축을 풉니다. 번들 배포에서는 변경 사항을 감지하고 최신 버전의 콘텐츠로 피벗합니다.

이는 Pod의 컨테이너 이미지 중 하나가 태그를 사용하고 태그를 다른 다이제스트로 이동한 다음 나중에 기존 Pod가 다른 노드에 다시 예약되는 Pod 동작과 유사합니다. 이 시점에서 노드는 새 다이제스트에서 새 이미지를 가져와서 사용자가 명시적으로 요청하지 않고 다른 이미지를 실행합니다.

번들 사양 콘텐츠가 변경되지 않도록 하려면 번들을 생성할 때 다이제스트 기반 이미지 또는 Git 커밋 참조를 사용합니다.

2.2.3.1.2. 일반 번들 사양

RukPak의 일반 번들은 지정된 디렉터리에 있는 정적, 임의의 Kubernetes YAML 매니페스트 컬렉션입니다.

현재 구현된 일반 번들 형식은 plain+v0 형식입니다. 번들 형식인 plain +v0은 번들 유형(일반 )과 현재 스키마 버전(v0)을 결합합니다.

참고

plain+v0 번들 형식은 스키마 버전 v0 입니다. 즉, 변경될 수 있는 실험 형식입니다.

예를 들어 다음은 일반+v0 번들의 파일 트리를 보여줍니다. 애플리케이션을 배포하는 데 필요한 Kubernetes 리소스가 포함된 manifests/ 디렉터리가 있어야 합니다.

일반+v0 번들 파일 트리의 예

$ tree manifests

manifests
├── namespace.yaml
├── service_account.yaml
├── cluster_role.yaml
├── cluster_role_binding.yaml
└── deployment.yaml

정적 매니페스트는 번들에서 프로비저너의 압축을 풀 수 있는 유효한 plain+v0 번들로 하나 이상의 리소스가 있는 manifests/ 디렉터리에 있어야 합니다. manifests/ 디렉터리도 플랫이어야 합니다. 모든 매니페스트는 하위 디렉터리가 없는 최상위에 있어야 합니다.

중요

정적 매니페스트가 아닌 일반 번들의 manifests/ 디렉터리에 콘텐츠를 포함하지 마십시오. 그렇지 않으면 해당 번들에서 클러스터상의 콘텐츠를 생성할 때 오류가 발생합니다. oc apply 명령을 사용하여 성공적으로 적용되지 않는 파일이 발생하면 오류가 발생합니다. 다중 오브젝트 YAML 또는 JSON 파일도 유효합니다.

2.2.3.1.3. 레지스트리 번들 사양

레지스트리 번들 또는 registry+v1 번들에는 기존 OLM(Operator Lifecycle Manager) 번들 형식으로 구성된 정적 Kubernetes YAML 매니페스트 세트가 포함되어 있습니다.

추가 리소스

2.2.3.2. BundleDeployment

주의

BundleDeployment 오브젝트는 오브젝트를 설치 및 제거하여 Kubernetes 클러스터의 상태를 변경합니다. RBAC를 사용하여 설치 중인 콘텐츠를 확인하고 해당 권한이 필요한 사용자에게만 BundleDeployment API에 대한 액세스를 제한하는 것이 중요합니다.

RukPak BundleDeployment API는 Bundle 오브젝트를 가리키며 활성화되어 있어야 함을 나타냅니다. 여기에는 이전 버전의 활성 번들에서 피벗하는 작업이 포함됩니다. BundleDeployment 오브젝트에는 원하는 번들에 대한 임베디드 사양도 포함될 수 있습니다.

Pod가 컨테이너 이미지의 인스턴스를 생성하는 것과 마찬가지로 번들 배포는 배포된 버전의 번들을 생성합니다. 번들 배포는 Pod 개념의 일반화로 볼 수 있습니다.

번들 배포에서 참조된 번들을 기반으로 클러스터를 변경하는 방법에 대한 세부 사항은 번들 배포를 모니터링하도록 구성된 프로비저너에 의해 정의됩니다.

일반 프로비저너에서 작동하도록 구성된 BundleDeployment 오브젝트의 예

apiVersion: core.rukpak.io/v1alpha1
kind: BundleDeployment
metadata:
  name: my-bundle-deployment
spec:
  provisionerClassName: core-rukpak-io-plain
  template:
    metadata:
      labels:
        app: my-bundle
    spec:
      source:
        type: image
        image:
          ref: my-bundle@sha256:xyz123
      provisionerClassName: core-rukpak-io-plain

2.2.3.3. 프로비저너 정보

RukPak은 Kubernetes 클러스터에 콘텐츠를 설치하고 관리하는 프로비전 프로그램으로 알려진 일련의 컨트롤러로 구성됩니다. RukPak은 또한 BundleBundleDeployment 의 두 가지 주요 API를 제공합니다. 이러한 구성 요소는 함께 작동하여 콘텐츠를 클러스터에 가져오고 설치하고 클러스터 내에서 리소스를 생성합니다.

현재 RukPak과 함께 두 개의 프로비저너가 구현되고 번들로 제공되는 일반 프로비저너plain+v0 번들의 압축을 풀고, OLM(Operator Lifecycle Manager) registry+v1 번들의 압축을 풉니다.

각 프로비저너에는 고유한 ID가 할당되며 해당 ID와 일치하는 spec.provisionerClassName 필드를 사용하여 BundleBundleDeployment 오브젝트를 조정합니다. 예를 들어 일반 프로비저너는 지정된 plain+v0 번들을 클러스터에 압축한 다음 인스턴스화하여 클러스터에서 번들 내용을 사용할 수 있도록 할 수 있습니다.

프로비저너는 프로비저너를 명시적으로 참조하는 BundleBundleDeployment 리소스에 감시를 배치합니다. 지정된 번들의 경우 프로비저너는 Bundle 리소스의 내용을 클러스터에 압축을 풉니다. 그런 다음 해당 번들을 참조하는 BundleDeployment 리소스가 제공되면 프로비저너는 번들 콘텐츠를 설치하고 해당 리소스의 라이프사이클을 관리합니다.

2.3. Operator 프레임워크 일반 용어집

이 주제에서는 OLM(Operator Lifecycle Manager) 및 Operator SDK를 포함하여 Operator 프레임워크와 관련된 일반 용어집을 제공합니다.

2.3.1. 일반 Operator 프레임워크 용어

2.3.1.1. 번들

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

2.3.1.2. 번들 이미지

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

2.3.1.3. 카탈로그 소스

카탈로그 소스 는 OLM에서 Operator 및 해당 종속 항목을 검색하고 설치하기 위해 쿼리할 수 있는 메타데이터 저장소를 나타냅니다.

2.3.1.4. 채널

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

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

2.3.1.5. 채널 헤드

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

2.3.1.6. 클러스터 서비스 버전

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

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

2.3.1.7. 종속성

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

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

2.3.1.8. 인덱스 이미지

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

2.3.1.9. 설치 계획

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

2.3.1.10. 멀티 테넌시

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

여러 사용자 또는 그룹에서 클러스터를 공유하는 경우 다중 테넌트 클러스터로 간주됩니다.

2.3.1.11. Operator group

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

2.3.1.12. 패키지

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

2.3.1.13. 레지스트리

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

2.3.1.14. Subscription

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

2.3.1.15. 업데이트 그래프

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

2.4. OLM(Operator Lifecycle Manager)

2.4.1. Operator Lifecycle Manager 개념 및 리소스

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

2.4.1.1. Operator Lifecycle Manager란?

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

그림 2.2. Operator Lifecycle Manager 워크플로

olm 워크플로

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

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

2.4.1.2. OLM 리소스

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

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

ClusterServiceVersion(CSV)

csv

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

CatalogSource

catsrc

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

서브스크립션

sub

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

InstallPlan

ip

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

OperatorGroup

og

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

OperatorConditions

-

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

2.4.1.2.1. 클러스터 서비스 버전

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

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

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

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

2.4.1.2.2. 카탈로그 소스

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

작은 정보

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

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

예 2.9. CatalogSource 오브젝트의 예

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

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

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

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

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

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

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

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

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

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

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

다음으로 변경합니다.

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

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

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

  • kube_major_version
  • kube_minor_version
  • kube_patch_version
참고

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

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

중요

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.1.2.3. 서브스크립션

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

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

Subscription 개체 예

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

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

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

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

2.4.1.2.4. 설치 계획

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

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

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

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

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

예 2.12. InstallPlan 오브젝트의 예

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

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

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

추가 리소스

2.4.1.2.6. Operator 상태

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

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

참고

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

추가 리소스

2.4.2. Operator Lifecycle Manager 아키텍처

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

2.4.2.1. 구성 요소의 역할

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

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

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

ClusterServiceVersion(CSV)

csv

OLM

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

InstallPlan

ip

카탈로그

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

CatalogSource

catsrc

카탈로그

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

서브스크립션

sub

카탈로그

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

OperatorGroup

og

OLM

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

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

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

Deployments

OLM

ServiceAccounts

(Cluster)Roles

(Cluster)RoleBindings

CRD(CustomResourceDefinitions)

카탈로그

ClusterServiceVersions

2.4.2.2. OLM Operator

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

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

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

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

    참고

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

2.4.2.3. Catalog Operator

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

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

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

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

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

2.4.2.4. 카탈로그 레지스트리

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

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

2.4.3. Operator Lifecycle Manager 워크플로

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

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

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

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

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

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

olm catalogsource

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

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

olm channels

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

참고

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

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

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

OLM 대체

패키지에 포함된 채널의 예

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

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

2.4.3.1.1. 업그레이드 경로의 예

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

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

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

2.4.3.1.2. 업그레이드 건너뛰기

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

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

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

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

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

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

릴리스를 건너뛰는 CSV의 예

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

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

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

업데이트를 건너뛰는 OLM

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

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

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

olm.skipRange: <semver_range>

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

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

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

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

skipRange가 있는 CSV의 예

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

2.4.3.1.4. z-stream 지원

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

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

그림 2.7. 여러 Operator 교체

olm z 스트림

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

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

2.4.4. Operator Lifecycle Manager 종속성 확인

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

2.4.4.1. 종속성 확인 정보

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

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

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

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

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

속성

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

제약 조건 또는 종속 항목

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

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

2.4.4.2. Operator 속성

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

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

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

임의의 속성의 예

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

2.4.4.2.1. 임의의 속성

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

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

임의의 속성의 예

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

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

2.4.4.3. Operator 종속 항목

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

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

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

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

dependencies.yaml 파일의 예

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

2.4.4.4. 일반 제약 조건

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

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

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

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

cel 제약 조건 예

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

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

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

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

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

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

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

모든 제약 조건의 예

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

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

제약 조건 예

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

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

제약 조건이 아닌

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

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

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

2.4.4.4.3. 중첩된 복합 제약 조건

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

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

중첩된 복합 제약 조건의 예

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

참고

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

2.4.4.5. 종속 기본 설정

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

2.4.4.5.1. 카탈로그 우선순위

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

CatalogSource 오브젝트의 예

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

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

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

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

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

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

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

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

2.4.4.5.3. 채널 내 순서

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

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

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

2.4.4.5.4. 기타 제약 조건

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

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

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

2.4.4.5.4.2. 패키지 제약 조건

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

2.4.4.5.5. 추가 리소스

2.4.4.6. CRD 업그레이드

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

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

2.4.4.7. 종속성 모범 사례

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

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

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

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

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

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

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

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

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

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

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

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

참고

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

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

추가 리소스

2.4.4.8. 종속성 경고

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

혼합 제약 조건(AND) 없음

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

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

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

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

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

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

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

예: 종속 API 사용 중단

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

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

결과는 다음과 같습니다.

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

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

예: 버전 교착 상태

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

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

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

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

2.4.5. Operator groups

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

2.4.5.1. Operator groups 정의

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

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

2.4.5.2. Operator group 멤버십

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

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

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

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

OwnNamespace

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

SingleNamespace

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

MultiNamespace

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

AllNamespaces

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

참고

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

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

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

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

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

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

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

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

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

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

2.4.5.4. Operator group CSV 주석

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

주석설명

olm.operatorGroup=<group_name>

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

olm.operatorNamespace=<group_namespace>

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

olm.targetNamespaces=<target_namespaces>

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

참고

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

2.4.5.5. 제공된 API 주석

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

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

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

2.4.5.6. 역할 기반 액세스 제어

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

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

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

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

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

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

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

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

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

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

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

<kind>의 동사:

  • *

집계 라벨:

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

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

<kind>의 동사:

  • create
  • update
  • patch
  • delete

집계 라벨:

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

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

<kind>의 동사:

  • get
  • list
  • watch

집계 라벨:

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

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

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

  • get

집계 라벨:

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

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

<kind>의 동사:

  • *

집계 라벨:

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

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

<kind>의 동사:

  • create
  • update
  • patch
  • delete

집계 라벨:

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

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

<kind>의 동사:

  • get
  • list
  • watch

집계 라벨:

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

추가 역할 및 역할 바인딩

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

2.4.5.7. CSV 복사본

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

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

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

참고

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

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

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

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

2.4.5.8. 정적 Operator groups

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

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

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

2.4.5.9. Operator group 교집합

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

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

참고

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

교집합 규칙

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2.4.5.11. Operator groups 문제 해결

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

클러스터 관리자는 다음 워크플로우를 사용하여 이 기본 동작을 수동으로 무시할 수 있습니다.

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

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

2.4.7. Operator 상태

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

2.4.7.1. Operator 조건 정보

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

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

참고

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

2.4.7.2. 지원되는 조건

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

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

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

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

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

Upgradeable Operator 조건의 예

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

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

2.4.7.3. 추가 리소스

2.4.8. Operator Lifecycle Manager 지표

2.4.8.1. 표시되는 지표

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

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

catalog_source_count

카탈로그 소스 수입니다.

catalogsource_ready

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

csv_abnormal

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

csv_count

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

csv_succeeded

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

csv_upgrade_count

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

install_plan_count

설치 계획 수입니다.

installplan_warnings_total

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

olm_resolution_duration_seconds

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

subscription_count

서브스크립션 수입니다.

subscription_sync_total

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

2.4.9. Operator Lifecycle Manager의 Webhook 관리

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

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

2.4.9.1. 추가 리소스

2.5. OperatorHub 이해

2.5.1. OperatorHub 정보

OperatorHub는 클러스터 관리자가 Operator를 검색하고 설치하는 데 사용하는 OpenShift Container Platform의 웹 콘솔 인터페이스입니다. 한 번의 클릭으로 Operator를 클러스터 외부 소스에서 가져와서 클러스터에 설치 및 구독하고 엔지니어링 팀에서 OLM(Operator Lifecycle Manager)을 사용하여 배포 환경에서 제품을 셀프서비스로 관리할 수 있습니다.

클러스터 관리자는 다음 카테고리로 그룹화된 카탈로그에서 선택할 수 있습니다.

카테고리설명

Red Hat Operator

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

인증된 Operator

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

Red Hat Marketplace

Red Hat Marketplace에서 구매할 수 있는 인증 소프트웨어입니다.

커뮤니티 Operator

redhat-openshift-ecosystem/community-operators-prod/operators GitHub 리포지토리의 관련 담당자가 유지 관리하는 선택적 표시 소프트웨어입니다. 공식적으로 지원되지 않습니다.

사용자 정의 Operator

클러스터에 직접 추가하는 Operator입니다. 사용자 정의 Operator를 추가하지 않은 경우 OperatorHub의 웹 콘솔에 사용자 정의 카테고리가 표시되지 않습니다.

OperatorHub의 Operator는 OLM에서 실행되도록 패키지됩니다. 여기에는 Operator를 설치하고 안전하게 실행하는 데 필요한 모든 CRD, RBAC 규칙, 배포, 컨테이너 이미지가 포함된 CSV(클러스터 서비스 버전)라는 YAML 파일이 포함됩니다. 또한 해당 기능 및 지원되는 Kubernetes 버전에 대한 설명과 같이 사용자가 볼 수 있는 정보가 포함됩니다.

Operator SDK는 OLM 및 OperatorHub에서 사용하도록 Operator를 패키지하는 개발자를 지원하는 데 사용할 수 있습니다. 고객이 액세스할 수 있도록 설정할 상용 애플리케이션이 있는 경우 Red Hat Partner Connect 포털(connect.redhat.com)에 제공된 인증 워크플로를 사용하여 포함합니다.

2.5.2. OperatorHub 아키텍처

OperatorHub UI 구성 요소는 기본적으로 openshift-marketplace 네임스페이스의 OpenShift Container Platform에서 Marketplace Operator에 의해 구동됩니다.

2.5.2.1. OperatorHub 사용자 정의 리소스

Marketplace Operator는 OperatorHub와 함께 제공되는 기본 CatalogSource 오브젝트를 관리하는 cluster라는 OperatorHub CR(사용자 정의 리소스)을 관리합니다. 이 리소스를 수정하여 기본 카탈로그를 활성화하거나 비활성화할 수 있어 제한된 네트워크 환경에서 OpenShift Container Platform을 구성할 때 유용합니다.

OperatorHub 사용자 정의 리소스의 예

apiVersion: config.openshift.io/v1
kind: OperatorHub
metadata:
  name: cluster
spec:
  disableAllDefaultSources: true 1
  sources: [ 2
    {
      name: "community-operators",
      disabled: false
    }
  ]

1
disableAllDefaultSources는 OpenShift Container Platform 설치 중 기본적으로 구성되는 모든 기본 카탈로그의 가용성을 제어하는 덮어쓰기입니다.
2
소스에 따라 disabled 매개변수 값을 변경하여 기본 카탈로그를 개별적으로 비활성화합니다.

2.5.3. 추가 리소스

2.6. Red Hat 제공 Operator 카탈로그

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

중요

OpenShift Container Platform 4.11부터 파일 기반 카탈로그 형식으로 기본 Red Hat 제공 Operator 카탈로그 릴리스입니다. 더 이상 사용되지 않는 SQLite 데이터베이스 형식으로 릴리스된 OpenShift Container Platform 4.6에 대한 기본 Red Hat 제공 Operator 카탈로그입니다.

SQLite 데이터베이스 형식과 관련된 opm 하위 명령, 플래그 및 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이 기능은 계속 지원되며 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 사용하는 카탈로그에 사용해야 합니다.

opm index prune 와 같은 SQLite 데이터베이스 형식을 사용하기 위한 opm 하위 명령 및 플래그는 파일 기반 카탈로그 형식에서는 작동하지 않습니다. 파일 기반 카탈로그 작업에 대한 자세한 내용은 Managing custom catalogs,Operator Framework 패키징 형식, oc-mirror 플러그인을 사용하여 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.

2.6.1. Operator 카탈로그 정보

Operator 카탈로그는 OLM(Operator Lifecycle Manager)에서 쿼리하여 Operator 및 해당 종속성을 검색하고 설치할 수 있는 메타데이터 리포지토리입니다. OLM은 항상 최신 버전의 카탈로그에 있는 Operator를 설치합니다.

Operator 번들 형식을 기반으로 하는 인덱스 이미지는 컨테이너화된 카탈로그 스냅샷입니다. 일련의 Operator 매니페스트 콘텐츠에 대한 포인터의 데이터베이스를 포함하는 변경 불가능한 아티팩트입니다. 카탈로그는 인덱스 이미지를 참조하여 클러스터에서 OLM에 대한 콘텐츠를 소싱할 수 있습니다.

카탈로그가 업데이트되면 최신 버전의 Operator가 변경되고 이전 버전은 제거되거나 변경될 수 있습니다. 또한 OLM이 네트워크가 제한된 환경의 OpenShift Container Platform 클러스터에서 실행되면 최신 콘텐츠를 가져오기 위해 인터넷에서 카탈로그에 직접 액세스할 수 없습니다.

클러스터 관리자는 Red Hat에서 제공하는 카탈로그를 기반으로 또는 처음부터 자체 사용자 정의 인덱스 이미지를 생성할 수 있습니다. 이 이미지는 클러스터에서 카탈로그 콘텐츠를 소싱하는 데 사용할 수 있습니다. 자체 인덱스 이미지를 생성하고 업데이트하면 클러스터에서 사용 가능한 Operator 세트를 사용자 정의할 수 있을 뿐만 아니라 앞서 언급한 제한된 네트워크 환경 문제도 방지할 수 있습니다.

중요

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

클러스터가 사용자 정의 카탈로그를 사용하는 경우 Operator 작성자가 워크로드 문제를 방지하고 호환되지 않는 업그레이드를 방지하는 방법에 대한 자세한 내용은 OpenShift Container Platform 버전과의 Operator 호환성 제어를 참조하십시오.

참고

OpenShift Container Platform 4.8 이상에서는 레거시 형식을 사용하는 사용자 지정 카탈로그를 포함하여 Operators에 대한 레거시 패키지 매니페스트 형식에 대한 지원이 제거되었습니다.

사용자 정의 카탈로그 이미지를 생성할 때 이전 버전의 OpenShift Container Platform 4에서는 oc adm catalog build 명령을 사용해야 했습니다. 이 명령은 여러 릴리스에서 더 이상 사용되지 않으며 지금은 제거되었습니다. OpenShift Container Platform 4.6부터 Red Hat 제공 인덱스 이미지를 사용할 수 있으므로 카탈로그 빌더는 opm index 명령을 사용하여 인덱스 이미지를 관리해야 합니다.

2.6.2. Red Hat 제공 Operator 카탈로그 정보

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

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

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

redhat-operators

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

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

certified-operators

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

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

redhat-marketplace

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

Red Hat Marketplace에서 구매할 수 있는 인증 소프트웨어입니다.

community-operators

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

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

다음으로 변경합니다.

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

2.7. 다중 테넌트 클러스터의 Operator

OLM(Operator Lifecycle Manager)의 기본 동작은 Operator 설치 중에 단순성을 제공하는 것을 목표로 합니다. 그러나 이 동작에는 특히 다중 테넌트 클러스터에서 유연성이 부족할 수 있습니다. OpenShift Container Platform 클러스터의 여러 테넌트가 Operator를 사용하려면 OLM의 기본 동작을 수행하려면 관리자가 최소 권한 원칙을 위반하는 것으로 간주할 수 있는 모든 네임스페이스 모드에서 Operator를 설치해야 합니다.

다음 시나리오를 고려하여 환경 및 요구 사항에 가장 적합한 Operator 설치 워크플로를 확인합니다.

2.7.1. 기본 Operator 설치 모드 및 동작

웹 콘솔을 사용하여 Operator를 관리자로 설치할 때 일반적으로 Operator의 기능에 따라 설치 모드에 대한 두 가지 선택 사항이 있습니다.

단일 네임스페이스
선택한 단일 네임스페이스에 Operator를 설치하고 해당 네임스페이스에서 Operator에서 사용할 수 있는 모든 권한을 만듭니다.
모든 네임스페이스
기본 openshift-operators 네임스페이스에 Operator를 설치하여 클러스터의 모든 네임스페이스를 감시하고 사용할 수 있습니다. Operator에서 요청하는 모든 권한을 모든 네임스페이스에서 사용할 수 있도록 합니다. 경우에 따라 Operator 작성자는 메타데이터를 정의하여 사용자에게 해당 Operator의 제안된 네임스페이스에 두 번째 옵션을 제공할 수 있습니다.

또한 영향을 받는 네임스페이스의 사용자는 네임스페이스의 역할에 따라 자신이 소유한 CR(사용자 정의 리소스)을 활용할 수 있는 Operator API에 액세스할 수 있습니다.

  • namespace-adminnamespace-edit 역할은 Operator API를 읽고 쓸 수 있으므로 사용할 수 있습니다.
  • namespace-view 역할은 해당 Operator의 CR 오브젝트를 읽을 수 있습니다.

Operator 자체가 선택한 네임스페이스에 설치되므로 단일 네임스페이스 모드의 경우 해당 Pod 및 서비스 계정도 있습니다. 모든 네임스페이스 모드의 경우 Operator의 권한이 모두 클러스터 역할로 자동 향상되므로 Operator에는 모든 네임스페이스에 이러한 권한이 있습니다.

2.7.2. 다중 테넌트 클러스터에 권장되는 솔루션

다중 네임스페이스 설치 모드가 존재하지만 매우 적은 Operator에서 지원합니다. 표준 All namespacesSingle namespace 설치 모드 간의 중간 솔루션으로 다음 워크플로를 사용하여 각 테넌트에 대해 동일한 Operator의 인스턴스를 여러 개 설치할 수 있습니다.

  1. 테넌트의 네임스페이스와 별도의 테넌트 Operator의 네임스페이스를 생성합니다.
  2. 테넌트 Operator 범위의 Operator group을 테넌트의 네임스페이스에만 생성합니다.
  3. 테넌트 Operator 네임스페이스에 Operator를 설치합니다.

결과적으로 Operator는 테넌트 Operator 네임스페이스에 상주하며 테넌트 네임스페이스를 감시하지만, 테넌트에서 Operator Pod 및 해당 서비스 계정을 볼 수 없거나 사용할 수 없습니다.

이 솔루션을 사용하면 더 나은 테넌트 분리, 리소스 사용 비용의 최소 권한 원칙, 제약 조건이 충족되도록 하는 추가 오케스트레이션을 제공합니다. 자세한 절차는 "다중 테넌트 클러스터용 Operator의 여러 인스턴스 준비"를 참조하십시오.

제한 사항 및 고려 사항

이 솔루션은 다음 제약 조건이 충족되는 경우에만 작동합니다.

  • 동일한 Operator의 모든 인스턴스가 동일한 버전이어야 합니다.
  • Operator는 다른 Operator에 대한 종속성을 가질 수 없습니다.
  • Operator는 CRD 변환 Webhook를 제공할 수 없습니다.
중요

동일한 클러스터에서 동일한 Operator의 다른 버전을 사용할 수 없습니다. 결국 다음 조건을 충족하면 Operator의 다른 인스턴스 설치가 차단됩니다.

  • 인스턴스가 최신 버전의 Operator가 아닙니다.
  • 인스턴스는 클러스터에서 이미 사용 중인 최신 버전 또는 버전이 없는 이전 버전의 CRD를 제공합니다.
주의

관리자는 "클러스터 이외의 관리자가 Operator를 설치할 수 있도록 허용"에 설명된 대로 클러스터 이외의 관리자가 Operator를 직접 설치할 수 있도록 허용할 때 주의해야 합니다. 이러한 테넌트는 종속 항목이 없는 것으로 알려진 Operator의 선별된 카탈로그에만 액세스할 수 있어야 합니다. 이러한 테넌트는 CRD가 변경되지 않도록 하려면 Operator의 동일한 버전 행을 사용해야 합니다. 이를 위해서는 네임스페이스 범위 카탈로그를 사용해야 하며 글로벌 기본 카탈로그를 비활성화해야 합니다.

2.7.3. Operator colocation 및 Operator groups

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

Operator 공동 배치 및 Operator 그룹을 효과적으로 사용하는 방법에 대한 자세한 내용은 OLM(Operator Lifecycle Manager) → 멀티 테넌시 및 Operator 공동 배치를 참조하십시오.

2.8. CRD

2.8.1. 사용자 정의 리소스 정의를 사용하여 Kubernetes API 확장

Operator는 Kubernetes 확장 메커니즘인 CRD(사용자 정의 리소스 정의)를 사용하므로 Operator에서 관리하는 사용자 정의 오브젝트가 네이티브 Kubernetes 오브젝트처럼 보이고 작동합니다. 이 가이드에서는 클러스터 관리자가 CRD를 생성하고 관리하여 OpenShift Container Platform 클러스터를 확장할 수 있는 방법을 설명합니다.

2.8.1.1. 사용자 정의 리소스 정의

Kubernetes API에서 리소스는 특정 종류의 API 오브젝트 컬렉션을 저장하는 끝점입니다. 예를 들어 기본 제공 Pod 리소스에는 Pod 오브젝트의 컬렉션이 포함됩니다.

CRD(사용자 정의 리소스 정의) 오브젝트는 클러스터에서 종류라는 새로운 고유한 오브젝트 유형을 정의하고 Kubernetes API 서버에서 전체 라이프사이클을 처리하도록 합니다.

CR(사용자 정의 리소스) 오브젝트는 클러스터 관리자가 클러스터에 추가한 CRD에서 생성하므로 모든 클러스터 사용자가 새 리소스 유형을 프로젝트에 추가할 수 있습니다.

클러스터 관리자가 새 CRD를 클러스터에 추가하면 Kubernetes API 서버는 전체 클러스터 또는 단일 프로젝트(네임스페이스)에서 액세스할 수 있는 새 RESTful 리소스 경로를 생성하여 반응하고 지정된 CR을 제공하기 시작합니다.

클러스터 관리자가 다른 사용자에게 CRD에 대한 액세스 권한을 부여하려면 클러스터 역할 집계를 사용하여 admin, edit 또는 view 기본 클러스터 역할이 있는 사용자에게 액세스 권한을 부여할 수 있습니다. 클러스터 역할 집계를 사용하면 이러한 클러스터 역할에 사용자 정의 정책 규칙을 삽입할 수 있습니다. 이 동작은 새 리소스를 기본 제공 리소스인 것처럼 클러스터의 RBAC 정책에 통합합니다.

특히 운영자는 CRD를 필수 RBAC 정책 및 기타 소프트웨어별 논리와 함께 패키지로 제공하는 방식으로 CRD를 사용합니다. 또한 클러스터 관리자는 Operator의 라이프사이클 외부에서 클러스터에 CRD를 수동으로 추가하여 모든 사용자에게 제공할 수 있습니다.

참고

클러스터 관리자만 CRD를 생성할 수 있지만 기존 CRD에 대한 읽기 및 쓰기 권한이 있는 개발자의 경우 기존 CRD에서 CR을 생성할 수 있습니다.

2.8.1.2. 사용자 정의 리소스 정의 생성

사용자 정의 리소스(CR) 오브젝트를 생성하려면 클러스터 관리자가 먼저 CRD(사용자 정의 리소스 정의)를 생성해야 합니다.

사전 요구 사항

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

프로세스

CRD를 생성하려면 다음을 수행합니다.

  1. 다음 필드 유형을 포함하는 YAML 파일을 생성합니다.

    CRD에 대한 YAML 파일의 예

    apiVersion: apiextensions.k8s.io/v1 1
    kind: CustomResourceDefinition
    metadata:
      name: crontabs.stable.example.com 2
    spec:
      group: stable.example.com 3
      versions:
        - name: v1 4
          served: true
          storage: true
          schema:
            openAPIV3Schema:
              type: object
              properties:
                spec:
                  type: object
                  properties:
                    cronSpec:
                      type: string
                    image:
                      type: string
                    replicas:
                      type: integer
      scope: Namespaced 5
      names:
        plural: crontabs 6
        singular: crontab 7
        kind: CronTab 8
        shortNames:
        - ct 9

    1
    apiextensions.k8s.io/v1 API를 사용합니다.
    2
    정의의 이름을 지정합니다. groupplural 필드의 값을 사용하는 <plural-name>.<group> 형식이어야 합니다.
    3
    API의 그룹 이름을 지정합니다. API 그룹은 논리적으로 관련된 오브젝트의 컬렉션입니다. 예를 들어 Job 또는 ScheduledJob과 같은 배치 오브젝트는 모두 배치 API 그룹(예: batch.api.example.com)에 있을 수 있습니다. 조직의 FQDN(정규화된 도메인 이름)을 사용하는 것이 좋습니다.
    4
    URL에 사용할 버전 이름을 지정합니다. 각 API 그룹은 여러 버전(예: v1alpha, v1beta, v1)에 있을 수 있습니다.
    5
    특정 프로젝트(Namespaced) 또는 클러스터의 모든 프로젝트(Cluster)에서 사용자 정의 오브젝트를 사용할 수 있는지 지정합니다.
    6
    URL에서 사용할 복수형 이름을 지정합니다. plural 필드는 API URL의 리소스와 동일합니다.
    7
    CLI 및 디스플레이에서 별칭으로 사용할 단수형 이름을 지정합니다.
    8
    생성할 수 있는 오브젝트의 종류를 지정합니다. 유형은 CamelCase에 있을 수 있습니다.
    9
    CLI의 리소스와 일치하는 짧은 문자열을 지정합니다.
    참고

    기본적으로 CRD는 클러스터 범위이며 모든 프로젝트에서 사용할 수 있습니다.

  2. CRD 오브젝트를 생성합니다.

    $ oc create -f <file_name>.yaml

    다음에 새 RESTful API 끝점이 생성됩니다.

    /apis/<spec:group>/<spec:version>/<scope>/*/<names-plural>/...

    예를 들어 예제 파일을 사용하면 다음 끝점이 생성됩니다.

    /apis/stable.example.com/v1/namespaces/*/crontabs/...

    이 끝점 URL을 사용하여 CR을 생성하고 관리할 수 있습니다. 오브젝트 종류는 생성한 CRD 오브젝트의 spec.kind 필드를 기반으로 합니다.

2.8.1.3. 사용자 정의 리소스 정의에 대한 클러스터 역할 생성

클러스터 관리자는 기존 클러스터 범위의 CRD(사용자 정의 리소스 정의)에 권한을 부여할 수 있습니다. admin, edit, view 기본 클러스터 역할을 사용하는 경우 해당 규칙에 클러스터 역할 집계를 활용할 수 있습니다.

중요

이러한 각 역할에 대한 권한을 명시적으로 할당해야 합니다. 권한이 더 많은 역할은 권한이 더 적은 역할의 규칙을 상속하지 않습니다. 역할에 규칙을 할당하는 경우 권한이 더 많은 역할에 해당 동사를 할당해야 합니다. 예를 들어 보기 역할에 get crontabs 권한을 부여하는 경우 editadmin 역할에도 부여해야 합니다. admin 또는 edit 역할은 일반적으로 프로젝트 템플릿을 통해 프로젝트를 생성한 사용자에게 할당됩니다.

사전 요구 사항

  • CRD를 생성합니다.

프로세스

  1. CRD의 클러스터 역할 정의 파일을 생성합니다. 클러스터 역할 정의는 각 클러스터 역할에 적용되는 규칙이 포함된 YAML 파일입니다. OpenShift Container Platform 컨트롤러는 지정하는 규칙을 기본 클러스터 역할에 추가합니다.

    클러스터 역할 정의에 대한 YAML 파일의 예

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1 1
    metadata:
      name: aggregate-cron-tabs-admin-edit 2
      labels:
        rbac.authorization.k8s.io/aggregate-to-admin: "true" 3
        rbac.authorization.k8s.io/aggregate-to-edit: "true" 4
    rules:
    - apiGroups: ["stable.example.com"] 5
      resources: ["crontabs"] 6
      verbs: ["get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"] 7
    ---
    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: aggregate-cron-tabs-view 8
      labels:
        # Add these permissions to the "view" default role.
        rbac.authorization.k8s.io/aggregate-to-view: "true" 9
        rbac.authorization.k8s.io/aggregate-to-cluster-reader: "true" 10
    rules:
    - apiGroups: ["stable.example.com"] 11
      resources: ["crontabs"] 12
      verbs: ["get", "list", "watch"] 13

    1
    rbac.authorization.k8s.io/v1 API를 사용합니다.
    2 8
    정의의 이름을 지정합니다.
    3
    관리 기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
    4
    편집 기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
    5 11
    CRD의 그룹 이름을 지정합니다.
    6 12
    이러한 규칙이 적용되는 CRD의 복수형 이름을 지정합니다.
    7 13
    역할에 부여된 권한을 나타내는 동사를 지정합니다. 예를 들어 adminedit 역할에는 읽기 및 쓰기 권한을 적용하고 view 역할에는 읽기 권한만 적용합니다.
    9
    view 기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
    10
    cluster-reader 기본 역할에 권한을 부여하려면 이 라벨을 지정합니다.
  2. 클러스터 역할을 생성합니다.

    $ oc create -f <file_name>.yaml

2.8.1.4. 파일에서 사용자 정의 리소스 생성

CRD(사용자 정의 리소스 정의)가 클러스터에 추가되면 CR 사양을 사용하여 파일에서 CLI를 사용하여 CR(사용자 정의 리소스)을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자가 클러스터에 CRD를 추가했습니다.

프로세스

  1. CR에 대한 YAML 파일을 생성합니다. 다음 예제 정의에서 cronSpecimage 사용자 정의 필드는 Kind: CronTab의 CR에 설정됩니다. Kind는 CRD 오브젝트의 spec.kind 필드에서 제공합니다.

    CR에 대한 YAML 파일의 예

    apiVersion: "stable.example.com/v1" 1
    kind: CronTab 2
    metadata:
      name: my-new-cron-object 3
      finalizers: 4
      - finalizer.stable.example.com
    spec: 5
      cronSpec: "* * * * /5"
      image: my-awesome-cron-image

    1
    CRD에서 그룹 이름 및 API 버전(이름/버전)을 지정합니다.
    2
    CRD에 유형을 지정합니다.
    3
    오브젝트의 이름을 지정합니다.
    4
    해당하는 경우 오브젝트의 종료자를 지정합니다. 종료자를 사용하면 컨트롤러에서 오브젝트를 삭제하기 전에 완료해야 하는 조건을 구현할 수 있습니다.
    5
    오브젝트 유형별 조건을 지정합니다.
  2. 파일을 생성한 후 오브젝트를 생성합니다.

    $ oc create -f <file_name>.yaml

2.8.1.5. 사용자 정의 리소스 검사

CLI를 사용하여 클러스터에 존재하는 CR(사용자 정의 리소스) 오브젝트를 검사할 수 있습니다.

사전 요구 사항

  • CR 오브젝트는 액세스할 수 있는 네임스페이스에 있습니다.

프로세스

  1. 특정 종류의 CR에 대한 정보를 얻으려면 다음을 실행합니다.

    $ oc get <kind>

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

    $ oc get crontab

    출력 예

    NAME                 KIND
    my-new-cron-object   CronTab.v1.stable.example.com

    리소스 이름은 대소문자를 구분하지 않으며 CRD에 정의된 단수형 또는 복수형 양식이나 짧은 이름을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

    $ oc get crontabs
    $ oc get crontab
    $ oc get ct
  2. CR의 원시 YAML 데이터를 볼 수도 있습니다.

    $ oc get <kind> -o yaml

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

    $ oc get ct -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: stable.example.com/v1
      kind: CronTab
      metadata:
        clusterName: ""
        creationTimestamp: 2017-05-31T12:56:35Z
        deletionGracePeriodSeconds: null
        deletionTimestamp: null
        name: my-new-cron-object
        namespace: default
        resourceVersion: "285"
        selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
        uid: 9423255b-4600-11e7-af6a-28d2447dc82b
      spec:
        cronSpec: '* * * * /5' 1
        image: my-awesome-cron-image 2

    1 2
    오브젝트를 생성하는 데 사용한 YAML의 사용자 정의 데이터가 표시됩니다.

2.8.2. 사용자 정의 리소스 정의에서 리소스 관리

이 가이드에서는 개발자가 CRD(사용자 정의 리소스 정의)에서 제공하는 CR(사용자 정의 리소스)을 관리하는 방법을 설명합니다.

2.8.2.1. 사용자 정의 리소스 정의

Kubernetes API에서 리소스는 특정 종류의 API 오브젝트 컬렉션을 저장하는 끝점입니다. 예를 들어 기본 제공 Pod 리소스에는 Pod 오브젝트의 컬렉션이 포함됩니다.

CRD(사용자 정의 리소스 정의) 오브젝트는 클러스터에서 종류라는 새로운 고유한 오브젝트 유형을 정의하고 Kubernetes API 서버에서 전체 라이프사이클을 처리하도록 합니다.

CR(사용자 정의 리소스) 오브젝트는 클러스터 관리자가 클러스터에 추가한 CRD에서 생성하므로 모든 클러스터 사용자가 새 리소스 유형을 프로젝트에 추가할 수 있습니다.

특히 운영자는 CRD를 필수 RBAC 정책 및 기타 소프트웨어별 논리와 함께 패키지로 제공하는 방식으로 CRD를 사용합니다. 또한 클러스터 관리자는 Operator의 라이프사이클 외부에서 클러스터에 CRD를 수동으로 추가하여 모든 사용자에게 제공할 수 있습니다.

참고

클러스터 관리자만 CRD를 생성할 수 있지만 기존 CRD에 대한 읽기 및 쓰기 권한이 있는 개발자의 경우 기존 CRD에서 CR을 생성할 수 있습니다.

2.8.2.2. 파일에서 사용자 정의 리소스 생성

CRD(사용자 정의 리소스 정의)가 클러스터에 추가되면 CR 사양을 사용하여 파일에서 CLI를 사용하여 CR(사용자 정의 리소스)을 생성할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자가 클러스터에 CRD를 추가했습니다.

프로세스

  1. CR에 대한 YAML 파일을 생성합니다. 다음 예제 정의에서 cronSpecimage 사용자 정의 필드는 Kind: CronTab의 CR에 설정됩니다. Kind는 CRD 오브젝트의 spec.kind 필드에서 제공합니다.

    CR에 대한 YAML 파일의 예

    apiVersion: "stable.example.com/v1" 1
    kind: CronTab 2
    metadata:
      name: my-new-cron-object 3
      finalizers: 4
      - finalizer.stable.example.com
    spec: 5
      cronSpec: "* * * * /5"
      image: my-awesome-cron-image

    1
    CRD에서 그룹 이름 및 API 버전(이름/버전)을 지정합니다.
    2
    CRD에 유형을 지정합니다.
    3
    오브젝트의 이름을 지정합니다.
    4
    해당하는 경우 오브젝트의 종료자를 지정합니다. 종료자를 사용하면 컨트롤러에서 오브젝트를 삭제하기 전에 완료해야 하는 조건을 구현할 수 있습니다.
    5
    오브젝트 유형별 조건을 지정합니다.
  2. 파일을 생성한 후 오브젝트를 생성합니다.

    $ oc create -f <file_name>.yaml

2.8.2.3. 사용자 정의 리소스 검사

CLI를 사용하여 클러스터에 존재하는 CR(사용자 정의 리소스) 오브젝트를 검사할 수 있습니다.

사전 요구 사항

  • CR 오브젝트는 액세스할 수 있는 네임스페이스에 있습니다.

프로세스

  1. 특정 종류의 CR에 대한 정보를 얻으려면 다음을 실행합니다.

    $ oc get <kind>

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

    $ oc get crontab

    출력 예

    NAME                 KIND
    my-new-cron-object   CronTab.v1.stable.example.com

    리소스 이름은 대소문자를 구분하지 않으며 CRD에 정의된 단수형 또는 복수형 양식이나 짧은 이름을 사용할 수 있습니다. 예를 들면 다음과 같습니다.

    $ oc get crontabs
    $ oc get crontab
    $ oc get ct
  2. CR의 원시 YAML 데이터를 볼 수도 있습니다.

    $ oc get <kind> -o yaml

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

    $ oc get ct -o yaml

    출력 예

    apiVersion: v1
    items:
    - apiVersion: stable.example.com/v1
      kind: CronTab
      metadata:
        clusterName: ""
        creationTimestamp: 2017-05-31T12:56:35Z
        deletionGracePeriodSeconds: null
        deletionTimestamp: null
        name: my-new-cron-object
        namespace: default
        resourceVersion: "285"
        selfLink: /apis/stable.example.com/v1/namespaces/default/crontabs/my-new-cron-object
        uid: 9423255b-4600-11e7-af6a-28d2447dc82b
      spec:
        cronSpec: '* * * * /5' 1
        image: my-awesome-cron-image 2

    1 2
    오브젝트를 생성하는 데 사용한 YAML의 사용자 정의 데이터가 표시됩니다.

3장. 사용자 작업

3.1. 설치된 Operator에서 애플리케이션 생성

이 가이드에서는 개발자에게 OpenShift Container Platform 웹 콘솔을 사용하여 설치한 Operator에서 애플리케이션을 생성하는 예제를 안내합니다.

3.1.1. Operator를 사용하여 etcd 클러스터 생성

이 절차에서는 OLM(Operator Lifecycle Manager)에서 관리하는 etcd Operator를 사용하여 새 etcd 클러스터를 생성하는 과정을 안내합니다.

사전 요구 사항

  • OpenShift Container Platform 4.15 클러스터에 액세스할 수 있습니다.
  • 관리자가 클러스터 수준에 etcd Operator를 이미 설치했습니다.

프로세스

  1. 이 절차를 위해 OpenShift Container Platform 웹 콘솔에 새 프로젝트를 생성합니다. 이 예제에서는 my-etcd라는 프로젝트를 사용합니다.
  2. Operator → 설치된 Operator 페이지로 이동합니다. 이 페이지에는 클러스터 관리자가 클러스터에 설치하여 사용할 수 있는 Operator가 CSV(클러스터 서비스 버전) 목록으로 표시됩니다. CSV는 Operator에서 제공하는 소프트웨어를 시작하고 관리하는 데 사용됩니다.

    작은 정보

    다음을 사용하여 CLI에서 이 목록을 가져올 수 있습니다.

    $ oc get csv
  3. 자세한 내용과 사용 가능한 작업을 확인하려면 설치된 Operator 페이지에서 etcd Operator를 클릭합니다.

    이 Operator에서는 제공된 API 아래에 표시된 것과 같이 etcd 클러스터(EtcdCluster 리소스)용 하나를 포함하여 새로운 리소스 유형 세 가지를 사용할 수 있습니다. 이러한 오브젝트는 내장된 네이티브 Kubernetes 오브젝트(예: Deployment 또는 ReplicaSet)와 비슷하게 작동하지만 etcd 관리와 관련된 논리가 포함됩니다.

  4. 새 etcd 클러스터를 생성합니다.

    1. etcd 클러스터 API 상자에서 인스턴스 생성을 클릭합니다.
    2. 다음 페이지에서는 클러스터 크기와 같은 EtcdCluster 오브젝트의 최소 시작 템플릿을 수정할 수 있습니다. 지금은 생성을 클릭하여 종료하십시오. 그러면 Operator에서 새 etcd 클러스터의 Pod, 서비스 및 기타 구성 요소를 가동합니다.
  5. 예제 etcd 클러스터를 클릭한 다음 리소스 탭을 클릭하여 Operator에 의해 자동으로 생성 및 구성된 여러 리소스가 프로젝트에 포함되어 있는지 확인합니다.

    프로젝트의 다른 Pod에서 데이터베이스에 액세스할 수 있도록 Kubernetes 서비스가 생성되었는지 확인합니다.

  6. 지정된 프로젝트에서 edit 역할을 가진 모든 사용자는 클라우드 서비스와 마찬가지로 셀프 서비스 방식으로 프로젝트에 이미 생성된 Operator에서 관리하는 애플리케이션 인스턴스(이 예제의 etcd 클러스터)를 생성, 관리, 삭제할 수 있습니다. 이 기능을 사용하여 추가 사용자를 활성화하려면 프로젝트 관리자가 다음 명령을 사용하여 역할을 추가하면 됩니다.

    $ oc policy add-role-to-user edit <user> -n <target_project>

이제 Pod가 비정상적인 상태가 되거나 클러스터의 다른 노드로 마이그레이션되면 오류에 반응하고 데이터를 재조정할 etcd 클러스터가 생성되었습니다. 가장 중요한 점은 적절한 액세스 권한이 있는 클러스터 관리자 또는 개발자가 애플리케이션과 함께 데이터베이스를 쉽게 사용할 수 있다는 점입니다.

3.2. 네임스페이스에 Operator 설치

클러스터 관리자가 계정에 Operator 설치 권한을 위임한 경우 셀프서비스 방식으로 Operator를 설치하고 네임스페이스에 등록할 수 있습니다.

3.2.1. 사전 요구 사항

3.2.2. OperatorHub를 통한 Operator 설치 정보

OperatorHub는 Operator를 검색하는 사용자 인터페이스입니다. 이는 클러스터에 Operator를 설치하고 관리하는 OLM(Operator Lifecycle Manager)과 함께 작동합니다.

적절한 권한이 있는 사용자는 OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다.

설치하는 동안 Operator의 다음 초기 설정을 결정해야합니다.

설치 모드
Operator를 설치할 특정 네임스페이스를 선택합니다.
업데이트 채널
여러 채널을 통해 Operator를 사용할 수있는 경우 구독할 채널을 선택할 수 있습니다. 예를 들어, stable 채널에서 배치하려면 (사용 가능한 경우) 목록에서 해당 채널을 선택합니다.
승인 전략

자동 또는 수동 업데이트를 선택할 수 있습니다.

설치된 Operator에 대해 자동 업데이트를 선택하는 경우 선택한 채널에 해당 Operator의 새 버전이 제공되면 OLM(Operator Lifecycle Manager)에서 Operator의 실행 중인 인스턴스를 개입 없이 자동으로 업그레이드합니다.

수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM이 업데이트 요청을 작성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

3.2.3. 웹 콘솔을 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Operator를 설치하고 구독할 수 있습니다.

사전 요구 사항

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

프로세스

  1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.
  2. 원하는 Operator를 찾으려면 키워드를 Filter by keyword 상자에 입력하거나 스크롤합니다. 예를 들어 Kubernetes Operator의 고급 클러스터 관리 기능을 찾으려면 advanced를 입력합니다.

    인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.

  3. Operator를 선택하여 추가 정보를 표시합니다.

    참고

    커뮤니티 Operator를 선택하면 Red Hat이 커뮤니티 Operator를 인증하지 않는다고 경고합니다. 계속하기 전에 경고를 확인해야합니다.

  4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.
  5. Operator 설치 페이지에서 다음을 수행합니다.

    1. Operator를 설치할 특정 단일 네임스페이스를 선택합니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
    2. 토큰 인증이 활성화된 클라우드 공급자의 클러스터의 경우:

      • 클러스터가 AWS STS(웹 콘솔에서STS 모드 )를 사용하는 경우 역할 ARN 필드에 서비스 계정의 AWS IAM 역할의 Amazon Resource Name( ARN )을 입력합니다.

        ARN 입력

        역할의 ARN을 생성하려면 AWS 계정 준비에 설명된 절차를 따르십시오.

      • 클러스터에서 Microsoft Entra Workload ID(웹 콘솔에서워크로드 ID / Federated Identity Mode )를 사용하는 경우 적절한 필드에 클라이언트 ID, 테넌트 ID 및 구독 ID를 추가합니다.
    3. 둘 이상의 업데이트 채널을 사용할 수 있는 경우 업데이트 채널을 선택합니다.
    4. 앞에서 설명한 대로 자동 또는 수동 승인 전략을 선택합니다.

      중요

      웹 콘솔에 AWS STS 또는 Microsoft Entra Workload ID를 사용하는 클러스터가 표시되는 경우 업데이트 승인을 Manual 로 설정해야 합니다.

      자동 업데이트 승인이 있는 서브스크립션은 업데이트하기 전에 권한을 변경할 수 있으므로 권장되지 않습니다. 수동 업데이트 승인이 있는 서브스크립션을 통해 관리자는 최신 버전의 권한을 확인하고 업데이트 전에 필요한 단계를 수행할 수 있습니다.

  6. 이 OpenShift Container Platform 클러스터에서 선택한 네임스페이스에서 Operator를 사용할 수 있도록 하려면 설치를 클릭합니다.

    1. 수동 승인 전략을 선택한 경우 설치 계획을 검토하고 승인할 때까지 서브스크립션의 업그레이드 상태가 업그레이드 중으로 유지됩니다.

      Install Plan 페이지에서 승인 한 후 subscription 업그레이드 상태가 Up to date로 이동합니다.

    2. 자동 승인 전략을 선택한 경우 업그레이드 상태가 개입 없이 최신 상태로 확인되어야 합니다.
  7. 서브스크립션의 업그레이드 상태가 최신이면 Operator → 설치된 Operator를 선택하여 설치된 Operator의 CSV(클러스터 서비스 버전)가 최종적으로 표시되는지 확인합니다. 상태는 최종적으로 관련 네임스페이스에서 InstallSucceeded로 확인되어야 합니다.

    참고

    모든 네임스페이스…​ 설치 모드의 경우, openshift-operators 네임스페이스에서 상태가 InstallSucceeded로 확인되지만 다른 네임스페이스에서 확인하면 상태가 복사됨입니다.

    그렇지 않은 경우 다음을 수행합니다.

    1. 워크로드 → Pod 페이지의 openshift-operators 프로젝트(또는 특정 네임스페이스…​설치 모드가 선택된 경우 기타 관련 네임스페이스)에서 문제를 보고하는 모든 Pod의 로그를 확인하여 문제를 추가로 해결합니다.

3.2.4. CLI를 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하는 대신 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다. oc 명령을 사용하여 Subscription 개체를 만들거나 업데이트합니다.

사전 요구 사항

  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. OperatorHub에서 클러스터에 사용 가능한 Operator의 목록을 표시합니다.

    $ oc get packagemanifests -n openshift-marketplace

    출력 예

    NAME                               CATALOG               AGE
    3scale-operator                    Red Hat Operators     91m
    advanced-cluster-management        Red Hat Operators     91m
    amq7-cert-manager                  Red Hat Operators     91m
    ...
    couchbase-enterprise-certified     Certified Operators   91m
    crunchy-postgres-operator          Certified Operators   91m
    mongodb-enterprise                 Certified Operators   91m
    ...
    etcd                               Community Operators   91m
    jaeger                             Community Operators   91m
    kubefed                            Community Operators   91m
    ...

    필요한 Operator의 카탈로그를 기록해 둡니다.

  2. 필요한 Operator를 검사하여 지원되는 설치 모드 및 사용 가능한 채널을 확인합니다.

    $ oc describe packagemanifests <operator_name> -n openshift-marketplace
  3. OperatorGroup 오브젝트로 정의되는 Operator group에서 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

    Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces 모드를 사용하는 경우 openshift-operators 네임스페이스에 적절한 global-operators Operator group이 이미 있습니다.

    그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

    참고
    • 이 프로세스의 웹 콘솔 버전에서는 SingleNamespace 모드를 선택할 때 자동으로 OperatorGroupSubscription 개체 생성을 자동으로 처리합니다.
    • 네임스페이스당 하나의 Operator 그룹만 있을 수 있습니다. 자세한 내용은 "Operator groups"을 참조하십시오.
    1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml
  4. Subscription 개체 YAML 파일을 생성하여 OpenShift Pipelines Operator에 네임스페이스를 등록합니다(예: sub.yaml).

    Subscription 개체 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: <subscription_name>
      namespace: openshift-operators 1
    spec:
      channel: <channel_name> 2
      name: <operator_name> 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace 5
      config:
        env: 6
        - name: ARGS
          value: "-v=10"
        envFrom: 7
        - secretRef:
            name: license-secret
        volumes: 8
        - name: <volume_name>
          configMap:
            name: <configmap_name>
        volumeMounts: 9
        - mountPath: <directory_name>
          name: <volume_name>
        tolerations: 10
        - operator: "Exists"
        resources: 11
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        nodeSelector: 12
          foo: bar

    1
    기본 AllNamespaces 설치 모드 사용량의 경우 openshift-operators 네임스페이스를 지정합니다. 또는 사용자 지정 글로벌 네임스페이스를 생성한 경우 지정할 수 있습니다. 그 외에는 SingleNamespace 설치 모드를 사용하도록 관련 단일 네임스페이스를 지정합니다.
    2
    등록할 채널의 이름입니다.
    3
    등록할 Operator의 이름입니다.
    4
    Operator를 제공하는 카탈로그 소스의 이름입니다.
    5
    카탈로그 소스의 네임스페이스입니다. 기본 OperatorHub 카탈로그 소스에는 openshift-marketplace를 사용합니다.
    6
    env 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 있어야 하는 환경 변수 목록을 정의합니다.
    7
    envFrom 매개 변수는 컨테이너에서 환경 변수를 채울 소스 목록을 정의합니다.
    8
    volumes 매개변수는 OLM에서 생성한 Pod에 있어야 하는 볼륨 목록을 정의합니다.
    9
    volumeMounts 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 있어야 하는 볼륨 마운트 목록을 정의합니다. volume Mount 가 존재하지 않는 볼륨을 참조하는 경우 OLM에서 Operator를 배포하지 못합니다.
    10
    tolerations 매개변수는 OLM에서 생성한 Pod의 허용 목록을 정의합니다.
    11
    resources 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.
    12
    nodeSelector 매개변수는 OLM에서 생성한 Pod에 대한 NodeSelector 를 정의합니다.
  5. 토큰 인증이 활성화된 클라우드 공급자의 클러스터의 경우:

    1. Subscription 오브젝트가 수동 업데이트 승인으로 설정되어 있는지 확인합니다.

      kind: Subscription
      # ...
      spec:
        installPlanApproval: Manual 1
      1
      자동 업데이트 승인이 있는 서브스크립션은 업데이트하기 전에 권한을 변경할 수 있으므로 권장되지 않습니다. 수동 업데이트 승인이 있는 서브스크립션을 통해 관리자는 최신 버전의 권한을 확인하고 업데이트 전에 필요한 단계를 수행할 수 있습니다.
    2. Subscription 오브젝트의 config 섹션에 관련 클라우드 공급자별 필드를 포함합니다.

      • 클러스터가 AWS STS 모드에 있는 경우 다음 필드를 포함합니다.

        kind: Subscription
        # ...
        spec:
          config:
            env:
            - name: ROLEARN
              value: "<role_arn>" 1
        1
        역할 ARN 세부 정보를 포함합니다.
      • 클러스터가 Microsoft Entra Workload ID 모드에 있는 경우 다음 필드를 포함합니다.

        kind: Subscription
        # ...
        spec:
         config:
           env:
           - name: CLIENTID
             value: "<client_id>" 1
           - name: TENANTID
             value: "<tenant_id>" 2
           - name: SUBSCRIPTIONID
             value: "<subscription_id>" 3
        1
        클라이언트 ID를 포함합니다.
        2
        테넌트 ID를 포함합니다.
        3
        서브스크립션 ID를 포함합니다.
  6. Subscription 오브젝트를 생성합니다.

    $ oc apply -f sub.yaml

    이 시점에서 OLM은 이제 선택한 Operator를 인식합니다. Operator의 CSV(클러스터 서비스 버전)가 대상 네임스페이스에 표시되고 Operator에서 제공하는 API를 생성에 사용할 수 있어야 합니다.

추가 리소스

3.2.5. 특정 버전의 Operator 설치

Subscription 오브젝트에 CSV(클러스터 서비스 버전)를 설정하면 특정 버전의 Operator를 설치할 수 있습니다.

사전 요구 사항

  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 설치할 Operator의 사용 가능한 버전 및 채널을 찾습니다.

    명령 구문

    $ oc describe packagemanifests <operator_name> -n <catalog_namespace>

    예를 들어 다음 명령은 OperatorHub에서 사용 가능한 채널 및 버전의 Red Hat Quay Operator를 출력합니다.

    명령 예

    $ oc describe packagemanifests quay-operator -n openshift-marketplace

    예 3.1. 출력 예

    Name:         quay-operator
    Namespace:    operator-marketplace
    Labels:       catalog=redhat-operators
                  catalog-namespace=openshift-marketplace
                  hypershift.openshift.io/managed=true
                  operatorframework.io/arch.amd64=supported
                  operatorframework.io/os.linux=supported
                  provider=Red Hat
                  provider-url=
    Annotations:  <none>
    API Version:  packages.operators.coreos.com/v1
    Kind:         PackageManifest
    ...
        Current CSV:  quay-operator.v3.7.11
    ...
        Entries:
          Name:       quay-operator.v3.7.11
          Version:    3.7.11
          Name:       quay-operator.v3.7.10
          Version:    3.7.10
          Name:       quay-operator.v3.7.9
          Version:    3.7.9
          Name:       quay-operator.v3.7.8
          Version:    3.7.8
          Name:       quay-operator.v3.7.7
          Version:    3.7.7
          Name:       quay-operator.v3.7.6
          Version:    3.7.6
          Name:       quay-operator.v3.7.5
          Version:    3.7.5
          Name:       quay-operator.v3.7.4
          Version:    3.7.4
          Name:       quay-operator.v3.7.3
          Version:    3.7.3
          Name:       quay-operator.v3.7.2
          Version:    3.7.2
          Name:       quay-operator.v3.7.1
          Version:    3.7.1
          Name:       quay-operator.v3.7.0
          Version:    3.7.0
        Name:         stable-3.7
    ...
       Current CSV:  quay-operator.v3.8.5
    ...
       Entries:
          Name:         quay-operator.v3.8.5
          Version:      3.8.5
          Name:         quay-operator.v3.8.4
          Version:      3.8.4
          Name:         quay-operator.v3.8.3
          Version:      3.8.3
          Name:         quay-operator.v3.8.2
          Version:      3.8.2
          Name:         quay-operator.v3.8.1
          Version:      3.8.1
          Name:         quay-operator.v3.8.0
          Version:      3.8.0
        Name:           stable-3.8
      Default Channel:  stable-3.8
      Package Name:     quay-operator
    작은 정보

    다음 명령을 실행하여 Operator 버전 및 채널 정보를 YAML 형식으로 출력할 수 있습니다.

    $ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
    • 네임스페이스에 두 개 이상의 카탈로그가 설치된 경우 다음 명령을 실행하여 특정 카탈로그에서 사용 가능한 버전 및 Operator 채널을 조회합니다.

      $ oc get packagemanifest \
         --selector=catalog=<catalogsource_name> \
         --field-selector metadata.name=<operator_name> \
         -n <catalog_namespace> -o yaml
      중요

      Operator 카탈로그를 지정하지 않으면 다음 조건이 충족되는 경우 oc get packagemanifestoc describe packagemanifest 명령을 실행하면 예기치 않은 카탈로그에서 패키지를 반환할 수 있습니다.

      • 여러 카탈로그가 동일한 네임스페이스에 설치됩니다.
      • 카탈로그에는 동일한 이름의 Operator 또는 Operator가 포함됩니다.
  2. OperatorGroup 오브젝트에서 정의하는 Operator group은 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC(역할 기반 액세스 제어) 액세스를 생성하는 대상 네임스페이스를 선택합니다.

    Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces 모드를 사용하는 경우 openshift-operators 네임스페이스에 적절한 Operator group이 이미 있습니다.

    그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

    1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml
  3. startingCSV 필드를 설정하여 특정 버전의 Operator에 네임스페이스를 서브스크립션하는 Subscription 오브젝트 YAML 파일을 생성합니다. 카탈로그에 이후 버전이 있는 경우 Operator가 자동으로 업그레이드되지 않도록 installPlanApproval 필드를 Manual로 설정합니다.

    예를 들어 다음 sub.yaml 파일을 사용하여 특히 버전 3.7.10에 Red Hat Quay Operator를 설치할 수 있습니다.

    특정 시작 Operator 버전이 있는 서브스크립션

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: quay-operator
      namespace: quay
    spec:
      channel: stable-3.7
      installPlanApproval: Manual 1
      name: quay-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: quay-operator.v3.7.10 2

    1
    지정된 버전이 카탈로그의 이후 버전으로 대체될 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.
    2
    Operator CSV의 특정 버전을 설정합니다.
  4. Subscription 오브젝트를 생성합니다.

    $ oc apply -f sub.yaml
  5. 보류 중인 설치 계획을 수동으로 승인하여 Operator 설치를 완료합니다.

4장. 관리자 작업

4.1. 클러스터에 Operator 추가

OLM(Operator Lifecycle Manager)을 사용하여 클러스터 관리자는 OLM 기반 Operator를 OpenShift Container Platform 클러스터에 설치할 수 있습니다.

참고

OLM에서 동일한 네임스페이스에 배치된 설치된 Operator에 대한 업데이트를 처리하는 방법과 사용자 정의 글로벌 Operator 그룹을 사용하여 Operator를 설치하는 대체 방법은 Multitenancy 및 Operator colocation 을 참조하십시오.

4.1.1. OperatorHub를 통한 Operator 설치 정보

OperatorHub는 Operator를 검색하는 사용자 인터페이스입니다. 이는 클러스터에 Operator를 설치하고 관리하는 OLM(Operator Lifecycle Manager)과 함께 작동합니다.

적절한 권한이 있는 사용자는 OpenShift Container Platform 웹 콘솔 또는 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다.

설치하는 동안 Operator의 다음 초기 설정을 결정해야합니다.

설치 모드
Operator를 설치할 특정 네임스페이스를 선택합니다.
업데이트 채널
여러 채널을 통해 Operator를 사용할 수있는 경우 구독할 채널을 선택할 수 있습니다. 예를 들어, stable 채널에서 배치하려면 (사용 가능한 경우) 목록에서 해당 채널을 선택합니다.
승인 전략

자동 또는 수동 업데이트를 선택할 수 있습니다.

설치된 Operator에 대해 자동 업데이트를 선택하는 경우 선택한 채널에 해당 Operator의 새 버전이 제공되면 OLM(Operator Lifecycle Manager)에서 Operator의 실행 중인 인스턴스를 개입 없이 자동으로 업그레이드합니다.

수동 업데이트를 선택하면 최신 버전의 Operator가 사용 가능할 때 OLM이 업데이트 요청을 작성합니다. 클러스터 관리자는 Operator를 새 버전으로 업데이트하려면 OLM 업데이트 요청을 수동으로 승인해야 합니다.

추가 리소스

4.1.2. 웹 콘솔을 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하여 OperatorHub에서 Operator를 설치하고 구독할 수 있습니다.

사전 요구 사항

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

프로세스

  1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.
  2. 원하는 Operator를 찾으려면 키워드를 Filter by keyword 상자에 입력하거나 스크롤합니다. 예를 들어 Kubernetes Operator의 고급 클러스터 관리 기능을 찾으려면 advanced를 입력합니다.

    인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.

  3. Operator를 선택하여 추가 정보를 표시합니다.

    참고

    커뮤니티 Operator를 선택하면 Red Hat이 커뮤니티 Operator를 인증하지 않는다고 경고합니다. 계속하기 전에 경고를 확인해야합니다.

  4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.
  5. Operator 설치 페이지에서 다음을 수행합니다.

    1. 다음 명령 중 하나를 선택합니다.

      • All namespaces on the cluster (default)에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 모니터링하고 사용할 수 있습니다. 이 옵션을 항상 사용할 수있는 것은 아닙니다.
      • A specific namespace on the cluster를 사용하면 Operator를 설치할 특정 단일 네임 스페이스를 선택할 수 있습니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
    2. Operator를 설치할 특정 단일 네임스페이스를 선택합니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
    3. 토큰 인증이 활성화된 클라우드 공급자의 클러스터의 경우:

      • 클러스터가 AWS STS(웹 콘솔에서STS 모드 )를 사용하는 경우 역할 ARN 필드에 서비스 계정의 AWS IAM 역할의 Amazon Resource Name( ARN )을 입력합니다.

        ARN 입력

        역할의 ARN을 생성하려면 AWS 계정 준비에 설명된 절차를 따르십시오.

      • 클러스터에서 Microsoft Entra Workload ID(웹 콘솔에서워크로드 ID / Federated Identity Mode )를 사용하는 경우 적절한 필드에 클라이언트 ID, 테넌트 ID 및 구독 ID를 추가합니다.
    4. 둘 이상의 업데이트 채널을 사용할 수 있는 경우 업데이트 채널을 선택합니다.
    5. 앞에서 설명한 대로 자동 또는 수동 승인 전략을 선택합니다.

      중요

      웹 콘솔에 AWS STS 또는 Microsoft Entra Workload ID를 사용하는 클러스터가 표시되는 경우 업데이트 승인을 Manual 로 설정해야 합니다.

      자동 업데이트 승인이 있는 서브스크립션은 업데이트하기 전에 권한을 변경할 수 있으므로 권장되지 않습니다. 수동 업데이트 승인이 있는 서브스크립션을 통해 관리자는 최신 버전의 권한을 확인하고 업데이트 전에 필요한 단계를 수행할 수 있습니다.

  6. 이 OpenShift Container Platform 클러스터에서 선택한 네임스페이스에서 Operator를 사용할 수 있도록 하려면 설치를 클릭합니다.

    1. 수동 승인 전략을 선택한 경우 설치 계획을 검토하고 승인할 때까지 서브스크립션의 업그레이드 상태가 업그레이드 중으로 유지됩니다.

      Install Plan 페이지에서 승인 한 후 subscription 업그레이드 상태가 Up to date로 이동합니다.

    2. 자동 승인 전략을 선택한 경우 업그레이드 상태가 개입 없이 최신 상태로 확인되어야 합니다.
  7. 서브스크립션의 업그레이드 상태가 최신이면 Operator → 설치된 Operator를 선택하여 설치된 Operator의 CSV(클러스터 서비스 버전)가 최종적으로 표시되는지 확인합니다. 상태는 최종적으로 관련 네임스페이스에서 InstallSucceeded로 확인되어야 합니다.

    참고

    모든 네임스페이스…​ 설치 모드의 경우, openshift-operators 네임스페이스에서 상태가 InstallSucceeded로 확인되지만 다른 네임스페이스에서 확인하면 상태가 복사됨입니다.

    그렇지 않은 경우 다음을 수행합니다.

    1. 워크로드 → Pod 페이지의 openshift-operators 프로젝트(또는 특정 네임스페이스…​설치 모드가 선택된 경우 기타 관련 네임스페이스)에서 문제를 보고하는 모든 Pod의 로그를 확인하여 문제를 추가로 해결합니다.

4.1.3. CLI를 사용하여 OperatorHub에서 설치

OpenShift Container Platform 웹 콘솔을 사용하는 대신 CLI를 사용하여 OperatorHub에서 Operator를 설치할 수 있습니다. oc 명령을 사용하여 Subscription 개체를 만들거나 업데이트합니다.

사전 요구 사항

  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. OperatorHub에서 클러스터에 사용 가능한 Operator의 목록을 표시합니다.

    $ oc get packagemanifests -n openshift-marketplace

    출력 예

    NAME                               CATALOG               AGE
    3scale-operator                    Red Hat Operators     91m
    advanced-cluster-management        Red Hat Operators     91m
    amq7-cert-manager                  Red Hat Operators     91m
    ...
    couchbase-enterprise-certified     Certified Operators   91m
    crunchy-postgres-operator          Certified Operators   91m
    mongodb-enterprise                 Certified Operators   91m
    ...
    etcd                               Community Operators   91m
    jaeger                             Community Operators   91m
    kubefed                            Community Operators   91m
    ...

    필요한 Operator의 카탈로그를 기록해 둡니다.

  2. 필요한 Operator를 검사하여 지원되는 설치 모드 및 사용 가능한 채널을 확인합니다.

    $ oc describe packagemanifests <operator_name> -n openshift-marketplace
  3. OperatorGroup 오브젝트로 정의되는 Operator group에서 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

    Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces 모드를 사용하는 경우 openshift-operators 네임스페이스에 적절한 global-operators Operator group이 이미 있습니다.

    그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

    참고
    • 이 프로세스의 웹 콘솔 버전에서는 SingleNamespace 모드를 선택할 때 자동으로 OperatorGroupSubscription 개체 생성을 자동으로 처리합니다.
    • 네임스페이스당 하나의 Operator 그룹만 있을 수 있습니다. 자세한 내용은 "Operator groups"을 참조하십시오.
    1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml
  4. Subscription 개체 YAML 파일을 생성하여 OpenShift Pipelines Operator에 네임스페이스를 등록합니다(예: sub.yaml).

    Subscription 개체 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: <subscription_name>
      namespace: openshift-operators 1
    spec:
      channel: <channel_name> 2
      name: <operator_name> 3
      source: redhat-operators 4
      sourceNamespace: openshift-marketplace 5
      config:
        env: 6
        - name: ARGS
          value: "-v=10"
        envFrom: 7
        - secretRef:
            name: license-secret
        volumes: 8
        - name: <volume_name>
          configMap:
            name: <configmap_name>
        volumeMounts: 9
        - mountPath: <directory_name>
          name: <volume_name>
        tolerations: 10
        - operator: "Exists"
        resources: 11
          requests:
            memory: "64Mi"
            cpu: "250m"
          limits:
            memory: "128Mi"
            cpu: "500m"
        nodeSelector: 12
          foo: bar

    1
    기본 AllNamespaces 설치 모드 사용량의 경우 openshift-operators 네임스페이스를 지정합니다. 또는 사용자 지정 글로벌 네임스페이스를 생성한 경우 지정할 수 있습니다. 그 외에는 SingleNamespace 설치 모드를 사용하도록 관련 단일 네임스페이스를 지정합니다.
    2
    등록할 채널의 이름입니다.
    3
    등록할 Operator의 이름입니다.
    4
    Operator를 제공하는 카탈로그 소스의 이름입니다.
    5
    카탈로그 소스의 네임스페이스입니다. 기본 OperatorHub 카탈로그 소스에는 openshift-marketplace를 사용합니다.
    6
    env 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 있어야 하는 환경 변수 목록을 정의합니다.
    7
    envFrom 매개 변수는 컨테이너에서 환경 변수를 채울 소스 목록을 정의합니다.
    8
    volumes 매개변수는 OLM에서 생성한 Pod에 있어야 하는 볼륨 목록을 정의합니다.
    9
    volumeMounts 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 있어야 하는 볼륨 마운트 목록을 정의합니다. volume Mount 가 존재하지 않는 볼륨을 참조하는 경우 OLM에서 Operator를 배포하지 못합니다.
    10
    tolerations 매개변수는 OLM에서 생성한 Pod의 허용 목록을 정의합니다.
    11
    resources 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.
    12
    nodeSelector 매개변수는 OLM에서 생성한 Pod에 대한 NodeSelector 를 정의합니다.
  5. 토큰 인증이 활성화된 클라우드 공급자의 클러스터의 경우:

    1. Subscription 오브젝트가 수동 업데이트 승인으로 설정되어 있는지 확인합니다.

      kind: Subscription
      # ...
      spec:
        installPlanApproval: Manual 1
      1
      자동 업데이트 승인이 있는 서브스크립션은 업데이트하기 전에 권한을 변경할 수 있으므로 권장되지 않습니다. 수동 업데이트 승인이 있는 서브스크립션을 통해 관리자는 최신 버전의 권한을 확인하고 업데이트 전에 필요한 단계를 수행할 수 있습니다.
    2. Subscription 오브젝트의 config 섹션에 관련 클라우드 공급자별 필드를 포함합니다.

      • 클러스터가 AWS STS 모드에 있는 경우 다음 필드를 포함합니다.

        kind: Subscription
        # ...
        spec:
          config:
            env:
            - name: ROLEARN
              value: "<role_arn>" 1
        1
        역할 ARN 세부 정보를 포함합니다.
      • 클러스터가 Microsoft Entra Workload ID 모드에 있는 경우 다음 필드를 포함합니다.

        kind: Subscription
        # ...
        spec:
         config:
           env:
           - name: CLIENTID
             value: "<client_id>" 1
           - name: TENANTID
             value: "<tenant_id>" 2
           - name: SUBSCRIPTIONID
             value: "<subscription_id>" 3
        1
        클라이언트 ID를 포함합니다.
        2
        테넌트 ID를 포함합니다.
        3
        서브스크립션 ID를 포함합니다.
  6. Subscription 오브젝트를 생성합니다.

    $ oc apply -f sub.yaml

    이 시점에서 OLM은 이제 선택한 Operator를 인식합니다. Operator의 CSV(클러스터 서비스 버전)가 대상 네임스페이스에 표시되고 Operator에서 제공하는 API를 생성에 사용할 수 있어야 합니다.

추가 리소스

4.1.4. 특정 버전의 Operator 설치

Subscription 오브젝트에 CSV(클러스터 서비스 버전)를 설정하면 특정 버전의 Operator를 설치할 수 있습니다.

사전 요구 사항

  • Operator 설치 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 다음 명령을 실행하여 설치할 Operator의 사용 가능한 버전 및 채널을 찾습니다.

    명령 구문

    $ oc describe packagemanifests <operator_name> -n <catalog_namespace>

    예를 들어 다음 명령은 OperatorHub에서 사용 가능한 채널 및 버전의 Red Hat Quay Operator를 출력합니다.

    명령 예

    $ oc describe packagemanifests quay-operator -n openshift-marketplace

    예 4.1. 출력 예

    Name:         quay-operator
    Namespace:    operator-marketplace
    Labels:       catalog=redhat-operators
                  catalog-namespace=openshift-marketplace
                  hypershift.openshift.io/managed=true
                  operatorframework.io/arch.amd64=supported
                  operatorframework.io/os.linux=supported
                  provider=Red Hat
                  provider-url=
    Annotations:  <none>
    API Version:  packages.operators.coreos.com/v1
    Kind:         PackageManifest
    ...
        Current CSV:  quay-operator.v3.7.11
    ...
        Entries:
          Name:       quay-operator.v3.7.11
          Version:    3.7.11
          Name:       quay-operator.v3.7.10
          Version:    3.7.10
          Name:       quay-operator.v3.7.9
          Version:    3.7.9
          Name:       quay-operator.v3.7.8
          Version:    3.7.8
          Name:       quay-operator.v3.7.7
          Version:    3.7.7
          Name:       quay-operator.v3.7.6
          Version:    3.7.6
          Name:       quay-operator.v3.7.5
          Version:    3.7.5
          Name:       quay-operator.v3.7.4
          Version:    3.7.4
          Name:       quay-operator.v3.7.3
          Version:    3.7.3
          Name:       quay-operator.v3.7.2
          Version:    3.7.2
          Name:       quay-operator.v3.7.1
          Version:    3.7.1
          Name:       quay-operator.v3.7.0
          Version:    3.7.0
        Name:         stable-3.7
    ...
       Current CSV:  quay-operator.v3.8.5
    ...
       Entries:
          Name:         quay-operator.v3.8.5
          Version:      3.8.5
          Name:         quay-operator.v3.8.4
          Version:      3.8.4
          Name:         quay-operator.v3.8.3
          Version:      3.8.3
          Name:         quay-operator.v3.8.2
          Version:      3.8.2
          Name:         quay-operator.v3.8.1
          Version:      3.8.1
          Name:         quay-operator.v3.8.0
          Version:      3.8.0
        Name:           stable-3.8
      Default Channel:  stable-3.8
      Package Name:     quay-operator
    작은 정보

    다음 명령을 실행하여 Operator 버전 및 채널 정보를 YAML 형식으로 출력할 수 있습니다.

    $ oc get packagemanifests <operator_name> -n <catalog_namespace> -o yaml
    • 네임스페이스에 두 개 이상의 카탈로그가 설치된 경우 다음 명령을 실행하여 특정 카탈로그에서 사용 가능한 버전 및 Operator 채널을 조회합니다.

      $ oc get packagemanifest \
         --selector=catalog=<catalogsource_name> \
         --field-selector metadata.name=<operator_name> \
         -n <catalog_namespace> -o yaml
      중요

      Operator 카탈로그를 지정하지 않으면 다음 조건이 충족되는 경우 oc get packagemanifestoc describe packagemanifest 명령을 실행하면 예기치 않은 카탈로그에서 패키지를 반환할 수 있습니다.

      • 여러 카탈로그가 동일한 네임스페이스에 설치됩니다.
      • 카탈로그에는 동일한 이름의 Operator 또는 Operator가 포함됩니다.
  2. OperatorGroup 오브젝트에서 정의하는 Operator group은 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC(역할 기반 액세스 제어) 액세스를 생성하는 대상 네임스페이스를 선택합니다.

    Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces 모드를 사용하는 경우 openshift-operators 네임스페이스에 적절한 Operator group이 이미 있습니다.

    그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

    1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

    2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml
  3. startingCSV 필드를 설정하여 특정 버전의 Operator에 네임스페이스를 서브스크립션하는 Subscription 오브젝트 YAML 파일을 생성합니다. 카탈로그에 이후 버전이 있는 경우 Operator가 자동으로 업그레이드되지 않도록 installPlanApproval 필드를 Manual로 설정합니다.

    예를 들어 다음 sub.yaml 파일을 사용하여 특히 버전 3.7.10에 Red Hat Quay Operator를 설치할 수 있습니다.

    특정 시작 Operator 버전이 있는 서브스크립션

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: quay-operator
      namespace: quay
    spec:
      channel: stable-3.7
      installPlanApproval: Manual 1
      name: quay-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: quay-operator.v3.7.10 2

    1
    지정된 버전이 카탈로그의 이후 버전으로 대체될 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.
    2
    Operator CSV의 특정 버전을 설정합니다.
  4. Subscription 오브젝트를 생성합니다.

    $ oc apply -f sub.yaml
  5. 보류 중인 설치 계획을 수동으로 승인하여 Operator 설치를 완료합니다.

4.1.5. 웹 콘솔에서 특정 버전의 Operator 설치

웹 콘솔에서 OperatorHub를 사용하여 특정 버전의 Operator를 설치할 수 있습니다. 보유할 수 있는 모든 채널에서 다양한 버전의 Operator를 검색하고 해당 채널 및 버전의 메타데이터를 보고 설치할 정확한 버전을 선택할 수 있습니다.

사전 요구 사항

  • 클러스터 관리자 권한이 있어야합니다.

프로세스

  1. 웹 콘솔에서 OperatorOperatorHub 를 클릭합니다.
  2. 설치할 Operator를 선택합니다.
  3. 선택한 Operator의 목록에서 채널 및 버전을 선택할 수 있습니다.

    참고

    버전 선택 기본값은 선택한 채널의 최신 버전입니다. 채널의 최신 버전이 선택되어 있으면 기본적으로 자동 승인 전략이 활성화됩니다. 그렇지 않으면 선택한 채널의 최신 버전을 설치하지 않는 경우 수동 승인이 필요합니다.

    수동 승인은 네임스페이스에 설치된 모든 Operator에 적용됩니다.

    수동 승인을 사용하여 Operator를 설치하면 네임스페이스 내에 설치된 모든 Operator가 수동 승인 전략과 함께 작동하고 모든 Operator가 함께 업데이트됩니다. 독립적으로 업데이트하기 위해 별도의 네임스페이스에 Operator를 설치합니다.

  4. 설치를 클릭합니다.

검증

  • Operator가 설치되면 메타데이터는 설치된 채널 및 버전을 나타냅니다.

    참고

    이 카탈로그 컨텍스트에서 채널 및 버전 드롭다운 메뉴를 사용하여 다른 버전 메타데이터를 볼 수 있습니다.

4.1.6. 다중 테넌트 클러스터를 위한 Operator의 여러 인스턴스 준비

클러스터 관리자는 다중 테넌트 클러스터에서 사용할 Operator의 여러 인스턴스를 추가할 수 있습니다. 이는 최소 권한의 원칙을 위반하는 것으로 간주될 수 있는 표준 All namespaces 설치 모드 또는 널리 채택되지 않은 Multinamespace 모드의 대체 솔루션입니다. 자세한 내용은 "테넌트 클러스터의 Operator"를 참조하십시오.

다음 절차에서는 배포된 워크로드 집합에 대한 공통 액세스 및 권한을 공유하는 사용자 또는 사용자 그룹입니다. 테넌트 Operator 는 해당 테넌트에서만 사용할 수 있는 Operator의 인스턴스입니다.

사전 요구 사항

  • 설치하려는 Operator의 모든 인스턴스가 지정된 클러스터에서 동일한 버전이어야 합니다.

    중요

    이 제한 및 기타 제한 사항에 대한 자세한 내용은 "테넌트 클러스터의 Operator"를 참조하십시오.

프로세스

  1. Operator를 설치하기 전에 테넌트의 네임스페이스와 별도의 테넌트 Operator의 네임스페이스를 생성합니다. 예를 들어 테넌트의 네임스페이스가 team1 인 경우 team1-operator 네임스페이스를 생성할 수 있습니다.

    1. 네임스페이스 리소스를 정의하고 YAML 파일을 저장합니다(예: team1-operator.yaml ):

      apiVersion: v1
      kind: Namespace
      metadata:
        name: team1-operator
    2. 다음 명령을 실행하여 네임스페이스를 생성합니다.

      $ oc create -f team1-operator.yaml
  2. spec.targetNamespaces 목록에 하나의 네임스페이스 항목만 사용하여 테넌트의 네임스페이스에 범위가 지정된 Operator group을 생성합니다.

    1. OperatorGroup 리소스를 정의하고 YAML 파일을 저장합니다(예: team1-operatorgroup.yaml ):

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: team1-operatorgroup
        namespace: team1-operator
      spec:
        targetNamespaces:
        - team1 1
      1
      spec.targetNamespaces 목록에 테넌트의 네임스페이스만 정의합니다.
    2. 다음 명령을 실행하여 Operator group을 생성합니다.

      $ oc create -f team1-operatorgroup.yaml

다음 단계

  • 테넌트 Operator 네임스페이스에 Operator를 설치합니다. 이 작업은 CLI 대신 웹 콘솔에서 OperatorHub를 사용하여 더 쉽게 수행합니다. 자세한 절차는 웹 콘솔을 사용하여 OperatorHub에서 설치를 참조하십시오.

    참고

    Operator 설치를 완료한 후 Operator는 테넌트 Operator 네임스페이스에 상주하며 테넌트 네임스페이스를 감시하지만 Operator의 Pod 및 서비스 계정은 테넌트에서 보거나 사용할 수 없습니다.

4.1.7. 사용자 정의 네임스페이스에 글로벌 Operator 설치

OpenShift Container Platform 웹 콘솔을 사용하여 Operator를 설치할 때 기본 동작은 All namespaces 설치 모드를 지원하는 Operator를 기본 openshift-operators 글로벌 네임스페이스에 설치합니다. 이로 인해 공유 설치 계획과 관련된 문제가 발생하고 네임스페이스의 모든 Operator 간에 정책을 업데이트할 수 있습니다. 이러한 제한 사항에 대한 자세한 내용은 "Multitenancy and Operator colocation"을 참조하십시오.

클러스터 관리자는 사용자 정의 글로벌 네임스페이스를 생성하고 해당 네임스페이스를 사용하여 개별 또는 범위가 지정된 Operator 및 해당 종속 항목을 설치하여 이 기본 동작을 수동으로 바이패스할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. Operator를 설치하기 전에 원하는 Operator를 설치할 네임스페이스를 생성합니다. 이 설치 네임스페이스는 사용자 정의 글로벌 네임스페이스가 됩니다.

    1. 네임스페이스 리소스를 정의하고 YAML 파일(예: global-operators.yaml )을 저장합니다.

      apiVersion: v1
      kind: Namespace
      metadata:
        name: global-operators
    2. 다음 명령을 실행하여 네임스페이스를 생성합니다.

      $ oc create -f global-operators.yaml
  2. 모든 네임스페이스를 감시하는 Operator group인 사용자 정의 글로벌 Operator group을 생성합니다.

    1. OperatorGroup 리소스를 정의하고 YAML 파일(예: global-operatorgroup.yaml )을 저장합니다. spec.selectorspec.targetNamespaces 필드를 모두 생략하여 모든 네임스페이스를 선택하는 글로벌 Operator group 으로 설정합니다.

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: global-operatorgroup
        namespace: global-operators
      참고

      생성된 글로벌 Operator group의 status.namespaces 에는 사용 중인 Operator에 모든 네임스페이스를 조사해야 한다는 신호를 보내는 빈 문자열("")이 포함되어 있습니다.

    2. 다음 명령을 실행하여 Operator group을 생성합니다.

      $ oc create -f global-operatorgroup.yaml

다음 단계

  • 사용자 정의 글로벌 네임스페이스에 원하는 Operator를 설치합니다. Operator 설치 중에 웹 콘솔은 사용자 정의 글로벌 네임스페이스로 설치된 네임스페이스 메뉴를 채우지 않으므로 이 작업은 OpenShift CLI(oc)로만 수행할 수 있습니다. 자세한 절차는 CLI를 사용하여 OperatorHub에서 설치를 참조하십시오.

    참고

    Operator 설치를 시작할 때 Operator에 종속 항목이 있는 경우 사용자 정의 글로벌 네임스페이스에 종속성도 자동으로 설치됩니다. 결과적으로 종속성 Operator에 동일한 업데이트 정책 및 공유 설치 계획이 있는 것이 유효합니다.

4.1.8. Operator 워크로드의 Pod 배치

기본적으로 OLM(Operator Lifecycle Manager)은 Operator를 설치하거나 Operand 워크로드를 배포할 때 임의의 작업자 노드에 Pod를 배치합니다. 관리자는 노드 선택기, 테인트 및 허용 오차가 결합된 프로젝트를 사용하여 특정 노드에 Operator 및 Operand 배치를 제어할 수 있습니다.

Operator 및 Operand 워크로드의 Pod 배치 제어에는 다음과 같은 사전 요구 사항이 있습니다.

  1. 요구 사항에 따라 Pod를 대상으로 할 노드 또는 노드 집합을 결정합니다. 사용 가능한 경우 노드 또는 노드를 식별하는 node-role.kubernetes.io/app과 같은 기존 레이블을 확인합니다. 그렇지 않으면 컴퓨팅 머신 세트를 사용하거나 노드를 직접 편집하여 myoperator 와 같은 레이블을 추가합니다. 이후 단계에서 이 레이블을 프로젝트의 노드 선택기로 사용합니다.
  2. 특정 레이블이 있는 Pod만 노드에서 실행되도록 허용하지만 관련이 없는 워크로드를 다른 노드에 추가하려면 컴퓨팅 머신 세트를 사용하거나 노드를 직접 편집하여 노드 또는 노드에 테인트를 추가합니다. 테인트와 일치하지 않는 새 Pod를 노드에서 예약할 수 없도록 하는 효과를 사용합니다. 예를 들어 myoperator:NoSchedule 테인트를 사용하면 테인트와 일치하지 않는 새 Pod가 해당 노드에 예약되지 않지만 노드의 기존 Pod는 그대로 유지됩니다.
  3. 기본 노드 선택기와 테인트를 추가한 경우 일치하는 허용 오차로 구성된 프로젝트를 만듭니다.

이 시점에서 생성한 프로젝트를 사용하여 다음 시나리오에서 지정된 노드로 Pod를 이동할 수 있습니다.

Operator Pod의 경우
관리자는 다음 섹션에 설명된 대로 프로젝트에서 Subscription 오브젝트를 생성할 수 있습니다. 결과적으로 Operator Pod가 지정된 노드에 배치됩니다.
Operand Pod의 경우
설치된 Operator를 사용하여 프로젝트에 애플리케이션을 생성할 수 있습니다. 그러면 Operator가 프로젝트에 소유한 CR(사용자 정의 리소스)이 배치됩니다. 결과적으로 Operator가 다른 네임스페이스에 클러스터 수준 오브젝트 또는 리소스를 배포하지 않는 한 피연산자 Pod가 지정된 노드에 배치됩니다. 이 경우 사용자 정의 Pod 배치가 적용되지 않습니다.

4.1.9. Operator가 설치된 위치 제어

기본적으로 Operator를 설치할 때 OpenShift Container Platform은 Operator Pod를 임의로 작업자 노드 중 하나에 설치합니다. 그러나 특정 노드 또는 노드 세트에 해당 Pod를 예약하려는 경우가 있을 수 있습니다.

다음 예제에서는 Operator Pod를 특정 노드 또는 노드 세트에 예약해야 하는 상황을 설명합니다.

  • Operator에 amd64 또는 arm64와 같은 특정 플랫폼이 필요한 경우
  • Operator에 Linux 또는 Windows와 같은 특정 운영 체제가 필요한 경우
  • 동일한 호스트에서 또는 동일한 랙에 있는 호스트에서 예약된 Operator를 원하는 경우
  • 네트워크 또는 하드웨어 문제로 인해 다운타임을 방지하기 위해 인프라 전체에 Operator를 분산하려는 경우

Operator의 Subscription 오브젝트에 노드 유사성, Pod 유사성 또는 Pod 유사성 방지 제약 조건을 추가하여 Operator Pod가 설치된 위치를 제어할 수 있습니다. 노드 유사성은 스케줄러에서 Pod를 배치할 수 있는 위치를 결정하는 데 사용하는 규칙 세트입니다. Pod 유사성을 사용하면 관련 Pod가 동일한 노드에 예약되도록 할 수 있습니다. Pod 유사성 방지를 사용하면 노드에서 Pod가 예약되지 않도록 할 수 있습니다.

다음 예제에서는 노드 유사성 또는 Pod 유사성 방지를 사용하여 클러스터의 특정 노드에 Custom Metrics Autoscaler Operator 인스턴스를 설치하는 방법을 보여줍니다.

Operator Pod를 특정 노드에 배치하는 노드 유사성 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - ip-10-0-163-94.us-west-2.compute.internal
#...

1
ip-10-0-163-94.us-west-2.compute.internal 이라는 노드에 Operator의 Pod를 예약해야 하는 노드 유사성입니다.

특정 플랫폼이 있는 노드에 Operator Pod를 배치하는 노드 유사성 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      nodeAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/arch
              operator: In
              values:
              - arm64
            - key: kubernetes.io/os
              operator: In
              values:
              - linux
#...

1
kubernetes.io/arch=arm64kubernetes.io/os=linux 라벨이 있는 노드에 Operator의 Pod를 예약해야 하는 노드 유사성입니다.

Operator Pod를 하나 이상의 특정 노드에 배치하는 Pod 유사성 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: app
              operator: In
              values:
              - test
          topologyKey: kubernetes.io/hostname
#...

1
app=test 레이블이 있는 Pod가 있는 노드에 Operator의 Pod를 배치하는 Pod 유사성입니다.

Operator Pod가 하나 이상의 특정 노드에서 발생하지 않도록 하는 Pod 유사성 방지 예

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-custom-metrics-autoscaler-operator
  namespace: openshift-keda
spec:
  name: my-package
  source: my-operators
  sourceNamespace: operator-registries
  config:
    affinity:
      podAntiAffinity: 1
        requiredDuringSchedulingIgnoredDuringExecution:
        - labelSelector:
            matchExpressions:
            - key: cpu
              operator: In
              values:
              - high
          topologyKey: kubernetes.io/hostname
#...

1
cpu=high 라벨이 있는 Pod가 있는 노드에서 Operator의 Pod를 예약하지 않도록 하는 Pod 유사성 방지입니다.

프로세스

Operator Pod 배치를 제어하려면 다음 단계를 완료합니다.

  1. Operator를 정상적으로 설치합니다.
  2. 필요한 경우 선호도에 올바르게 응답하도록 노드에 레이블이 지정되어 있는지 확인합니다.
  3. Operator Subscription 오브젝트를 편집하여 선호도를 추가합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: openshift-custom-metrics-autoscaler-operator
      namespace: openshift-keda
    spec:
      name: my-package
      source: my-operators
      sourceNamespace: operator-registries
      config:
        affinity: 1
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/hostname
                  operator: In
                  values:
                  - ip-10-0-185-229.ec2.internal
    #...
    1
    nodeAffinity,podAffinity 또는 podAntiAffinity 를 추가합니다. 선호도 생성에 대한 정보는 다음 추가 리소스 섹션을 참조하십시오.

검증

  • Pod가 특정 노드에 배포되도록 하려면 다음 명령을 실행합니다.

    $ oc get pods -o wide

    출력 예

    NAME                                                  READY   STATUS    RESTARTS   AGE   IP            NODE                           NOMINATED NODE   READINESS GATES
    custom-metrics-autoscaler-operator-5dcc45d656-bhshg   1/1     Running   0          50s   10.131.0.20   ip-10-0-185-229.ec2.internal   <none>           <none>

4.2. 설치된 Operator 업데이트

클러스터 관리자는 OpenShift Container Platform 클러스터에서 OLM(Operator Lifecycle Manager)을 사용하여 이전에 설치한 Operator를 업데이트할 수 있습니다.

참고

OLM에서 동일한 네임스페이스에 배치된 설치된 Operator에 대한 업데이트를 처리하는 방법과 사용자 정의 글로벌 Operator 그룹을 사용하여 Operator를 설치하는 대체 방법은 Multitenancy 및 Operator colocation 을 참조하십시오.

4.2.1. Operator 업데이트 준비

설치된 Operator의 서브스크립션은 Operator를 추적하고 업데이트를 수신하는 업데이트 채널을 지정합니다. 업데이트 채널을 변경하여 추적을 시작하고 최신 채널에서 업데이트를 수신할 수 있습니다.

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

참고

설치된 Operator는 현재 채널보다 오래된 채널로 변경할 수 없습니다.

Red Hat Customer Portal 랩에는 관리자가 Operator 업데이트를 준비하는 데 도움이 되는 다음 애플리케이션이 포함되어 있습니다.

애플리케이션을 사용하여 Operator Lifecycle Manager 기반 Operator를 검색하고 다양한 OpenShift Container Platform 버전에서 업데이트 채널별로 사용 가능한 Operator 버전을 확인할 수 있습니다. Cluster Version Operator 기반 Operator는 포함되어 있지 않습니다.

4.2.2. Operator의 업데이트 채널 변경

OpenShift Container Platform 웹 콘솔을 사용하여 Operator의 업데이트 채널을 변경할 수 있습니다.

작은 정보

서브스크립션의 승인 전략이 자동으로 설정된 경우 선택한 채널에서 새 Operator 버전을 사용할 수 있는 즉시 업데이트 프로세스가 시작됩니다. 승인 전략이 수동으로 설정된 경우 보류 중인 업데이트를 수동으로 승인해야 합니다.

사전 요구 사항

  • OLM(Operator Lifecycle Manager)을 사용하여 이전에 설치한 Operator입니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 Operator → Installed Operators로 이동합니다.
  2. 업데이트 채널을 변경할 Operator 이름을 클릭합니다.
  3. 서브스크립션 탭을 클릭합니다.
  4. 업데이트 채널 아래에서 업데이트 채널 의 이름을 클릭합니다.
  5. 변경할 최신 업데이트 채널을 클릭한 다음 저장을 클릭합니다.
  6. 자동 승인 전략이 있는 서브스크립션의 경우 업데이트가 자동으로 시작됩니다. Operator → 설치된 Operator 페이지로 이동하여 업데이트 진행 상황을 모니터링합니다. 완료되면 상태가 성공최신으로 변경됩니다.

    수동 승인 전략이 있는 서브스크립션의 경우 서브스크립션 탭에서 업데이트를 수동으로 승인할 수 있습니다.

4.2.3. 보류 중인 Operator 업데이트 수동 승인

설치된 Operator의 서브스크립션에 있는 승인 전략이 수동으로 설정된 경우 새 업데이트가 현재 업데이트 채널에 릴리스될 때 업데이트를 수동으로 승인해야 설치가 시작됩니다.

사전 요구 사항

  • OLM(Operator Lifecycle Manager)을 사용하여 이전에 설치한 Operator입니다.

절차

  1. OpenShift Container Platform 웹 콘솔의 관리자 관점에서 Operator → 설치된 Operator로 이동합니다.
  2. 보류 중인 업데이트가 있는 Operator에 업그레이드 사용 가능 상태가 표시됩니다. 업데이트할 Operator 이름을 클릭합니다.
  3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업데이트는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
  4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
  5. 업데이트에 사용 가능한 것으로 나열된 리소스를 검토합니다. 문제가 없는 경우 승인을 클릭합니다.
  6. Operator → 설치된 Operator 페이지로 이동하여 업데이트 진행 상황을 모니터링합니다. 완료되면 상태가 성공최신으로 변경됩니다.

4.2.4. 추가 리소스

4.3. 클러스터에서 Operator 삭제

다음은 OpenShift Container Platform 클러스터에서 OLM(Operator Lifecycle Manager)을 사용하여 이전에 설치한 Operator를 삭제하거나 제거하는 방법을 설명합니다.

중요

동일한 Operator를 다시 설치하기 전에 Operator를 성공적으로 제거하고 완전히 제거해야 합니다. Operator를 완전히 설치 해제하지 않으면 프로젝트 또는 네임스페이스와 같은 리소스를 "Terminating" 상태가 되고 Operator를 다시 설치하려고 할 때 "error resolving resource" 메시지가 확인될 수 있습니다.

자세한 내용은 제거 실패 후 Operator 다시 설치를 참조하십시오.

4.3.1. 웹 콘솔을 사용하여 클러스터에서 Operator 삭제

클러스터 관리자는 웹 콘솔을 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.

사전 요구 사항

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

프로세스

  1. Operator설치된 Operator 페이지로 이동합니다.
  2. 제거하려는 Operator를 찾으려면 이름으로 필터링 필드에 키워드를 스크롤하거나 입력합니다. 그런 다음 해당 Operator를 클릭합니다.
  3. Operator 세부 정보 페이지 오른쪽에 있는 작업 목록에서 Operator 제거를 선택합니다.

    Operator를 설치 제거하시겠습니까? 대화 상자가 표시됩니다.

  4. 설치 제거를 선택하여 Operator, Operator 배포 및 Pod를 제거합니다. 이 작업 후에 Operator는 실행을 중지하고 더 이상 업데이트가 수신되지 않습니다.

    참고

    이 작업은 CRD(사용자 정의 리소스 정의) 및 CR(사용자 정의 리소스)을 포함하여 Operator에서 관리하는 리소스를 제거하지 않습니다. 웹 콘솔에서 활성화된 대시보드 및 탐색 항목과 계속 실행되는 클러스터 외부 리소스는 수동 정리가 필요할 수 있습니다. Operator를 설치 제거한 후 해당 항목을 제거하려면 Operator CRD를 수동으로 삭제해야 할 수 있습니다.

4.3.2. CLI를 사용하여 클러스터에서 Operator 삭제

클러스터 관리자는 CLI를 사용하여 선택한 네임스페이스에서 설치된 Operator를 삭제할 수 있습니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)가 워크스테이션에 설치되어 있습니다.

프로세스

  1. 구독된 Operator의 최신 버전(예: 서버리스-operator)이 currentCSV 필드에서 식별되는지 확인합니다.

    $ oc get subscription.operators.coreos.com serverless-operator -n openshift-serverless -o yaml | grep currentCSV

    출력 예

      currentCSV: serverless-operator.v1.28.0

  2. 서브스크립션을 삭제합니다(예: 서버리스-operator).

    $ oc delete subscription.operators.coreos.com serverless-operator -n openshift-serverless

    출력 예

    subscription.operators.coreos.com "serverless-operator" deleted

  3. 이전 단계의 currentCSV 값을 사용하여 대상 네임스페이스에서 Operator의 CSV를 삭제합니다.

    $ oc delete clusterserviceversion serverless-operator.v1.28.0 -n openshift-serverless

    출력 예

    clusterserviceversion.operators.coreos.com "serverless-operator.v1.28.0" deleted

4.3.3. 실패한 서브스크립션 새로 고침

OLM(Operator Lifecycle Manager)에서는 네트워크상에서 액세스할 수 없는 이미지를 참조하는 Operator를 구독하는 경우 openshift-marketplace 네임스페이스에 다음 오류로 인해 실패하는 작업을 확인할 수 있습니다.

출력 예

ImagePullBackOff for
Back-off pulling image "example.com/openshift4/ose-elasticsearch-operator-bundle@sha256:6d2587129c846ec28d384540322b40b05833e7e00b25cca584e004af9a1d292e"

출력 예

rpc error: code = Unknown desc = error pinging docker registry example.com: Get "https://example.com/v2/": dial tcp: lookup example.com on 10.0.0.1:53: no such host

결과적으로 서브스크립션이 이러한 장애 상태에 고착되어 Operator를 설치하거나 업그레이드할 수 없습니다.

서브스크립션, CSV(클러스터 서비스 버전) 및 기타 관련 오브젝트를 삭제하여 실패한 서브스크립션을 새로 고칠 수 있습니다. 서브스크립션을 다시 생성하면 OLM에서 올바른 버전의 Operator를 다시 설치합니다.

사전 요구 사항

  • 액세스할 수 없는 번들 이미지를 가져올 수 없는 실패한 서브스크립션이 있습니다.
  • 올바른 번들 이미지에 액세스할 수 있는지 확인했습니다.

프로세스

  1. Operator가 설치된 네임스페이스에서 SubscriptionClusterServiceVersion 오브젝트의 이름을 가져옵니다.

    $ oc get sub,csv -n <namespace>

    출력 예

    NAME                                                       PACKAGE                  SOURCE             CHANNEL
    subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
    
    NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
    clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

  2. 서브스크립션을 삭제합니다.

    $ oc delete subscription <subscription_name> -n <namespace>
  3. 클러스터 서비스 버전을 삭제합니다.

    $ oc delete csv <csv_name> -n <namespace>
  4. openshift-marketplace 네임스페이스에서 실패한 모든 작업 및 관련 구성 맵의 이름을 가져옵니다.

    $ oc get job,configmap -n openshift-marketplace

    출력 예

    NAME                                                                        COMPLETIONS   DURATION   AGE
    job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
    
    NAME                                                                        DATA   AGE
    configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

  5. 작업을 삭제합니다.

    $ oc delete job <job_name> -n openshift-marketplace

    이렇게 하면 액세스할 수 없는 이미지를 가져오려는 Pod가 다시 생성되지 않습니다.

  6. 구성 맵을 삭제합니다.

    $ oc delete configmap <configmap_name> -n openshift-marketplace
  7. 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.

검증

  • Operator가 제대로 다시 설치되었는지 확인합니다.

    $ oc get sub,csv,installplan -n <namespace>

4.4. Operator Lifecycle Manager 기능 구성

OLM(Operator Lifecycle Manager) 컨트롤러는 cluster 라는 OLMConfig CR(사용자 정의 리소스)에 의해 구성됩니다. 클러스터 관리자는 이 리소스를 수정하여 특정 기능을 활성화하거나 비활성화할 수 있습니다.

이 문서에서는 OLMConfig 리소스에서 구성한 OLM에서 현재 지원하는 기능에 대해 간단히 설명합니다.

4.4.1. 복사된 CSV 비활성화

OLM(Operator Lifecycle Manager)에서 Operator를 설치하면 Operator가 조사하도록 구성된 모든 네임스페이스에서 기본적으로 CSV(클러스터 서비스 버전)의 단순화된 사본이 생성됩니다. 이러한 CSV는 복사된 CSV 라고 하며 지정된 네임스페이스에서 컨트롤러가 리소스 이벤트를 적극적으로 조정하는 사용자와 통신합니다.

Operator가 AllNamespaces 설치 모드를 사용하도록 구성된 경우 단일 또는 지정된 네임스페이스 집합을 대상으로 하는 대신 클러스터의 모든 네임스페이스에서 Operator의 복사본 CSV가 생성됩니다. 특히 대규모 클러스터에서는 수백 또는 수천 개의 복사된 Operator가 있는 대규모 클러스터에서는 OLM의 메모리 사용량, 클러스터 etcd 제한 및 네트워킹과 같은 리소스가 사용되지 않을 수 있습니다.

클러스터 관리자는 이러한 대규모 클러스터를 지원하기 위해 AllNamespaces 모드를 사용하여 전역적으로 설치된 Operator에 대해 복사된 CSV를 비활성화할 수 있습니다.

참고

복사된 CSV를 비활성화하면 AllNamespaces 모드에 설치된 Operator의 CSV가 클러스터의 모든 네임스페이스가 아니라 openshift 네임스페이스에만 복사됩니다. 비활성화된 CSV 모드에서 동작은 웹 콘솔과 CLI 간에 다릅니다.

  • 웹 콘솔에서 CSV가 실제로 모든 네임스페이스에 복사되지 않더라도 모든 네임스페이스의 openshift 네임스페이스에서 복사된 CSV가 표시되도록 기본 동작이 수정되었습니다. 이를 통해 일반 사용자는 여전히 네임스페이스에서 이러한 Operator의 세부 정보를 보고 관련 CR(사용자 정의 리소스)을 생성할 수 있습니다.
  • OpenShift CLI(oc)에서 일반 사용자는 oc get csvs 명령을 사용하여 네임스페이스에 직접 설치된 Operator를 볼 수 있지만 openshift 네임스페이스에서 복사한 CSV는 네임스페이스에 표시되지 않습니다. 이 제한에 영향을 받는 Operator를 계속 사용할 수 있으며 사용자 네임스페이스에서 이벤트를 계속 조정할 수 있습니다.

    웹 콘솔 동작과 유사하게 설치된 전체 글로벌 Operator 목록을 보려면 인증된 모든 사용자가 다음 명령을 실행할 수 있습니다.

    $ oc get csvs -n openshift

프로세스

  • cluster 라는 OLMConfig 오브젝트를 편집하고 spec.features.disableCopiedCSVs 필드를 true 로 설정합니다.

    $ oc apply -f - <<EOF
    apiVersion: operators.coreos.com/v1
    kind: OLMConfig
    metadata:
      name: cluster
    spec:
      features:
        disableCopiedCSVs: true 1
    EOF
    1
    AllNamespaces 설치 모드 Operator에 대해 복사된 CSV를 비활성화

검증

  • CSV 복사본이 비활성화되면 OLM은 Operator의 네임 스페이스의 이벤트에서 이 정보를 캡처합니다.

    $ oc get events

    출력 예

    LAST SEEN   TYPE      REASON               OBJECT                                MESSAGE
    85s         Warning   DisabledCopiedCSVs   clusterserviceversion/my-csv.v1.0.0   CSV copying disabled for operators/my-csv.v1.0.0

    spec.features.disableCopiedCSVs 필드가 없거나 false 로 설정된 경우 OLM은 AllNamespaces 모드로 설치된 모든 Operator에 대해 복사된 CSV를 다시 생성하고 이전에 언급한 이벤트를 삭제합니다.

추가 리소스

4.5. Operator Lifecycle Manager에서 프록시 지원 구성

OpenShift Container Platform 클러스터에 글로벌 프록시가 구성된 경우 OLM(Operator Lifecycle Manager)은 클러스터 수준 프록시를 사용하여 관리하는 Operator를 자동으로 구성합니다. 그러나 설치된 Operator를 글로벌 프록시를 덮어쓰거나 사용자 정의 CA 인증서를 삽입하도록 구성할 수도 있습니다.

4.5.1. Operator의 프록시 설정 덮어쓰기

클러스터 수준 송신 프록시가 구성된 경우 OLM(Operator Lifecycle Manager)에서 실행되는 Operator는 배포 시 클러스터 수준 프록시 설정을 상속합니다. 클러스터 관리자는 Operator 서브스크립션을 구성하여 이러한 프록시 설정을 덮어쓸 수도 있습니다.

중요

Operator에서는 관리형 Operand에 대해 Pod의 프록시 설정을 위한 환경 변수 설정을 처리해야 합니다.

사전 요구 사항

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

프로세스

  1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.
  2. Operator를 선택하고 설치를 클릭합니다.
  3. Operator 설치 페이지에서 spec 섹션에 다음 환경 변수를 하나 이상 포함하도록 Subscription 오브젝트를 수정합니다.

    • HTTP_PROXY
    • HTTPS_PROXY
    • NO_PROXY

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

    프록시 설정 덮어쓰기가 포함된 Subscription 오브젝트

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: etcd-config-test
      namespace: openshift-operators
    spec:
      config:
        env:
        - name: HTTP_PROXY
          value: test_http
        - name: HTTPS_PROXY
          value: test_https
        - name: NO_PROXY
          value: test
      channel: clusterwide-alpha
      installPlanApproval: Automatic
      name: etcd
      source: community-operators
      sourceNamespace: openshift-marketplace
      startingCSV: etcdoperator.v0.9.4-clusterwide

    참고

    이러한 환경 변수는 이전에 설정한 클러스터 수준 또는 사용자 정의 프록시 설정을 제거하기 위해 빈 값을 사용하여 설정을 해제할 수도 있습니다.

    OLM에서는 이러한 환경 변수를 단위로 처리합니다. 환경 변수가 한 개 이상 설정되어 있으면 세 개 모두 덮어쓰는 것으로 간주하며 구독한 Operator의 배포에 클러스터 수준 기본값이 사용되지 않습니다.

  4. 선택한 네임스페이스에서 Operator를 사용할 수 있도록 설치를 클릭합니다.
  5. Operator의 CSV가 관련 네임스페이스에 표시되면 사용자 정의 프록시 환경 변수가 배포에 설정되어 있는지 확인할 수 있습니다. 예를 들면 CLI를 사용합니다.

    $ oc get deployment -n openshift-operators \
        etcd-operator -o yaml \
        | grep -i "PROXY" -A 2

    출력 예

            - name: HTTP_PROXY
              value: test_http
            - name: HTTPS_PROXY
              value: test_https
            - name: NO_PROXY
              value: test
            image: quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21088a98b93838e284a6086b13917f96b0d9c
    ...

4.5.2. 사용자 정의 CA 인증서 삽입

클러스터 관리자가 구성 맵을 사용하여 클러스터에 사용자 정의 CA 인증서를 추가하면 Cluster Network Operator는 사용자 제공 인증서와 시스템 CA 인증서를 단일 번들로 병합합니다. 이 병합된 번들은 OLM(Operator Lifecycle Manager)에서 실행 중인 Operator에 삽입할 수 있는데 이러한 작업은 중간자 HTTPS 프록시를 사용하는 경우 유용합니다.

사전 요구 사항

  • cluster-admin 권한이 있는 계정을 사용하여 OpenShift Container Platform 클러스터에 액세스할 수 있습니다.
  • 구성 맵을 사용하여 사용자 정의 CA 인증서를 클러스터에 추가했습니다.
  • 필요한 Operator가 OLM에 설치되어 실행되고 있습니다.

프로세스

  1. Operator의 서브스크립션이 존재하고 다음 라벨을 포함하는 네임스페이스에 빈 구성 맵을 생성합니다.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: trusted-ca 1
      labels:
        config.openshift.io/inject-trusted-cabundle: "true" 2
    1
    구성 맵의 이름입니다.
    2
    CNO(Cluster Network Operator)에 병합된 번들을 삽입하도록 요청합니다.

    이 구성 맵이 생성되면 병합된 번들의 인증서 콘텐츠로 즉시 채워집니다.

  2. 사용자 정의 CA가 필요한 Pod 내의 각 컨테이너에 trusted-ca 구성 맵을 볼륨으로 마운트하는 spec.config 섹션을 포함하도록 Subscription 오브젝트를 업데이트합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: my-operator
    spec:
      package: etcd
      channel: alpha
      config: 1
        selector:
          matchLabels:
            <labels_for_pods> 2
        volumes: 3
        - name: trusted-ca
          configMap:
            name: trusted-ca
            items:
              - key: ca-bundle.crt 4
                path: tls-ca-bundle.pem 5
        volumeMounts: 6
        - name: trusted-ca
          mountPath: /etc/pki/ca-trust/extracted/pem
          readOnly: true
    1
    config 섹션이 없는 경우 추가합니다.
    2
    Operator에서 보유한 Pod와 일치하도록 라벨을 지정합니다.
    3
    trusted-ca 볼륨을 생성합니다.
    4
    구성 맵 키로 ca-bundle.crt가 필요합니다.
    5
    구성 맵 경로로 tls-ca-bundle.pem이 필요합니다.
    6
    trusted-ca 볼륨 마운트를 생성합니다.
    참고

    Operator 배포는 기관을 검증하지 못하고 알 수 없는 권한 오류로 서명된 x509 인증서 를 표시할 수 있습니다. 이 오류는 Operator 서브스크립션을 사용할 때 사용자 정의 CA를 삽입한 후에도 발생할 수 있습니다. 이 경우 Operator 서브스크립션을 사용하여 mountPath 를 trusted-ca의 /etc/ssl/certs 로 설정할 수 있습니다.

4.6. Operator 상태 보기

OLM(Operator Lifecycle Manager)의 시스템 상태를 이해하는 것은 설치된 Operator와 관련된 결정을 내리고 문제를 디버깅하는 데 중요합니다. OLM에서는 서브스크립션 및 관련 카탈로그 소스의 상태 및 수행된 작업과 관련된 통찰력을 제공합니다. 이를 통해 사용자는 Operator의 상태를 더 잘 이해할 수 있습니다.

4.6.1. Operator 서브스크립션 상태 유형

서브스크립션은 다음 상태 유형을 보고할 수 있습니다.

표 4.1. 서브스크립션 상태 유형
상태설명

CatalogSourcesUnhealthy

해결에 사용되는 일부 또는 모든 카탈로그 소스가 정상 상태가 아닙니다.

InstallPlanMissing

서브스크립션 설치 계획이 없습니다.

InstallPlanPending

서브스크립션 설치 계획이 설치 대기 중입니다.

InstallPlanFailed

서브스크립션 설치 계획이 실패했습니다.

ResolutionFailed

서브스크립션의 종속성 확인에 실패했습니다.

참고

기본 OpenShift Container Platform 클러스터 Operator는 CVO(Cluster Version Operator)에서 관리하며 Subscription 오브젝트가 없습니다. 애플리케이션 Operator는 OLM(Operator Lifecycle Manager)에서 관리하며 Subscription 오브젝트가 있습니다.

4.6.2. CLI를 사용하여 Operator 서브스크립션 상태 보기

CLI를 사용하여 Operator 서브스크립션 상태를 볼 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. Operator 서브스크립션을 나열합니다.

    $ oc get subs -n <operator_namespace>
  2. oc describe 명령을 사용하여 Subscription 리소스를 검사합니다.

    $ oc describe sub <subscription_name> -n <operator_namespace>
  3. 명령 출력에서 Operator 서브스크립션 조건 유형의 상태에 대한 Conditions 섹션을 확인합니다. 다음 예에서 사용 가능한 모든 카탈로그 소스가 정상이므로 CatalogSourcesUnhealthy 조건 유형의 상태가 false입니다.

    출력 예

    Name:         cluster-logging
    Namespace:    openshift-logging
    Labels:       operators.coreos.com/cluster-logging.openshift-logging=
    Annotations:  <none>
    API Version:  operators.coreos.com/v1alpha1
    Kind:         Subscription
    # ...
    Conditions:
       Last Transition Time:  2019-07-29T13:42:57Z
       Message:               all available catalogsources are healthy
       Reason:                AllCatalogSourcesHealthy
       Status:                False
       Type:                  CatalogSourcesUnhealthy
    # ...

참고

기본 OpenShift Container Platform 클러스터 Operator는 CVO(Cluster Version Operator)에서 관리하며 Subscription 오브젝트가 없습니다. 애플리케이션 Operator는 OLM(Operator Lifecycle Manager)에서 관리하며 Subscription 오브젝트가 있습니다.

4.6.3. CLI를 사용하여 Operator 카탈로그 소스 상태 보기

CLI를 사용하여 Operator 카탈로그 소스의 상태를 볼 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 네임스페이스의 카탈로그 소스를 나열합니다. 예를 들어 클러스터 전체 카탈로그 소스에 사용되는 openshift-marketplace 네임스페이스를 확인할 수 있습니다.

    $ oc get catalogsources -n openshift-marketplace

    출력 예

    NAME                  DISPLAY               TYPE   PUBLISHER   AGE
    certified-operators   Certified Operators   grpc   Red Hat     55m
    community-operators   Community Operators   grpc   Red Hat     55m
    example-catalog       Example Catalog       grpc   Example Org 2m25s
    redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
    redhat-operators      Red Hat Operators     grpc   Red Hat     55m

  2. oc describe 명령을 사용하여 카탈로그 소스에 대한 자세한 내용 및 상태를 가져옵니다.

    $ oc describe catalogsource example-catalog -n openshift-marketplace

    출력 예

    Name:         example-catalog
    Namespace:    openshift-marketplace
    Labels:       <none>
    Annotations:  operatorframework.io/managed-by: marketplace-operator
                  target.workload.openshift.io/management: {"effect": "PreferredDuringScheduling"}
    API Version:  operators.coreos.com/v1alpha1
    Kind:         CatalogSource
    # ...
    Status:
      Connection State:
        Address:              example-catalog.openshift-marketplace.svc:50051
        Last Connect:         2021-09-09T17:07:35Z
        Last Observed State:  TRANSIENT_FAILURE
      Registry Service:
        Created At:         2021-09-09T17:05:45Z
        Port:               50051
        Protocol:           grpc
        Service Name:       example-catalog
        Service Namespace:  openshift-marketplace
    # ...

    앞의 예제 출력에서 마지막으로 관찰된 상태는 TRANSIENT_FAILURE입니다. 이 상태는 카탈로그 소스에 대한 연결을 설정하는 데 문제가 있음을 나타냅니다.

  3. 카탈로그 소스가 생성된 네임스페이스의 Pod를 나열합니다.

    $ oc get pods -n openshift-marketplace

    출력 예

    NAME                                    READY   STATUS             RESTARTS   AGE
    certified-operators-cv9nn               1/1     Running            0          36m
    community-operators-6v8lp               1/1     Running            0          36m
    marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
    example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
    redhat-marketplace-57p8c                1/1     Running            0          36m
    redhat-operators-smxx8                  1/1     Running            0          36m

    카탈로그 소스가 네임스페이스에 생성되면 해당 네임스페이스에 카탈로그 소스의 Pod가 생성됩니다. 위 예제 출력에서 example-catalog-bwt8z pod의 상태는 ImagePullBackOff입니다. 이 상태는 카탈로그 소스의 인덱스 이미지를 가져오는 데 문제가 있음을 나타냅니다.

  4. 자세한 정보는 oc describe 명령을 사용하여 Pod를 검사합니다.

    $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

    출력 예

    Name:         example-catalog-bwt8z
    Namespace:    openshift-marketplace
    Priority:     0
    Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
    ...
    Events:
      Type     Reason          Age                From               Message
      ----     ------          ----               ----               -------
      Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
      Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
      Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
      Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
      Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
      Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
      Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

    앞의 예제 출력에서 오류 메시지는 권한 부여 문제로 인해 카탈로그 소스의 인덱스 이미지를 성공적으로 가져오지 못한 것으로 표시됩니다. 예를 들어 인덱스 이미지는 로그인 인증 정보가 필요한 레지스트리에 저장할 수 있습니다.

4.7. Operator 조건 관리

클러스터 관리자는 OLM(Operator Lifecycle Manager)을 사용하여 Operator 상태를 관리할 수 있습니다.

4.7.1. Operator 상태 덮어쓰기

클러스터 관리자는 Operator에서 보고한 지원되는 Operator 상태를 무시해야 할 수 있습니다. 이러한 상태가 있는 경우 Spec.Overrides 어레이의 Operator 상태가 Spec.Conditions 어레이의 상태를 덮어씁니다. 그러면 클러스터 관리자가 Operator에서 OLM(Operator Lifecycle Manager)에 상태를 잘못 보고하는 상황을 처리할 수 있습니다.

참고

기본적으로 Spec.Overrides 어레이는 클러스터 관리자가 추가할 때까지 OperatorCondition 오브젝트에 존재하지 않습니다. 사용자가 추가하거나 사용자 정의 Operator 논리의 결과로 Spec.Conditions 배열도 존재하지 않습니다.

예를 들어 항상 업그레이드할 수 없다고 보고하는 알려진 버전의 Operator를 떠올려 보십시오. 이 경우 Operator에서 업그레이드할 수 없다고 보고하더라도 Operator를 업그레이드해야 할 수 있습니다. 이 작업은 OperatorCondition 오브젝트의 Spec.Overrides 배열에 조건 유형상태를 추가하여 Operator 조건을 재정의하여 수행할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OLM을 사용하여 OperatorCondition 오브젝트가 설치된 Operator입니다.

프로세스

  1. Operator의 OperatorCondition 오브젝트를 편집합니다.

    $ oc edit operatorcondition <name>
  2. 오브젝트에 Spec.Overrides 어레이를 추가합니다.

    Operator 조건 덮어쓰기 예제

    apiVersion: operators.coreos.com/v1
    kind: OperatorCondition
    metadata:
      name: my-operator
      namespace: operators
    spec:
      overrides:
      - type: Upgradeable 1
        status: "True"
        reason: "upgradeIsSafe"
        message: "This is a known issue with the Operator where it always reports that it cannot be upgraded."
      conditions:
      - type: Upgradeable
        status: "False"
        reason: "migration"
        message: "The operator is performing a migration."
        lastTransitionTime: "2020-08-24T23:15:55Z"

    1
    클러스터 관리자는 업그레이드 준비 상태를 True로 변경할 수 있습니다.

4.7.2. Operator 조건을 사용하도록 Operator 업데이트

OLM(Operator Lifecycle Manager)은 OLM에서 조정하는 각 ClusterServiceVersion 리소스에 대해 OperatorCondition 리소스를 자동으로 생성합니다. CSV의 모든 서비스 계정에는 Operator에 속하는 OperatorCondition과 상호 작용할 수 있도록 RBAC가 부여됩니다.

Operator 작성자는 Operator가 OLM에 의해 배포된 후 operator-lib 라이브러리를 사용하여 자체 조건을 설정할 수 있도록 Operator를 개발할 수 있습니다. Operator 조건을 Operator 작성자로 설정하는 방법에 대한 자세한 내용은 Operator 조건 활성화 페이지를 참조하십시오.

4.7.2.1. 기본값 설정

OLM은 이전 버전과의 호환성을 유지하기 위해 OperatorCondition 리소스의 부재를 조건을 옵트아웃하는 것으로 처리합니다. 따라서 Operator 조건 사용에 옵트인하는 Operator는 Pod의 준비 상태 프로브를 true로 설정하기 전에 기본 조건을 설정해야 합니다. 그러면 Operator에 조건을 올바른 상태로 업데이트할 수 있는 유예 기간이 제공됩니다.

4.7.3. 추가 리소스

4.8. 비 클러스터 관리자가 Operator를 설치하도록 허용

클러스터 관리자는 Operator 그룹을 사용하여 일반 사용자가 Operator 를 설치할 수 있도록 허용할 수 있습니다.

추가 리소스

4.8.1. Operator 설치 정책 이해

Operator를 실행하는 데 광범위한 권한이 필요할 수 있으며 필요한 권한이 버전에 따라 다를 수 있습니다. OLM(Operator Lifecycle Manager)은 cluster-admin 권한으로 실행됩니다. 기본적으로 Operator 작성자는 CSV(클러스터 서비스 버전)에서 권한 세트를 지정할 수 있으며 OLM은 이를 Operator에 부여합니다.

Operator가 클러스터 범위 권한을 달성할 수 없고 사용자가 OLM을 사용하여 권한을 에스컬레이션할 수 없도록 클러스터 관리자는 클러스터에 추가되기 전에 Operator를 수동으로 감사할 수 있습니다. 클러스터 관리자에게는 서비스 계정을 사용하여 Operator를 설치 또는 업그레이드하는 동안 수행할 수 있는 작업을 결정하고 제한하는 툴도 제공됩니다.

클러스터 관리자는 일련의 권한이 부여된 서비스 계정과 Operator group을 연결할 수 있습니다. 서비스 계정은 RBAC(역할 기반 액세스 제어) 규칙을 사용하여 사전 정의된 범위 내에서만 실행되도록 Operator에 정책을 설정합니다. 결과적으로 Operator는 해당 규칙에서 명시적으로 허용하지 않는 작업을 수행할 수 없습니다.

Operator 그룹을 사용하면 충분한 권한이 있는 사용자는 범위가 제한된 Operator를 설치할 수 있습니다. 결과적으로 더 많은 사용자가 더 많은 Operator 프레임워크 툴을 안전하게 사용할 수 있어 Operator를 사용하여 애플리케이션을 빌드할 수 있는 풍부한 환경을 제공할 수 있습니다.

참고

Subscription 오브젝트에 대한 RBAC(역할 기반 액세스 제어)는 네임스페이스에서 edit 또는 admin 역할이 있는 모든 사용자에게 자동으로 부여됩니다. 그러나 OperatorGroup 오브젝트에 RBAC가 존재하지 않습니다. 이 경우 일반 사용자가 Operator를 설치하지 못하도록 합니다. Operator group을 사전 설치하는 것은 효과적으로 설치 권한을 부여하는 것입니다.

Operator 그룹을 서비스 계정과 연결할 때 다음 사항에 유의하십시오.

  • APIServiceCustomResourceDefinition 리소스는 항상 cluster-admin 역할을 사용하여 OLM에 의해 생성됩니다. Operator group과 연결된 서비스 계정에는 이러한 리소스를 작성할 수 있는 권한을 부여해서는 안 됩니다.
  • 이제 Operator group에 연결된 모든 Operator의 권한이 지정된 서비스 계정에 부여된 권한으로 제한됩니다. Operator에서 서비스 계정 범위를 벗어나는 권한을 요청하면 클러스터 관리자가 문제를 해결하고 해결할 수 있도록 적절한 오류와 함께 설치에 실패합니다.

4.8.1.1. 설치 시나리오

Operator를 클러스터에서 설치하거나 업그레이드할 수 있는지 결정하는 경우 OLM(Operator Lifecycle Manager)은 다음 시나리오를 고려합니다.

  • 클러스터 관리자가 새 Operator group을 생성하고 서비스 계정을 지정합니다. 이 Operator group과 연결된 모든 Operator가 설치되고 서비스 계정에 부여된 권한에 따라 실행됩니다.
  • 클러스터 관리자가 새 Operator group을 생성하고 서비스 계정을 지정하지 않습니다. OpenShift Container Platform은 이전 버전과의 호환성을 유지하므로 기본 동작은 그대로 유지되면서 Operator 설치 및 업그레이드가 허용됩니다.
  • 서비스 계정을 지정하지 않는 기존 Operator group의 경우 기본 동작은 그대로 유지되면서 Operator 설치 및 업그레이드가 허용됩니다.
  • 클러스터 관리자가 기존 Operator group을 업데이트하고 서비스 계정을 지정합니다. OLM을 사용하면 현재 권한을 사용하여 기존 Operator를 계속 실행될 수 있습니다. 이러한 기존 Operator에서 업그레이드를 수행하면 기존 Operator가 새 Operator와 같이 서비스 계정에 부여된 권한에 따라 다시 설치되어 실행됩니다.
  • 권한을 추가하거나 제거함으로써 Operator group에서 지정하는 서비스 계정이 변경되거나 기존 서비스 계정을 새 서비스 계정과 교체합니다. 기존 Operator에서 업그레이드를 수행하면 기존 Operator가 새 Operator와 같이 업데이트된 서비스 계정에 부여된 권한에 따라 다시 설치되어 실행됩니다.
  • 클러스터 관리자는 Operator group에서 서비스 계정을 제거합니다. 기본 동작은 유지되고 Operator 설치 및 업그레이드는 허용됩니다.

4.8.1.2. 설치 워크플로

Operator group이 서비스 계정에 연결되고 Operator가 설치 또는 업그레이드되면 OLM(Operator Lifecycle Manager)에서 다음과 같은 워크플로를 사용합니다.

  1. OLM에서 지정된 Subscription 오브젝트를 선택합니다.
  2. OLM에서 이 서브스크립션에 연결된 Operator group을 가져옵니다.
  3. OLM에서 Operator group에 서비스 계정이 지정되었는지 확인합니다.
  4. OLM에서 서비스 계정에 대한 클라이언트 범위를 생성하고 범위가 지정된 클라이언트를 사용하여 Operator를 설치합니다. 이렇게 하면 Operator에서 요청한 모든 권한이 항상 Operator group 서비스 계정의 권한으로 제한됩니다.
  5. OLM은 CSV에 지정된 권한 세트를 사용하여 새 서비스 계정을 생성하고 Operator에 할당합니다. Operator는 할당된 서비스 계정으로 실행됩니다.

4.8.2. Operator 설치 범위 지정

OLM(Operator Lifecycle Manager)의 Operator 설치 및 업그레이드에 대한 범위 지정 규칙을 제공하려면 서비스 계정을 Operator group에 연결합니다.

클러스터 관리자는 다음 예제를 통해 일련의 Operator를 지정된 네임스페이스로 제한할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • OpenShift CLI(oc)가 설치되어 있습니다.

프로세스

  1. 새 네임스페이스를 생성합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Namespace
    metadata:
      name: scoped
    EOF
  2. Operator를 제한할 권한을 할당합니다. 이를 위해서는 새 서비스 계정, 관련 역할, 역할 바인딩을 생성해야 합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: scoped
      namespace: scoped
    EOF

    다음 예제에서는 간소화를 위해 지정된 네임스페이스에서 모든 작업을 수행할 수 있는 서비스 계정 권한을 부여합니다. 프로덕션 환경에서는 더 세분화된 권한 세트를 생성해야 합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: scoped
      namespace: scoped
    rules:
    - apiGroups: ["*"]
      resources: ["*"]
      verbs: ["*"]
    ---
    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: scoped-bindings
      namespace: scoped
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: Role
      name: scoped
    subjects:
    - kind: ServiceAccount
      name: scoped
      namespace: scoped
    EOF
  3. 지정된 네임스페이스에 OperatorGroup 오브젝트를 생성합니다. 이 Operator group은 지정된 네임스페이스를 대상으로 하여 테넌시가 제한되도록 합니다.

    또한 Operator group에서는 사용자가 서비스 계정을 지정할 수 있습니다. 이전 단계에서 생성한 서비스 계정을 지정합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: scoped
      namespace: scoped
    spec:
      serviceAccountName: scoped
      targetNamespaces:
      - scoped
    EOF

    지정된 네임스페이스에 설치된 Operator는 모두 이 Operator group 및 지정된 서비스 계정에 연결됩니다.

  4. 지정된 네임스페이스에 Subscription 오브젝트를 생성하여 Operator를 설치합니다.

    $ cat <<EOF | oc create -f -
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: etcd
      namespace: scoped
    spec:
      channel: singlenamespace-alpha
      name: etcd
      source: <catalog_source_name> 1
      sourceNamespace: <catalog_source_namespace> 2
    EOF
    1
    지정된 네임스페이스에 이미 존재하는 카탈로그 소스 또는 글로벌 카탈로그 네임스페이스에 있는 카탈로그 소스를 지정합니다.
    2
    카탈로그 소스가 생성된 네임스페이스를 지정합니다.

    Operator group에 연결된 모든 Operator의 권한이 지정된 서비스 계정에 부여된 권한으로 제한됩니다. Operator에서 서비스 계정 외부에 있는 권한을 요청하는 경우 설치가 실패하고 관련 오류가 표시됩니다.

4.8.2.1. 세분화된 권한

OLM(Operator Lifecycle Manager)은 Operator group에 지정된 서비스 계정을 사용하여 설치 중인 Operator와 관련하여 다음 리소스를 생성하거나 업데이트합니다.

  • ClusterServiceVersion
  • 서브스크립션
  • Secret
  • ServiceAccount
  • Service
  • ClusterRoleClusterRoleBinding
  • RoleRoleBinding

Operator를 지정된 네임스페이스로 제한하려면 클러스터 관리자가 서비스 계정에 다음 권한을 부여하여 시작하면 됩니다.

참고

다음 역할은 일반적인 예이며 특정 Operator를 기반으로 추가 규칙이 필요할 수 있습니다.

kind: Role
rules:
- apiGroups: ["operators.coreos.com"]
  resources: ["subscriptions", "clusterserviceversions"]
  verbs: ["get", "create", "update", "patch"]
- apiGroups: [""]
  resources: ["services", "serviceaccounts"]
  verbs: ["get", "create", "update", "patch"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles", "rolebindings"]
  verbs: ["get", "create", "update", "patch"]
- apiGroups: ["apps"] 1
  resources: ["deployments"]
  verbs: ["list", "watch", "get", "create", "update", "patch", "delete"]
- apiGroups: [""] 2
  resources: ["pods"]
  verbs: ["list", "watch", "get", "create", "update", "patch", "delete"]
1 2
여기에 표시된 배포 및 Pod와 같은 기타 리소스를 생성하는 권한을 추가합니다.

또한 Operator에서 가져오기 보안을 지정하는 경우 다음 권한도 추가해야 합니다.

kind: ClusterRole 1
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get"]
---
kind: Role
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["create", "update", "patch"]
1
OLM 네임스페이스에서 보안을 가져오는 데 필요합니다.

4.8.3. Operator 카탈로그 액세스 제어

글로벌 카탈로그 네임스페이스 openshift-marketplace 에 Operator 카탈로그가 생성되면 카탈로그의 Operator가 모든 네임스페이스에 클러스터 전체에서 사용할 수 있습니다. 다른 네임스페이스에 생성된 카탈로그는 카탈로그의 동일한 네임스페이스에서만 Operator를 사용할 수 있도록 합니다.

비 클러스터 관리자 사용자가 Operator 설치 권한을 위임한 클러스터에서 클러스터 관리자는 해당 사용자가 설치할 수 있는 Operator 집합을 추가로 제어하거나 제한하려고 할 수 있습니다. 이 작업은 다음 작업을 통해 수행할 수 있습니다.

  1. 기본 글로벌 카탈로그를 모두 비활성화합니다.
  2. 관련 Operator 그룹이 사전 설치된 동일한 네임스페이스에서 사용자 정의 큐레이션 카탈로그를 활성화합니다.

4.8.4. 권한 장애 문제 해결

권한 부족으로 인해 Operator 설치가 실패하는 경우 다음 절차를 사용하여 오류를 확인합니다.

프로세스

  1. Subscription 오브젝트를 검토합니다. 해당 상태에는 Operator에 필요한 [Cluster]Role[Binding] 오브젝트를 생성하는 InstallPlan 오브젝트를 가리키는 오브젝트 참조 installPlanRef가 있습니다.

    apiVersion: operators.coreos.com/v1
    kind: Subscription
    metadata:
      name: etcd
      namespace: scoped
    status:
      installPlanRef:
        apiVersion: operators.coreos.com/v1
        kind: InstallPlan
        name: install-4plp8
        namespace: scoped
        resourceVersion: "117359"
        uid: 2c1df80e-afea-11e9-bce3-5254009c9c23
  2. InstallPlan 오브젝트의 상태에 오류가 있는지 확인합니다.

    apiVersion: operators.coreos.com/v1
    kind: InstallPlan
    status:
      conditions:
      - lastTransitionTime: "2019-07-26T21:13:10Z"
        lastUpdateTime: "2019-07-26T21:13:10Z"
        message: 'error creating clusterrole etcdoperator.v0.9.4-clusterwide-dsfx4: clusterroles.rbac.authorization.k8s.io
          is forbidden: User "system:serviceaccount:scoped:scoped" cannot create resource
          "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope'
        reason: InstallComponentFailed
        status: "False"
        type: Installed
      phase: Failed

    오류 메시지에는 다음이 표시됩니다.

    • 리소스의 API 그룹을 포함하여 생성할 수 없는 리소스 유형. 이 경우 rbac.authorization.k8s.io 그룹의 clusterroles입니다.
    • 리소스의 이름.
    • 오류 유형 is forbidden은 사용자에게 작업을 수행할 수 있는 권한이 충분하지 않음을 나타냅니다.
    • 리소스를 생성하거나 업데이트하려고 시도한 사용자의 이름. 이 경우 Operator group에 지정된 서비스 계정을 나타냅니다.
    • 작업 범위: cluster scope 여부

      사용자는 서비스 계정에 누락된 권한을 추가한 다음 다시 수행할 수 있습니다.

      참고

      OLM(Operator Lifecycle Manager)은 현재 첫 번째 시도에서 전체 오류 목록을 제공하지 않습니다.

4.9. 사용자 정의 카탈로그 관리

클러스터 관리자와 Operator 카탈로그 유지 관리자는 OpenShift Container Platform의 OLM(Operator Lifecycle Manager)에서 번들 형식을 사용하여 패키지된 사용자 정의 카탈로그를 생성하고 관리할 수 있습니다.

중요

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

클러스터가 사용자 정의 카탈로그를 사용하는 경우 Operator 작성자가 워크로드 문제를 방지하고 호환되지 않는 업그레이드를 방지하는 방법에 대한 자세한 내용은 OpenShift Container Platform 버전과의 Operator 호환성 제어를 참조하십시오.

4.9.1. 사전 요구 사항

4.9.2. 파일 기반 카탈로그

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

중요

OpenShift Container Platform 4.11부터 파일 기반 카탈로그 형식으로 기본 Red Hat 제공 Operator 카탈로그 릴리스입니다. 더 이상 사용되지 않는 SQLite 데이터베이스 형식으로 릴리스된 OpenShift Container Platform 4.6에 대한 기본 Red Hat 제공 Operator 카탈로그입니다.

SQLite 데이터베이스 형식과 관련된 opm 하위 명령, 플래그 및 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이 기능은 계속 지원되며 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 사용하는 카탈로그에 사용해야 합니다.

opm index prune 와 같은 SQLite 데이터베이스 형식을 사용하기 위한 opm 하위 명령 및 플래그는 파일 기반 카탈로그 형식에서는 작동하지 않습니다. 파일 기반 카탈로그 작업에 대한 자세한 내용은 Operator Framework 패키징 형식oc-mirror 플러그인을 사용하여 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.

4.9.2.1. 파일 기반 카탈로그 이미지 생성

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

사전 요구 사항

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

프로세스

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

    1. 다음 명령을 실행하여 카탈로그의 디렉터리를 생성합니다.

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

      $ opm generate dockerfile <catalog_dir> \
          -i registry.redhat.io/openshift4/ose-operator-registry:v4.15 1
      1
      -i 플래그를 사용하여 공식 Red Hat 기본 이미지를 지정합니다. 그러지 않으면 Dockerfile에서 기본 업스트림 이미지를 사용합니다.

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

      디렉터리 구조의 예

      . 1
      ├── <catalog_dir> 2
      └── <catalog_dir>.Dockerfile 3

      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
      1
      Operator 또는 패키지, 이름
      2
      서브스크립션이 지정되지 않은 경우 기본값으로 설정된 채널
      3
      Operator의 README.md 또는 기타 문서 경로
      4
      Operator 아이콘 경로
      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
    1
    번들 이미지의 가져오기 사양
    2
    카탈로그 구성 파일의 경로
    참고

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

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

    채널 항목 예

    ---
    schema: olm.channel
    package: <operator_name>
    name: preview
    entries:
      - name: <operator_name>.v0.1.0 1

    1
    <operator_name> 뒤의 마침표(.)를 버전 v 앞에 포함해야 합니다. 그렇지 않으면 항목이 opm validate 명령을 전달하지 못합니다.
  4. 파일 기반 카탈로그를 확인합니다.

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

      $ opm validate <catalog_dir>
    2. 오류 코드가 0인지 확인합니다.

      $ echo $?

      출력 예

      0

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

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
  6. 카탈로그 이미지를 레지스트리로 푸시합니다.

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

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

      $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>

추가 리소스

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

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

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

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

참고

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

oc-mirror 플러그인 및 이 사용 사례에 대한 자세한 내용은 "미러 미러 레지스트리 콘텐츠 업데이트" 섹션, 특히 "oc-mirror 플러그인을 사용하여 연결이 끊긴 설치를 위한 이미지 미러링" 섹션, 특히 "이미지 실행" 섹션을 참조하십시오.

사전 요구 사항

  • 워크스테이션에 다음이 있습니다.

    • opm CLI입니다.
    • podman 버전 1.9.3 이상.
    • 파일 기반 카탈로그 이미지입니다.
    • 이 카탈로그와 관련된 워크스테이션에서 최근에 초기화된 카탈로그 디렉터리 구조입니다.

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

프로세스

  1. YAML 형식의 카탈로그 이미지의 콘텐츠를 카탈로그 디렉터리의 index.yaml 파일에 추출합니다.

    $ opm render <registry>/<namespace>/<catalog_image_name>:<tag> \
        -o yaml > <catalog_dir>/index.yaml
    참고

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

  2. 결과 index.yaml 파일의 내용을 사양으로 수정합니다.

    중요

    번들이 카탈로그에 게시되면 사용자 중 하나가 설치되었다고 가정합니다. 해당 버전이 설치된 사용자를 방지하려면 카탈로그의 이전에 게시된 모든 번들에 현재 또는 최신 채널 헤드에 대한 업데이트 경로가 있는지 확인합니다.

    • Operator를 추가하려면 "파일 기반 카탈로그 이미지 생성" 프로세스에서 패키지, 번들 및 채널 항목을 생성하는 단계를 수행합니다.
    • Operator를 제거하려면 패키지와 관련된 olm.package,olm.channel, olm.bundle blobs 세트를 삭제합니다. 다음 예제에서는 카탈로그에서 example-operator 패키지를 제거하려면 삭제해야 하는 세트를 보여줍니다.

      예 4.2. 삭제된 항목의 예

      ---
      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
      ---
    • Operator에 대한 사용 중단 메시지를 추가하거나 업데이트하려면 패키지의 index .yaml 파일과 동일한 디렉터리에precations.yaml 파일이 있는지 확인합니다. deprecations.yaml 파일 형식에 대한 자세한 내용은 "olm.deprecations 스키마"를 참조하십시오.
  3. 변경 사항을 저장하십시오.
  4. 카탈로그를 확인합니다.

    $ opm validate <catalog_dir>
  5. 카탈로그를 다시 빌드합니다.

    $ podman build . \
        -f <catalog_dir>.Dockerfile \
        -t <registry>/<namespace>/<catalog_image_name>:<tag>
  6. 업데이트된 카탈로그 이미지를 레지스트리로 푸시합니다.

    $ podman push <registry>/<namespace>/<catalog_image_name>:<tag>

검증

  1. 웹 콘솔에서 관리클러스터 설정 → 구성 페이지의 OperatorHub 구성 리소스로 이동합니다.
  2. 업데이트된 카탈로그 이미지의 pull 사양을 사용하도록 카탈로그 소스를 추가하거나 기존 카탈로그 소스를 업데이트합니다.

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

  3. 카탈로그 소스가 READY 상태인 후 OperatorOperatorHub 페이지로 이동하여 수행된 변경 사항이 Operator 목록에 반영되었는지 확인합니다.

4.9.3. SQLite 기반 카탈로그

중요

Operator 카탈로그의 SQLite 데이터베이스 형식은 더 이상 사용되지 않는 기능입니다. 더 이상 사용되지 않는 기능은 여전히 OpenShift Container Platform에 포함되어 있으며 계속 지원됩니다. 그러나 이 기능은 향후 릴리스에서 제거될 예정이므로 새로운 배포에는 사용하지 않는 것이 좋습니다.

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

4.9.3.1. SQLite 기반 인덱스 이미지 생성

opm CLI를 사용하여 SQLite 데이터베이스 형식을 기반으로 인덱스 이미지를 생성할 수 있습니다.

사전 요구 사항

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

프로세스

  1. 새 인덱스를 시작합니다.

    $ opm index add \
        --bundles <registry>/<namespace>/<bundle_image_name>:<tag> \1
        --tag <registry>/<namespace>/<index_image_name>:<tag> \2
        [--binary-image <registry_base_image>] 3
    1
    인덱스에 추가할 번들 이미지를 쉼표로 구분한 목록입니다.
    2
    인덱스 이미지에 포함할 이미지 태그입니다.
    3
    선택 사항: 카탈로그 제공에 사용할 대체 레지스트리 기본 이미지입니다.
  2. 인덱스 이미지를 레지스트리로 내보냅니다.

    1. 필요한 경우 대상 레지스트리로 인증합니다.

      $ podman login <registry>
    2. 인덱스 이미지를 내보냅니다.

      $ podman push <registry>/<namespace>/<index_image_name>:<tag>

4.9.3.2. SQLite 기반 인덱스 이미지 업데이트

사용자 정의 인덱스 이미지를 참조하는 카탈로그 소스를 사용하도록 OperatorHub를 구성한 후 클러스터 관리자는 인덱스 이미지에 번들 이미지를 추가하여 클러스터에 사용 가능한 Operator를 최신 상태로 유지할 수 있습니다.

opm index add 명령을 사용하여 기존 인덱스 이미지를 업데이트할 수 있습니다.

사전 요구 사항

  • opm CLI를 설치했습니다.
  • podman 버전 1.9.3 이상이 있습니다.
  • 인덱스 이미지가 빌드되어 레지스트리로 푸시됩니다.
  • 인덱스 이미지를 참조하는 기존 카탈로그 소스가 있습니다.

프로세스

  1. 번들 이미지를 추가하여 기존 인덱스를 업데이트합니다.

    $ opm index add \
        --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
        --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
        --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
        --pull-tool podman 4
    1
    --bundles 플래그는 인덱스에 추가할 쉼표로 구분된 추가 번들 이미지 목록을 지정합니다.
    2
    --from-index 플래그는 이전에 내보낸 인덱스를 지정합니다.
    3
    --tag 플래그는 업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다.
    4
    --pull-tool 플래그는 컨테이너 이미지를 가져오는 데 사용되는 툴을 지정합니다.

    다음과 같습니다.

    <registry>
    quay.io 또는 mirror.example.com 과 같은 레지스트리의 호스트 이름을 지정합니다.
    <namespace>
    ocs-dev 또는 abc 와 같은 레지스트리의 네임스페이스를 지정합니다.
    <new_bundle_image>
    ocs-operator 와 같이 레지스트리에 추가할 새 번들 이미지를 지정합니다.
    <digest>
    번들 이미지의 SHA 이미지 ID 또는 다이제스트(예: c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 )를 지정합니다.
    <existing_index_image>
    이전에 내보낸 이미지(예: abc-redhat-operator-index )를 지정합니다.
    <existing_tag>
    4.15 와 같이 이전에 푸시된 이미지 태그를 지정합니다.
    <updated_tag>
    4.15.1 과 같이 업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다.

    명령 예

    $ opm index add \
        --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
        --from-index mirror.example.com/abc/abc-redhat-operator-index:4.15 \
        --tag mirror.example.com/abc/abc-redhat-operator-index:4.15.1 \
        --pull-tool podman

  2. 업데이트된 인덱스 이미지를 내보냅니다.

    $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>
  3. OLM(Operator Lifecycle Manager)이 정기적으로 카탈로그 소스에서 참조하는 인덱스 이미지를 자동으로 폴링하면 새 패키지가 성공적으로 추가되었는지 확인합니다.

    $ oc get packagemanifests -n openshift-marketplace

4.9.3.3. SQLite 기반 인덱스 이미지 필터링

Operator 번들 포맷을 기반으로 하는 인덱스 이미지는 Operator 카탈로그의 컨테이너화된 스냅샷입니다. 지정된 패키지 목록을 제외한 모든 인덱스를 필터링하거나 정리할 수 있습니다. 이 목록은 원하는 Operator만 포함하는 소스 인덱스 복사본을 생성합니다.

사전 요구 사항

  • podman 버전 1.9.3 이상이 있습니다.
  • grpcurl (타사 명령줄 툴)이 있습니다.
  • opm CLI를 설치했습니다.
  • Docker v2-2 를 지원하는 레지스트리에 액세스할 수 있습니다.

프로세스

  1. 대상 레지스트리로 인증합니다.

    $ podman login <target_registry>
  2. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

    1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.15

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.15...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

    2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out
    3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

    4. podman run 명령을 실행한 터미널 세션에서 CtrlC를 눌러 컨테이너 프로세스를 중지합니다.
  3. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

    $ opm index prune \
        -f registry.redhat.io/redhat/redhat-operator-index:v4.15 \1
        -p advanced-cluster-management,jaeger-product,quay-operator \2
        [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \3
        -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.15 4
    1
    정리할 인덱스입니다.
    2
    쉼표로 구분된 보관할 패키지 목록입니다.
    3
    IBM Power® 및 IBM Z® 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 마이너 버전과 일치하는 태그가 있는 Operator 레지스트리 기본 이미지입니다.
    4
    빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.
  4. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

    $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.15

    <namespace>는 레지스트리의 기존 네임스페이스입니다.

4.9.4. 카탈로그 소스 및 Pod 보안 승인

Pod 보안 표준을 보장하기 위해 OpenShift Container Platform 4.11에 Pod 보안 승인이 도입되었습니다. SQLite 기반 카탈로그 형식 및 OpenShift Container Platform 4.11 이전에 릴리스된 opm CLI 툴 버전을 사용하여 빌드된 카탈로그 소스는 제한된 Pod 보안 적용에서 실행할 수 없습니다.

OpenShift Container Platform 4.15에서 네임스페이스에는 기본적으로 제한된 Pod 보안 적용 기능이 없으며 기본 카탈로그 소스 보안 모드는 legacy 로 설정됩니다.

모든 네임스페이스에 대한 기본 제한된 적용은 향후 OpenShift Container Platform 릴리스에 포함될 예정입니다. 제한된 적용이 발생하면 카탈로그 소스 Pod에 대한 Pod 사양의 보안 컨텍스트가 제한된 Pod 보안 표준과 일치해야 합니다. 카탈로그 소스 이미지에 다른 Pod 보안 표준이 필요한 경우 네임스페이스의 Pod 보안 승인 레이블을 명시적으로 설정해야 합니다.

참고

restricted로 SQLite 기반 카탈로그 소스 Pod를 실행하지 않으려면 OpenShift Container Platform 4.15에서 카탈로그 소스를 업데이트할 필요가 없습니다.

그러나 제한된 Pod 보안 적용에서 카탈로그 소스를 실행하려면 지금 작업을 수행하는 것이 좋습니다. 카탈로그 소스가 제한된 Pod 보안 적용에서 실행되도록 하지 않으면 향후 OpenShift Container Platform 릴리스에서 카탈로그 소스가 실행되지 않을 수 있습니다.

카탈로그 작성자는 다음 작업 중 하나를 완료하여 제한된 Pod 보안 적용과 호환성을 활성화할 수 있습니다.

  • 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션합니다.
  • OpenShift Container Platform 4.11 이상에서 릴리스된 opm CLI 툴 버전으로 카탈로그 이미지를 업데이트합니다.
참고

SQLite 데이터베이스 카탈로그 형식은 더 이상 사용되지 않지만 Red Hat에서 계속 지원합니다. 향후 릴리스에서는 SQLite 데이터베이스 형식이 지원되지 않으며 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션해야 합니다. OpenShift Container Platform 4.11부터 기본 Red Hat 제공 Operator 카탈로그는 파일 기반 카탈로그 형식으로 릴리스됩니다. 파일 기반 카탈로그는 제한된 Pod 보안 적용과 호환됩니다.

SQLite 데이터베이스 카탈로그 이미지를 업데이트하거나 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션하지 않으려면 승격된 권한으로 실행되도록 카탈로그를 구성할 수 있습니다.

4.9.4.1. SQLite 데이터베이스 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션

더 이상 사용되지 않는 SQLite 데이터베이스 형식 카탈로그를 파일 기반 카탈로그 형식으로 업데이트할 수 있습니다.

사전 요구 사항

  • SQLite 데이터베이스 카탈로그 소스가 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 워크스테이션에 OpenShift Container Platform 4.15와 함께 릴리스된 opm CLI 툴의 최신 버전이 있습니다.

프로세스

  1. 다음 명령을 실행하여 SQLite 데이터베이스 카탈로그를 파일 기반 카탈로그로 마이그레이션합니다.

    $ opm migrate <registry_image> <fbc_directory>
  2. 다음 명령을 실행하여 파일 기반 카탈로그에 대한 Dockerfile을 생성합니다.

    $ opm generate dockerfile <fbc_directory> \
      --binary-image \
      registry.redhat.io/openshift4/ose-operator-registry:v4.15

다음 단계

  • 생성된 Dockerfile을 빌드, 태그를 지정하고 레지스트리로 내보낼 수 있습니다.

4.9.4.2. SQLite 데이터베이스 카탈로그 이미지 다시 빌드

OpenShift Container Platform 버전과 함께 릴리스된 opm CLI 툴의 최신 버전으로 SQLite 데이터베이스 카탈로그 이미지를 다시 빌드할 수 있습니다.

사전 요구 사항

  • SQLite 데이터베이스 카탈로그 소스가 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 워크스테이션에 OpenShift Container Platform 4.15와 함께 릴리스된 opm CLI 툴의 최신 버전이 있습니다.

프로세스

  • 다음 명령을 실행하여 최신 버전의 opm CLI 툴로 카탈로그를 다시 빌드합니다.

    $ opm index add --binary-image \
      registry.redhat.io/openshift4/ose-operator-registry:v4.15 \
      --from-index <your_registry_image> \
      --bundles "" -t \<your_registry_image>

4.9.4.3. 승격된 권한으로 실행되도록 카탈로그 구성

SQLite 데이터베이스 카탈로그 이미지를 업데이트하거나 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션하지 않으려면 다음 작업을 수행하여 기본 Pod 보안 적용이 restricted로 변경될 때 카탈로그 소스가 실행되도록 할 수 있습니다.

  • 카탈로그 소스 정의에서 카탈로그 보안 모드를 legacy로 수동으로 설정합니다. 이 작업을 수행하면 기본 카탈로그 보안 모드가 restricted로 변경되는 경우에도 기존 권한으로 카탈로그가 실행됩니다.
  • 기준 또는 권한 있는 Pod 보안 시행을 위해 카탈로그 소스 네임스페이스에 레이블을 지정합니다.
참고

SQLite 데이터베이스 카탈로그 형식은 더 이상 사용되지 않지만 Red Hat에서 계속 지원합니다. 향후 릴리스에서는 SQLite 데이터베이스 형식이 지원되지 않으며 카탈로그를 파일 기반 카탈로그 형식으로 마이그레이션해야 합니다. 파일 기반 카탈로그는 제한된 Pod 보안 적용과 호환됩니다.

사전 요구 사항

  • SQLite 데이터베이스 카탈로그 소스가 있습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • 기준선 또는 권한 있는 Pod 보안 승인 표준으로 Pod 실행을 지원하는 대상 네임스페이스가 있습니다.

프로세스

  1. 다음 예와 같이 spec.grpcPodConfig.securityContextConfig 레이블을 legacy 로 설정하여 CatalogSource 정의를 편집합니다.

    CatalogSource 정의의 예

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-catsrc
      namespace: my-ns
    spec:
      sourceType: grpc
      grpcPodConfig:
        securityContextConfig: legacy
      image: my-image:latest

    작은 정보

    OpenShift Container Platform 4.15에서 spec.grpcPodConfig.securityContextConfig 필드는 기본적으로 legacy 로 설정됩니다. 향후 OpenShift Container Platform 릴리스에서는 기본 설정이 restricted 로 변경될 예정입니다. 제한된 적용으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.

  2. 다음 예와 같이 <namespace>.yaml 파일을 편집하여 카탈로그 소스 네임스페이스에 승격된 Pod 보안 승인 표준을 추가합니다.

    &lt ;namespace>.yaml 파일 예

    apiVersion: v1
    kind: Namespace
    metadata:
    ...
      labels:
        security.openshift.io/scc.podSecurityLabelSync: "false" 1
        openshift.io/cluster-monitoring: "true"
        pod-security.kubernetes.io/enforce: baseline 2
      name: "<namespace_name>"

    1
    네임스페이스에 security.openshift.io/scc.podSecurityLabelSync=false 라벨을 추가하여 Pod 보안 레이블 동기화를 끕니다.
    2
    Pod 보안 승인 pod-security.kubernetes.io/enforce 레이블을 적용합니다. 레이블을 baseline 또는 privileged 로 설정합니다. 네임스페이스의 다른 워크로드에 권한 있는 프로필이 필요하지 않는 한 기준 Pod 보안 프로필을 사용합니다.

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

OpenShift Container Platform 클러스터에 카탈로그 소스를 추가하면 사용자를 위한 Operator를 검색하고 설치할 수 있습니다. 클러스터 관리자는 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성할 수 있습니다. OperatorHub는 카탈로그 소스를 사용하여 사용자 인터페이스를 채웁니다.

작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리클러스터 설정구성OperatorHub 페이지에서 개별 소스 를 생성, 업데이트, 삭제, 비활성화 및 활성화할 수 있는 소스 탭을 클릭합니다.

사전 요구 사항

  • 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

    1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace 1
        annotations:
          olm.catalogImageTemplate: 2
            "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
      spec:
        sourceType: grpc
        grpcPodConfig:
          securityContextConfig: <security_mode> 3
        image: <registry>/<namespace>/<index_image_name>:<tag> 4
        displayName: My Operator Catalog
        publisher: <publisher_name> 5
        updateStrategy:
          registryPoll: 6
            interval: 30m
      1
      카탈로그 소스를 모든 네임스페이스의 사용자가 전역적으로 사용할 수 있도록 하려면 openshift-marketplace 네임스페이스를 지정합니다. 그러지 않으면 카탈로그의 범위가 지정되고 해당 네임스페이스에 대해서만 사용할 수 있도록 다른 네임스페이스를 지정할 수 있습니다.
      2
      선택 사항: olm.catalogImageTemplate 주석을 인덱스 이미지 이름으로 설정하고 이미지 태그의 템플릿을 구성할 때 표시된 대로 하나 이상의 Kubernetes 클러스터 버전 변수를 사용합니다.
      3
      legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 OpenShift Container Platform 릴리스에서는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.
      4
      인덱스 이미지를 지정합니다. 이미지 이름 다음에 태그를 지정하는 경우(예: :v4.15 ) 카탈로그 소스 Pod는 Always 의 이미지 가져오기 정책을 사용합니다. 즉, Pod는 컨테이너를 시작하기 전에 항상 이미지를 가져옵니다. 다이제스트를 지정하는 경우(예: @sha256:<id >) 이미지 가져오기 정책은 IfNotPresent 입니다. 즉 Pod는 노드에 없는 경우에만 이미지를 가져옵니다.
      5
      카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.
      6
      카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.
    2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml
  2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

    1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

이제 OpenShift Container Platform 웹 콘솔의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.

4.9.6. 프라이빗 레지스트리에서 Operator용 이미지에 액세스

OLM(Operator Lifecycle Manager)에서 관리하는 Operator와 관련된 특정 이미지가 개인 레지스트리라고도 하는 인증된 컨테이너 이미지 레지스트리에서 호스팅되는 경우 OLM 및 OperatorHub는 기본적으로 이미지를 가져올 수 없습니다. 액세스를 활성화하려면 레지스트리의 인증 정보가 포함된 풀 시크릿을 생성할 수 있습니다. OLM은 카탈로그 소스에서 하나 이상의 가져오기 보안을 참조함으로써 Operator 및 카탈로그 네임스페이스에 보안을 배치하여 설치를 허용할 수 있습니다.

Operator 또는 해당 Operand에 필요한 기타 이미지에서도 프라이빗 레지스트리에 액세스해야 할 수 있습니다. 이 시나리오에서 OLM은 대상 테넌트 네임스페이스에 보안을 배치하지 않지만 필요한 액세스 권한을 활성화하기 위해 글로벌 클러스터 가져오기 보안 또는 개별 네임스페이스 서비스 계정에 인증 자격 증명을 추가할 수 있습니다.

OLM에서 관리하는 Operator에 적절한 가져오기 액세스 권한이 있는지 확인할 때는 다음 유형의 이미지를 고려해야 합니다.

인덱스 이미지
CatalogSource 오브젝트는 Operator 번들 형식을 사용하고 이미지 레지스트리에서 호스팅되는 컨테이너 이미지로 패키지된 카탈로그 소스에 해당하는 인덱스 이미지를 참조할 수 있습니다. 인덱스 이미지가 프라이빗 레지스트리에서 호스팅되는 경우 시크릿을 사용하여 가져오기 액세스 권한을 활성화할 수 있습니다.
번들 이미지
Operator 번들 이미지는 컨테이너 이미지로 패키지되어 Operator의 고유 버전을 나타내는 메타데이터와 매니페스트입니다. 카탈로그 소스에서 참조한 번들 이미지가 하나 이상의 프라이빗 레지스트리에서 호스팅되는 경우 보안을 사용하여 가져오기 액세스 권한을 활성화할 수 있습니다.
Operator 및 Operand 이미지

카탈로그 소스에서 설치한 Operator에서 Operator 이미지 자체 또는 조사하는 Operand 이미지 중 하나로 프라이빗 이미지를 사용하는 경우 Operator가 설치되지 않습니다. 배포에 필수 레지스트리 인증에 대한 액세스 권한이 없기 때문입니다. 카탈로그 소스의 보안을 참조해도 OLM에서 Operand가 설치된 대상 테넌트 네임스페이스에 보안을 배치할 수 없습니다.

대신 클러스터의 모든 네임스페이스에 대한 액세스 권한을 제공하는 openshift-config 네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가하면 됩니다. 또는 전체 클러스터에 대한 액세스 권한을 제공할 수 없는 경우 대상 테넌트 네임스페이스의 default 서비스 계정에 가져오기 보안을 추가할 수 있습니다.

사전 요구 사항

  • 프라이빗 레지스트리에서 다음 중 하나 이상 호스팅해야 합니다.

    • 인덱스 이미지 또는 카탈로그 이미지.
    • Operator 번들 이미지.
    • Operator 또는 Operand 이미지.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 필요한 각 프라이빗 레지스트리에 대해 보안을 생성합니다.

    1. 프라이빗 레지스트리에 로그인하여 레지스트리 자격 증명 파일을 생성하거나 업데이트합니다.

      $ podman login <registry>:<port>
      참고

      레지스트리 자격 증명의 파일 경로는 레지스트리에 로그인하는 데 사용하는 컨테이너 툴에 따라 다를 수 있습니다. podman CLI의 경우 기본 위치는 ${XDG_RUNTIME_DIR}/containers/auth.json입니다. docker CLI의 경우 기본 위치는 /root/.docker/config.json입니다.

    2. 보안당 하나의 레지스트리에 대한 자격 증명만 포함하고 여러 레지스트리의 자격 증명은 별도의 보안에서 관리하는 것이 좋습니다. 이후 단계에서 CatalogSource 오브젝트에 여러 보안을 포함할 수 있으며 OpenShift Container Platform은 이미지를 가져오는 동안 사용할 수 있도록 보안을 단일 가상 자격 증명 파일에 병합합니다.

      기본적으로 레지스트리 자격 증명 파일은 둘 이상의 레지스트리 또는 하나의 레지스트리에 있는 여러 리포지토리의 세부 정보를 저장할 수 있습니다. 파일의 현재 콘텐츠를 확인합니다. 예를 들면 다음과 같습니다.

      여러 레지스트리에 대한 자격 증명을 저장하는 파일

      {
          "auths": {
              "registry.redhat.io": {
                  "auth": "FrNHNydQXdzclNqdg=="
              },
              "quay.io": {
                  "auth": "fegdsRib21iMQ=="
              },
              "https://quay.io/my-namespace/my-user/my-image": {
                  "auth": "eWfjwsDdfsa221=="
              },
              "https://quay.io/my-namespace/my-user": {
                  "auth": "feFweDdscw34rR=="
              },
              "https://quay.io/my-namespace": {
                  "auth": "frwEews4fescyq=="
              }
          }
      }

      이 파일은 이후 단계에서 보안을 생성하는 데 사용되므로 파일마다 하나의 레지스트리에만 세부 정보를 저장해야 합니다. 이 작업은 다음 방법 중 하나를 사용하여 수행할 수 있습니다.

      • podman logout <registry> 명령을 사용하여 원하는 레지스트리 하나만 남을 때까지 추가 레지스트리의 자격 증명을 제거합니다.
      • 레지스트리 자격 증명 파일을 편집하고 레지스트리 세부 정보를 분리하여 여러 파일에 저장합니다. 예를 들면 다음과 같습니다.

        하나의 레지스트리에 대한 자격 증명을 저장하는 파일

        {
                "auths": {
                        "registry.redhat.io": {
                                "auth": "FrNHNydQXdzclNqdg=="
                        }
                }
        }

        또 다른 레지스트리에 대한 자격 증명을 저장하는 파일

        {
                "auths": {
                        "quay.io": {
                                "auth": "Xd2lhdsbnRib21iMQ=="
                        }
                }
        }

    3. 프라이빗 레지스트리의 인증 자격 증명 정보가 포함된 openshift-marketplace 네임스페이스에 보안을 생성합니다.

      $ oc create secret generic <secret_name> \
          -n openshift-marketplace \
          --from-file=.dockerconfigjson=<path/to/registry/credentials> \
          --type=kubernetes.io/dockerconfigjson

      이 단계를 반복하여 다른 필수 프라이빗 레지스트리에 대한 추가 보안을 생성하고 --from-file 플래그를 업데이트하여 다른 레지스트리 자격 증명 파일 경로를 지정합니다.

  2. 기존 CatalogSource 오브젝트를 생성하거나 업데이트하여 하나 이상의 보안을 참조합니다.

    apiVersion: operators.coreos.com/v1alpha1
    kind: CatalogSource
    metadata:
      name: my-operator-catalog
      namespace: openshift-marketplace
    spec:
      sourceType: grpc
      secrets: 1
      - "<secret_name_1>"
      - "<secret_name_2>"
      grpcPodConfig:
        securityContextConfig: <security_mode> 2
      image: <registry>:<port>/<namespace>/<image>:<tag>
      displayName: My Operator Catalog
      publisher: <publisher_name>
      updateStrategy:
        registryPoll:
          interval: 30m
    1
    spec.secrets 섹션을 추가하고 필요한 보안을 지정합니다.
    2
    legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 OpenShift Container Platform 릴리스에서는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.
  3. 구독한 Operator에서 참조하는 Operator 또는 Operand 이미지에 프라이빗 레지스트리에 대한 액세스 권한이 필요한 경우 클러스터의 모든 네임스페이스 또는 개별 대상 테넌트 네임스페이스에 액세스 권한을 제공하면 됩니다.

    • 클러스터의 모든 네임스페이스에 액세스 권한을 제공하려면 openshift-config 네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가합니다.

      주의

      클러스터 리소스는 클러스터의 사용성을 일시적으로 제한할 수 있는 새 글로벌 가져오기 보안에 맞게 조정해야 합니다.

      1. 글로벌 가져오기 보안에서 .dockerconfigjson 파일을 추출합니다.

        $ oc extract secret/pull-secret -n openshift-config --confirm
      2. 필요한 프라이빗 레지스트리 또는 레지스트리에 대한 인증 자격 증명을 사용하여 .dockerconfigjson 파일을 업데이트한 후 새 파일로 저장합니다.

        $ cat .dockerconfigjson | \
            jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1
            > new_dockerconfigjson
        1
        <registry>:<port>/<namespace>를 프라이빗 레지스트리 세부 정보로 교체하고 <token>을 인증 자격 증명으로 교체합니다.
      3. 새 파일을 사용하여 글로벌 가져오기 보안을 업데이트합니다.

        $ oc set data secret/pull-secret -n openshift-config \
            --from-file=.dockerconfigjson=new_dockerconfigjson
    • 개별 네임스페이스를 업데이트하려면 대상 테넌트 네임스페이스에 액세스해야 하는 Operator의 서비스 계정에 가져오기 보안을 추가합니다.

      1. 테넌트 네임스페이스에서 openshift-marketplace용으로 생성한 보안을 다시 생성합니다.

        $ oc create secret generic <secret_name> \
            -n <tenant_namespace> \
            --from-file=.dockerconfigjson=<path/to/registry/credentials> \
            --type=kubernetes.io/dockerconfigjson
      2. 테넌트 네임스페이스를 검색하여 Operator의 서비스 계정 이름을 확인합니다.

        $ oc get sa -n <tenant_namespace> 1
        1
        Operator가 개별 네임스페이스에 설치된 경우 해당 네임스페이스를 검색합니다. Operator가 모든 네임스페이스에 설치된 경우 openshift-operators 네임스페이스를 검색합니다.

        출력 예

        NAME            SECRETS   AGE
        builder         2         6m1s
        default         2         6m1s
        deployer        2         6m1s
        etcd-operator   2         5m18s 1

        1
        설치된 etcd Operator의 서비스 계정입니다.
      3. Operator의 서비스 계정에 보안을 연결합니다.

        $ oc secrets link <operator_sa> \
            -n <tenant_namespace> \
             <secret_name> \
            --for=pull

4.9.7. 기본 OperatorHub 카탈로그 소스 비활성화

Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다. 클러스터 관리자는 기본 카탈로그 세트를 비활성화할 수 있습니다.

프로세스

  • OperatorHub 오브젝트에 disableAllDefaultSources: true를 추가하여 기본 카탈로그의 소스를 비활성화합니다.

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리클러스터 설정구성OperatorHub 페이지에서 개별 소스 를 생성, 업데이트, 삭제, 비활성화 및 활성화할 수 있는 소스 탭을 클릭합니다.

4.9.8. 사용자 정의 카탈로그 제거

클러스터 관리자는 관련 카탈로그 소스를 삭제하여 이전에 클러스터에 추가된 사용자 정의 Operator 카탈로그를 제거할 수 있습니다.

사전 요구 사항

  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 웹 콘솔의 관리자 화면에서 관리자클러스터 설정으로 이동합니다.
  2. 구성 탭을 클릭한 다음 OperatorHub 를 클릭합니다.
  3. 소스 탭을 클릭합니다.
  4. 제거할 카탈로그의 옵션 메뉴 kebab 를 선택한 다음 카탈로그 소스 삭제를 클릭합니다.

4.10. 제한된 네트워크에서 Operator Lifecycle Manager 사용

제한된 네트워크( 연결이 끊긴 클러스터)에 설치된 OpenShift Container Platform 클러스터 의 경우 OLM(Operator Lifecycle Manager)은 기본적으로 원격 레지스트리에서 호스팅되는 Red Hat 제공 OperatorHub 소스에 액세스할 수 없습니다. 이러한 원격 소스에는 완전한 인터넷 연결이 필요하기 때문입니다.

그러나 클러스터 관리자는 워크스테이션에 완전한 인터넷 액세스 권한이 있는 경우 제한된 네트워크에서 OLM을 사용하도록 클러스터를 활성화할 수 있습니다. 원격 OperatorHub 콘텐츠를 가져오는 데 완전한 인터넷 액세스 권한이 필요한 워크스테이션은 원격 소스의 로컬 미러를 준비하고 콘텐츠를 미러 레지스트리로 내보내는 데 사용됩니다.

미러 레지스트리는 워크스테이션 및 연결이 끊긴 클러스터 모두에 연결해야 하는 베스천 호스트에 있거나 미러링된 콘텐츠를 연결이 끊긴 환경에 물리적으로 이동하기 위해 이동식 미디어가 필요한 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있을 수 있습니다.

이 가이드에서는 제한된 네트워크에서 OLM을 활성화하는 데 필요한 다음 프로세스를 설명합니다.

  • OLM의 기본 원격 OperatorHub 소스를 비활성화합니다.
  • 완전한 인터넷 액세스가 가능한 워크스테이션을 사용하여 OperatorHub 콘텐츠의 로컬 미러를 생성하고 미러 레지스트리로 내보냅니다.
  • 기본 원격 소스가 아닌 미러 레지스트리의 로컬 소스에서 Operator를 설치하고 관리하도록 OLM을 구성합니다.

제한된 네트워크에서 OLM을 활성화한 후에는 제한되지 않은 워크스테이션을 계속 사용하여 최신 버전의 Operator가 출시될 때 로컬 OperatorHub 소스를 업데이트할 수 있습니다.

중요

OLM은 로컬 소스에서 Operator를 관리할 수 있지만 지정된 Operator를 제한된 네트워크에서 성공적으로 실행할 수 있는 기능은 다음 기준을 충족하는 Operator 자체에 따라 다릅니다.

  • Operator에서 기능을 수행하는 데 필요할 수 있는 관련 이미지 또는 기타 컨테이너 이미지를 CSV(ClusterServiceVersion) 오브젝트의 relatedImages 매개변수에 나열합니다.
  • 태그가 아닌 다이제스트(SHA)를 통해 지정된 모든 이미지를 참조합니다.

Red Hat Ecosystem Catalog 에서 다음 항목을 필터링하여 연결이 끊긴 모드에서 실행을 지원하는 Red Hat Operator 목록을 검색할 수 있습니다.

유형

컨테이너화된 애플리케이션

배포 방법

Operator

인프라 기능

연결 해제

4.10.1. 사전 요구 사항

  • cluster-admin 권한이 있는 사용자로 OpenShift Container Platform 클러스터에 로그인합니다.
참고

IBM Z®의 제한된 네트워크에서 OLM을 사용하는 경우 레지스트리를 배치하는 디렉터리에 12GB 이상을 할당해야 합니다.

4.10.2. 기본 OperatorHub 카탈로그 소스 비활성화

Red Hat 및 커뮤니티 프로젝트에서 제공하는 콘텐츠를 소싱하는 Operator 카탈로그는 OpenShift Container Platform을 설치하는 동안 기본적으로 OperatorHub용으로 구성됩니다. 제한된 네트워크 환경에서는 클러스터 관리자로서 기본 카탈로그를 비활성화해야 합니다. 그런 다음 로컬 카탈로그 소스를 사용하도록 OperatorHub를 구성할 수 있습니다.

프로세스

  • OperatorHub 오브젝트에 disableAllDefaultSources: true를 추가하여 기본 카탈로그의 소스를 비활성화합니다.

    $ oc patch OperatorHub cluster --type json \
        -p '[{"op": "add", "path": "/spec/disableAllDefaultSources", "value": true}]'
작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리클러스터 설정구성OperatorHub 페이지에서 개별 소스 를 생성, 업데이트, 삭제, 비활성화 및 활성화할 수 있는 소스 탭을 클릭합니다.

4.10.3. Operator 카탈로그 미러링

연결이 끊긴 클러스터에 사용하기 위해 Operator 카탈로그를 미러링하는 방법은 연결이 끊긴 설치를 위한 이미지 설치 → 미러링을 참조하십시오.

중요

OpenShift Container Platform 4.11부터 파일 기반 카탈로그 형식의 기본 Red Hat 제공 Operator 카탈로그 릴리스입니다. 더 이상 사용되지 않는 SQLite 데이터베이스 형식으로 릴리스된 OpenShift Container Platform 4.6 through 4.10의 기본 Red Hat 제공 Operator 카탈로그입니다.

SQLite 데이터베이스 형식과 관련된 opm 하위 명령, 플래그 및 기능은 더 이상 사용되지 않으며 향후 릴리스에서 제거됩니다. 이 기능은 계속 지원되며 더 이상 사용되지 않는 SQLite 데이터베이스 형식을 사용하는 카탈로그에 사용해야 합니다.

opm index prune 와 같은 SQLite 데이터베이스 형식을 사용하기 위한 opm 하위 명령 및 플래그는 파일 기반 카탈로그 형식에서는 작동하지 않습니다. 파일 기반 카탈로그 작업에 대한 자세한 내용은 Operator 프레임워크 패키징 형식,사용자 정의 카탈로그 관리, oc-mirror 플러그인을 사용하여 연결이 끊긴 설치의 이미지 미러링 을 참조하십시오.

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

OpenShift Container Platform 클러스터에 카탈로그 소스를 추가하면 사용자를 위한 Operator를 검색하고 설치할 수 있습니다. 클러스터 관리자는 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성할 수 있습니다. OperatorHub는 카탈로그 소스를 사용하여 사용자 인터페이스를 채웁니다.

작은 정보

또는 웹 콘솔을 사용하여 카탈로그 소스를 관리할 수 있습니다. 관리클러스터 설정구성OperatorHub 페이지에서 개별 소스 를 생성, 업데이트, 삭제, 비활성화 및 활성화할 수 있는 소스 탭을 클릭합니다.

사전 요구 사항

  • 인덱스 이미지를 빌드하여 레지스트리로 내보냈습니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.

프로세스

  1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다. oc adm catalog mirror 명령을 사용하여 카탈로그를 대상 레지스트리에 미러링한 경우 매니페스트 디렉터리에서 생성된 catalogSource.yaml 파일을 시작점으로 사용할 수 있습니다.

    1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog 1
        namespace: openshift-marketplace 2
      spec:
        sourceType: grpc
        grpcPodConfig:
          securityContextConfig: <security_mode> 3
        image: <registry>/<namespace>/redhat-operator-index:v4.15 4
        displayName: My Operator Catalog
        publisher: <publisher_name> 5
        updateStrategy:
          registryPoll: 6
            interval: 30m
      1
      레지스트리에 업로드하기 전에 콘텐츠를 로컬 파일에 미러링한 경우 오브젝트를 생성할 때 "잘못된 리소스 이름" 오류가 발생하지 않도록 metadata.name 필드에서 백슬래시(/) 문자를 제거합니다.
      2
      카탈로그 소스를 모든 네임스페이스의 사용자가 전역적으로 사용할 수 있도록 하려면 openshift-marketplace 네임스페이스를 지정합니다. 그러지 않으면 카탈로그의 범위가 지정되고 해당 네임스페이스에 대해서만 사용할 수 있도록 다른 네임스페이스를 지정할 수 있습니다.
      3
      legacy 또는 restricted 를 지정합니다. 필드가 설정되지 않은 경우 기본값은 legacy 입니다. 향후 OpenShift Container Platform 릴리스에서는 기본값이 제한 될 예정입니다. 제한된 권한으로 카탈로그를 실행할 수 없는 경우 이 필드를 기존으로 수동으로 설정하는 것이 좋습니다.
      4
      인덱스 이미지를 지정합니다. 이미지 이름 다음에 태그를 지정하는 경우(예: :v4.15 ) 카탈로그 소스 Pod는 Always 의 이미지 가져오기 정책을 사용합니다. 즉, Pod는 컨테이너를 시작하기 전에 항상 이미지를 가져옵니다. 다이제스트를 지정하는 경우(예: @sha256:<id >) 이미지 가져오기 정책은 IfNotPresent 입니다. 즉 Pod는 노드에 없는 경우에만 이미지를 가져옵니다.
      5
      카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.
      6
      카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.
    2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml
  2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

    1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

    2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

    3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

이제 OpenShift Container Platform 웹 콘솔의 OperatorHub 페이지에서 Operator를 설치할 수 있습니다.

4.10.5. 다음 단계

4.11. 카탈로그 소스 Pod 예약

OLM(Operator Lifecycle Manager) 소스 유형 grpc 에서 spec.image 를 정의하는 경우 Catalog Operator는 정의된 이미지 콘텐츠를 제공하는 Pod를 생성합니다. 기본적으로 이 Pod는 사양에 다음을 정의합니다.

  • kubernetes.io/os=linux 노드 선택기만 있습니다.
  • 기본 우선순위 클래스 이름: system-cluster-critical.
  • 허용 오차가 없습니다.

관리자는 CatalogSource 오브젝트의 선택적