7.2.
7.2.1.
OLM 1.0은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
- RukPak
7.2.2.
OLM 1.0은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
7.2.2.1. Operator API
apiVersion: operators.operatorframework.io/v1alpha1 kind: Operator metadata: name: <operator_name> spec: packageName: <package_name> channel: <channel_name> version: <version_number>
예를 들면 다음과 같습니다.
$ oc get operator.operators.operatorframework.io
7.2.2.1.1. OLM 1.0의 대상 버전 정보
Operator CR에 채널을 지정하면 OLM 1.0이 지정된 채널의 최신 릴리스를 설치합니다. 지정된 채널에 업데이트가 게시되면 OLM 1.0이 채널의 최신 릴리스로 자동 업데이트됩니다.
지정된 채널이 있는 CR의 예
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
name: quay-example
spec:
packageName: quay-operator
channel: stable-3.8 1
- 1
- 지정된 채널에 게시된 최신 릴리스를 설치합니다. 채널 업데이트가 자동으로 설치됩니다.
CR에서 Operator의 대상 버전을 지정하면 OLM 1.0이 지정된 버전을 설치합니다. 대상 버전이 Operator CR에 지정되면 카탈로그에 업데이트가 게시되면 OLM 1.0에서 대상 버전이 변경되지 않습니다.
클러스터에 설치된 Operator 버전을 업데이트하려면 Operator의 CR을 수동으로 업데이트해야 합니다. Operator의 대상 버전을 지정하면 Operator 버전이 지정된 릴리스에 고정됩니다.
대상 버전이 지정된 CR의 예
apiVersion: operators.operatorframework.io/v1alpha1
kind: Operator
metadata:
name: quay-example
spec:
packageName: quay-operator
version: 3.8.12 1
- 1
- 대상 버전을 지정합니다. 클러스터에 설치된 Operator 버전을 업데이트하려면 Operator의 CR을 원하는 대상 버전으로 수동으로 업데이트해야 합니다.
설치된 Operator 버전을 변경하려면 Operator의 CR을 원하는 대상 버전으로 편집합니다.
이전 버전의 OLM에서는 Operator 작성자가 지원되지 않는 버전으로 업데이트하지 못하도록 업그레이드 에지를 정의할 수 있었습니다. 현재 개발 상태에서 OLM 1.0은 업그레이드 에지 정의를 적용하지 않습니다. Operator 버전을 지정하고 OLM 1.0에서 업데이트를 적용하려고 할 수 있습니다.
다음 명령을 실행하여 사용 가능한 버전 및 채널을 포함하여 Operator의 카탈로그 콘텐츠를 검사할 수 있습니다.
명령 구문
$ oc get package <catalog_name>-<package_name> -o yaml
명령 구문
$ oc apply -f <extension_name>.yaml
문제 해결
존재하지 않는 대상 버전 또는 채널을 지정하는 경우 다음 명령을 실행하여 Operator의 상태를 확인할 수 있습니다.
$ oc get operator.operators.operatorframework.io <operator_name> -o yaml
출력 예
apiVersion: operators.operatorframework.io/v1alpha1 kind: Operator metadata: annotations: kubectl.kubernetes.io/last-applied-configuration: | {"apiVersion":"operators.operatorframework.io/v1alpha1","kind":"Operator","metadata":{"annotations":{},"name":"quay-example"},"spec":{"packageName":"quay-operator","version":"999.99.9"}} creationTimestamp: "2023-10-19T18:39:37Z" generation: 3 name: quay-example resourceVersion: "51505" uid: 2558623b-8689-421c-8ed5-7b14234af166 spec: packageName: quay-operator version: 999.99.9 status: conditions: - lastTransitionTime: "2023-10-19T18:50:34Z" message: package 'quay-operator' at version '999.99.9' not found observedGeneration: 3 reason: ResolutionFailed status: "False" type: Resolved - lastTransitionTime: "2023-10-19T18:50:34Z" message: installation has not been attempted as resolution failed observedGeneration: 3 reason: InstallationStatusUnknown status: Unknown type: Installed
7.2.3.
OLM 1.0은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
7.2.3.1.
- 번들
- 번들 이미지
- 프로비저너
7.2.3.2.
RukPak은 Kubernetes 클러스터에 콘텐츠를 설치하고 관리하는 프로비전 프로그램으로 알려진 일련의 컨트롤러로 구성됩니다. RukPak은 또한 Bundle
및 BundleDeployment
의 두 가지 주요 API를 제공합니다. 이러한 구성 요소는 함께 작동하여 콘텐츠를 클러스터에 가져오고 설치하고 클러스터 내에서 리소스를 생성합니다.
현재 RukPak과 함께 두 개의 프로비저너가 구현되고 번들로 제공되는 일반 프로비저너 는 plain+v0
번들의 압축을 풀고, OLM(Operator Lifecycle Manager) registry+v1
번들의 압축을 풉니다.
프로비저너는 프로비저너를 명시적으로 참조하는 Bundle
및 BundleDeployment
리소스에 감시를 배치합니다. 지정된 번들의 경우 프로비저너는 Bundle
리소스의 내용을 클러스터에 압축을 풉니다. 그런 다음 해당 번들을 참조하는 BundleDeployment
리소스가 제공되면 프로비저너는 번들 콘텐츠를 설치하고 해당 리소스의 라이프사이클을 관리합니다.
7.2.3.3. 번들
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
번들은 생성 후 변경 불가능한 것으로 간주됩니다.
7.2.3.3.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
필드를 변경하지 않고 최신 버전의 번들 콘텐츠로 피벗할 수 있습니다. 이러한 의도하지 않은 피벗은 다음 시나리오에서 발생할 수 있습니다.
-
사용자가
Bundle
오브젝트의spec.source
필드에 이미지 태그, Git 분기 또는 Git 태그를 설정합니다. - 이미지 태그는 새 다이제스트로 이동하거나, 사용자가 변경 사항을 Git 분기로 내보내거나, 사용자가 삭제한 후 다른 커밋에서 Git 태그를 다시 가져옵니다.
- 사용자가 압축 풀기 Pod를 삭제하는 등 번들 압축 해제 Pod를 다시 생성하도록 하는 작업을 수행합니다.
이 시나리오가 발생하면 3단계의 새 콘텐츠의 압축을 풉니다. 번들 배포에서는 변경 사항을 감지하고 최신 버전의 콘텐츠로 피벗합니다.
이는 Pod의 컨테이너 이미지 중 하나가 태그를 사용하고 태그를 다른 다이제스트로 이동한 다음 나중에 기존 Pod가 다른 노드에 다시 예약되는 Pod 동작과 유사합니다. 이 시점에서 노드는 새 다이제스트에서 새 이미지를 가져와서 사용자가 명시적으로 요청하지 않고 다른 이미지를 실행합니다.
번들
사양 콘텐츠가 변경되지 않도록 하려면 번들을 생성할 때 다이제스트 기반 이미지 또는 Git 커밋 참조를 사용합니다.
7.2.3.3.2. 일반 번들 사양
RukPak의 일반 번들은 지정된 디렉터리에 있는 정적, 임의의 Kubernetes YAML 매니페스트 컬렉션입니다.
현재 구현된 일반 번들 형식은 plain+v0
형식입니다. 번들 형식인
은 번들 유형(일반 )과 현재 스키마 버전(plain
+v0v0
)을 결합합니다.
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 파일도 유효합니다.
7.2.3.3.3. 레지스트리 번들 사양
레지스트리 번들 또는 registry+v1
번들에는 기존 OLM(Operator Lifecycle Manager) 번들 형식으로 구성된 정적 Kubernetes YAML 매니페스트 세트가 포함되어 있습니다.
추가 리소스
7.2.3.4. 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
7.2.4.
OLM 1.0은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
7.2.4.1. 개념
7.2.4.1.1.
Package A |
|
|
|
Package C |
|
패키지
- A
- B
Constraints
출력 결과
-
A
v0.1.0
-
C
v0.1.0
-
A
7.2.4.1.2.
Package A |
|
|
|
Package C |
Package C |
패키지
- A
- B
Constraints
출력 결과
7.2.5. 카탈로그 (기술 프리뷰)
OLM(Operator Lifecycle Manager) 1.0은 카탈로그 구성 요소와 해당 리소스를 사용하여 Operator 및 확장 카탈로그를 관리합니다.
OLM 1.0은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
7.2.5.1. OLM 1.0의 카탈로그 정보
카탈로그 구성 요소를 사용하여 Operator 및 컨트롤러와 같은 Kubernetes 확장 카탈로그를 쿼리하여 설치 가능한 콘텐츠를 검색할 수 있습니다. Catalogd는 클러스터 내 클라이언트의 카탈로그 콘텐츠의 압축을 풀고 OLM(Operator Lifecycle Manager) 1.0 마이크로 서비스 제품군의 일부입니다. 현재 catalogd는 컨테이너 이미지로 패키지 및 배포되는 카탈로그 콘텐츠의 압축을 풉니다.
추가 리소스
7.2.5.1.1. OLM 1.0의 Red Hat 제공 Operator 카탈로그
OLM(Operator Lifecycle Manager) 1.0에는 기본적으로 Red Hat 제공 Operator 카탈로그가 포함되어 있지 않습니다. Red Hat 제공 카탈로그를 클러스터에 추가하려면 카탈로그의 CR(사용자 정의 리소스)을 생성하여 클러스터에 적용합니다. 다음 CR(사용자 정의 리소스) 예제에서는 OLM 1.0에 대한 카탈로그 리소스를 생성하는 방법을 보여줍니다.
Red Hat Operator 카탈로그의 예
apiVersion: catalogd.operatorframework.io/v1alpha1 kind: Catalog metadata: name: redhat-operators spec: source: type: image image: ref: registry.redhat.io/redhat/redhat-operator-index:v4.14
인증된 Operator 카탈로그의 예
apiVersion: catalogd.operatorframework.io/v1alpha1 kind: Catalog metadata: name: certified-operators spec: source: type: image image: ref: registry.redhat.io/redhat/certified-operator-index:v4.14
커뮤니티 Operator 카탈로그의 예
apiVersion: catalogd.operatorframework.io/v1alpha1 kind: Catalog metadata: name: community-operators spec: source: type: image image: ref: registry.redhat.io/redhat/community-operator-index:v4.14
다음 명령은 클러스터에 카탈로그를 추가합니다.
명령 구문
$ oc apply -f <catalog_name>.yaml 1
- 1
redhat-operators.yaml
과 같은 카탈로그 CR을 지정합니다.