7.2. 구성 요소 및 아키텍처

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

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

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

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

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

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

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

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

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

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

$ oc apply -f <extension_name>.yaml

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 필드를 변경하지 않고 최신 버전의 번들 콘텐츠로 피벗할 수 있습니다. 이러한 의도하지 않은 피벗은 다음 시나리오에서 발생할 수 있습니다.

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

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

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

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

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

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

$ tree manifests

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

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

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

사용자는 다음과 같은 종속성이 있는 패키지 A 및 B를 설치하려고 합니다.

또한 사용자는 A 버전을 v0.1.0 에 고정하려고 합니다.

OLM 1.0에 전달된 패키지 및 제약 조건

사용자는 다음과 같은 종속성이 있는 패키지 A 및 B를 설치하려고 합니다.

또한 사용자는 A 버전을 v0.1.0 에 고정하려고 합니다.

OLM 1.0에 전달된 패키지 및 제약 조건

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

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

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

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

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

$ oc apply -f <catalog_name>.yaml 1