5.7. CSV(클러스터 서비스 버전) 정의
ClusterServiceVersion 오브젝트에서 정의하는 CSV(클러스터 서비스 버전)는 클러스터에서 Operator를 실행할 때 OLM(Operator Lifecycle Manager)을 지원하는 Operator 메타데이터에서 생성되는 YAML 매니페스트입니다. 로고, 설명, 버전과 같은 정보로 사용자 인터페이스를 채우는 데 사용되는 Operator 컨테이너 이미지와 함께 제공되는 메타데이터입니다. 또한 필요한 RBAC 규칙 및 관리하거나 사용하는 CR(사용자 정의 리소스)과 같이 Operator를 실행하는 데 필요한 기술 정보의 소스이기도 합니다.
Operator SDK에는 CSV 생성기가 포함되어 YAML 매니페스트 및 Operator 소스 파일에 포함된 정보를 사용하여 사용자 정의한 현재 Operator 프로젝트에 대해 CSV를 생성합니다.
CSV 생성 명령을 사용하면 Operator에서 OLM과 상호 작용하거나 메타데이터를 카탈로그 레지스트리에 게시하는 데 전문적인 OLM 지식을 보유한 Operator 작성자가 필요하지 않습니다. 또한 새로운 Kubernetes 및 OLM 기능이 구현되면서 시간이 지남에 따라 CSV 사양이 변경될 수 있으므로 Operator SDK는 앞으로의 새로운 CSV 기능을 처리할 수 있도록 업데이트 시스템을 쉽게 확장할 수 있습니다.
5.7.1. CSV 생성 작동 방식
CSV(클러스터 서비스 버전)를 포함하는 Operator 번들 매니페스트에서는 OLM(Operator Lifecycle Manager)을 사용하여 애플리케이션을 표시, 생성, 관리하는 방법을 설명합니다. generate bundle 하위 명령으로 호출되는 Operator SDK의 CSV 생성기는 Operator를 카탈로그에 게시하고 OLM과 함께 배포하기 위한 첫 번째 단계입니다. 하위 명령에는 CSV 매니페스트를 구성하는 데 특정 입력 매니페스트가 필요합니다. 명령을 호출하면 CSV 베이스와 함께 모든 입력을 읽어 CSV를 멱등하게 생성하거나 재생성합니다.
일반적으로 generate bundle 하위 명령에서 사용하는 입력 Kustomize 베이스를 생성하기 위해 generate kustomize manifests 하위 명령을 먼저 실행합니다. 그러나 Operator SDK에서는 다음 하위 명령을 순서대로 실행하는 것을 포함하여 여러 작업을 자동화하는 make bundle 명령을 제공합니다.
-
generate kustomize manifests -
generate bundle -
bundle validate
추가 리소스
- 번들 및 CSV 생성을 비롯한 전체 프로시저를 보려면 Operator 번들링을 참조하십시오.
5.7.1.1. 생성된 파일 및 리소스
make bundle 명령은 Operator 프로젝트에서 다음 파일 및 디렉터리를 생성합니다.
-
ClusterServiceVersion(CSV) 오브젝트를 포함하는bundle/manifests라는 번들 매니페스트 디렉터리 -
bundle/metadata라는 번들 메타데이터 디렉터리 -
config/crd디렉터리의 모든 CRD(사용자 정의 리소스 정의) -
Dockerfile
bundle.Dockerfile
일반적으로 CSV에는 다음 리소스가 포함됩니다.
- 역할
- 네임스페이스 내에서 Operator 권한을 정의합니다.
- ClusterRole
- 클러스터 수준 Operator 권한을 정의합니다.
- Deployment
- Pod에서 Operator의 Operand를 실행하는 방법을 정의합니다.
- CRD(CustomResourceDefinition)
- Operator에서 조정하는 사용자 정의 리소스를 정의합니다.
- 사용자 정의 리소스 예제
- 특정 CRD의 사양을 준수하는 리소스의 예입니다.
5.7.1.2. 버전 관리
generate bundle 하위 명령의 --version 플래그는 처음으로 번들을 생성하고 기존 번들을 업그레이드할 때 번들에 대한 의미 체계 버전을 제공합니다.
Makefile에서 VERSION 변수를 설정하면 make bundle 명령에 의해 generate bundle 하위 명령이 실행될 때 해당 값을 사용하여 --version 플래그가 자동으로 호출됩니다. CSV 버전은 Operator 버전과 동일하며 Operator 버전을 업그레이드하면 새 CSV가 생성됩니다.
5.7.2. 수동으로 정의한 CSV 필드
대부분의 CSV 필드는 Operator SDK와 관련 없이 생성된 일반 매니페스트를 사용하여 채울 수 없습니다. 이러한 필드는 대부분 Operator 및 다양한 CRD(사용자 정의 리소스 정의)에 대해 사람이 작성한 메타데이터입니다.
Operator 작성자는 CSV(클러스터 서비스 버전) YAML 파일을 직접 수정하여 다음과 같은 필수 필드에 개인화된 데이터를 추가해야 합니다. Operator SDK는 필수 필드에서 데이터 부족이 탐지되는 경우 CSV 생성 중 경고를 표시합니다.
다음 테이블에는 필수 또는 선택적인 수동 정의 CSV 필드가 자세히 설명되어 있습니다.
표 5.7. 필수 항목
| 필드 | 설명 |
|---|---|
|
|
이 CSV의 고유 이름입니다. 고유성을 유지하도록 이름에 Operator 버전이 포함되어야 합니다(예: |
|
|
Operator 완성 모델에 따른 기능 수준입니다. 옵션에는 |
|
| Operator를 확인하는 공용 이름입니다. |
|
| Operator 기능에 대한 간단한 설명입니다. |
|
| Operator를 설명하는 키워드입니다. |
|
|
|
|
|
|
|
| Operator 내부에서 사용할 키-값 쌍입니다. |
|
|
Operator의 의미 체계 버전입니다(예: |
|
|
Operator에서 사용하는 모든 CRD입니다. CRD YAML 파일이
|
표 5.8. 선택 사항
| 필드 | 설명 |
|---|---|
|
| CSV 이름이 이 CSV로 교체됩니다. |
|
|
Operator 또는 애플리케이션과 관련된 URL(예: 웹 사이트 및 문서)을 각각 |
|
| Operator에서 클러스터의 리소스와 연결할 수 있는 선택기입니다. |
|
|
Operator 고유의 base64로 인코딩된 아이콘으로, |
|
|
이 버전의 소프트웨어에서 달성한 완성 수준입니다. 옵션에는 |
위의 각 필드에 보관해야 하는 데이터에 대한 자세한 내용은 CSV 사양에서 확인할 수 있습니다.
현재 사용자 개입이 필요한 여러 YAML 필드를 Operator 코드에서 구문 분석할 수 있습니다.
추가 리소스
5.7.2.1. Operator 메타데이터 주석
Operator 개발자는 CSV(클러스터 서비스 버전) 메타데이터에 특정 주석을 수동으로 정의하여 OperatorHub와 같은 UI의 기능을 활성화하거나 성능을 강조할 수 있습니다.
다음 테이블에는 metadata.annotations 필드를 사용하여 수동으로 정의할 수 있는 Operator 메타데이터 주석이 나열되어 있습니다.
표 5.9. 주석
| 필드 | 설명 |
|---|---|
|
| CRD(사용자 정의 리소스 정의) 템플릿에 최소 구성 세트를 제공합니다. 사용자가 추가로 사용자 정의할 수 있도록 호환되는 UI가 이 템플릿에 미리 채워집니다. |
|
|
Operator 설치 중 |
|
| Operator를 배포해야 하는 제안된 네임스페이스를 설정합니다. |
|
| Operator에서 지원하는 인프라 기능입니다. 사용자는 웹 콘솔에서 OperatorHub를 통해 Operator를 검색할 때 이러한 기능을 확인하고 필터링할 수 있습니다. 유효한 대소문자를 구분하는 값은 다음과 같습니다.
중요
FIPS 검증 / 진행중인 모듈 암호화 라이브러리 사용은
|
|
|
Operator를 사용하는 데 필요한 특정 서브스크립션을 나열하기 위한 자유 양식 어레이입니다. 예를 들면 |
|
| UI에서 사용자 조작용이 아닌 CRD를 숨깁니다. |
사용 사례 예
Operator에서 연결이 끊긴 및 프록시 인식 지원
operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]'
Operator에는 OpenShift Container Platform 라이센스가 필요합니다.
operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'
Operator에는 3scale 라이센스가 필요합니다.
operators.openshift.io/valid-subscription: '["3Scale Commercial License", "Red Hat Managed Integration"]'
Operator는 연결이 끊긴 프록시 인식을 지원하며 OpenShift Container Platform 라이센스가 필요합니다.
operators.openshift.io/infrastructure-features: '["disconnected", "proxy-aware"]' operators.openshift.io/valid-subscription: '["OpenShift Container Platform"]'
추가 리소스
5.7.3. 제한된 네트워크 환경에 대한 Operator 활성화
사용 중인 Operator는 Operator 작성자로서 제한된 네트워크 또는 연결이 끊긴 환경에서 제대로 실행하려면 추가 요구 사항을 충족해야 합니다.
연결이 끊긴 모드를 지원하는 Operator 요구 사항
Operator의 CSV(클러스터 서비스 버전)에서 다음을 수행합니다.
- Operator에서 기능을 수행하는 데 필요할 수 있는 관련 이미지 또는 기타 컨테이너 이미지를 나열합니다.
- 태그가 아닌 다이제스트(SHA)를 통해 지정된 모든 이미지를 참조합니다.
- Operator의 모든 종속 항목은 연결이 끊긴 모드에서 실행할 수 있어야 합니다.
- Operator에 클러스터 외부 리소스가 필요하지 않아야 합니다.
CSV 요구 사항의 경우 Operator 작성자는 다음과 같은 변경을 수행할 수 있습니다.
사전 요구 사항
- Operator 프로젝트에 CSV가 포함되어 있습니다.
프로세스
사용 중인 Operator에 대한 CSV의 두 위치에서 관련 이미지에 대한 SHA 참조를 사용합니다.
spec.relatedImages를 업데이트합니다.... spec: relatedImages: 1 - name: etcd-operator 2 image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 3 - name: etcd-image image: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68 ...
Operator에서 사용할 이미지를 삽입하는 환경 변수를 선언할 때 배포의
env섹션을 업데이트합니다.spec: install: spec: deployments: - name: etcd-operator-v3.1.1 spec: replicas: 1 selector: matchLabels: name: etcd-operator strategy: type: Recreate template: metadata: labels: name: etcd-operator spec: containers: - args: - /opt/etcd/bin/etcd_operator_run.sh env: - name: WATCH_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.annotations['olm.targetNamespaces'] - name: ETCD_OPERATOR_DEFAULT_ETCD_IMAGE 1 value: quay.io/etcd-operator/etcd@sha256:13348c15263bd8838ec1d5fc4550ede9860fcbb0f843e48cbccec07810eebb68 2 - name: ETCD_LOG_LEVEL value: INFO image: quay.io/etcd-operator/operator@sha256:d134a9865524c29fcf75bbc4469013bc38d8a15cb5f41acfddb6b9e492f556e4 3 imagePullPolicy: IfNotPresent livenessProbe: httpGet: path: /healthy port: 8080 initialDelaySeconds: 10 periodSeconds: 30 name: etcd-operator readinessProbe: httpGet: path: /ready port: 8080 initialDelaySeconds: 10 periodSeconds: 30 resources: {} serviceAccountName: etcd-operator strategy: deployment참고프로브를 구성할 때
timeoutSeconds값은periodSeconds값보다 작아야 합니다.timeoutSeconds기본값은1입니다.periodSeconds의 기본값은10입니다.
연결이 끊긴 환경에서도 Operator가 작동함을 나타내는
Disconnected주석을 추가합니다.metadata: annotations: operators.openshift.io/infrastructure-features: '["disconnected"]'이 인프라 기능을 통해 OperatorHub에서 Operator를 필터링할 수 있습니다.
5.7.4. 여러 아키텍처 및 운영 체제의 Operator 활성화
OLM(Operator Lifecycle Manager)은 모든 Operator가 Linux 호스트에서 실행되는 것으로 가정합니다. 그러나 Operator 작성자는 OpenShift Container Platform 클러스터에서 작업자 노드를 사용할 수 있는 경우 Operator가 다른 아키텍처에서 워크로드 관리를 지원하는지를 지정할 수 있습니다.
Operator가 AMD64 및 Linux 이외의 변형을 지원하는 경우 Operator에 지원되는 변형 목록을 제공하는 라벨을 CSV(클러스터 서비스 버전)에 추가할 수 있습니다. 지원되는 아키텍처 및 운영 체제를 나타내는 라벨은 다음과 같이 정의합니다.
labels:
operatorframework.io/arch.<arch>: supported 1
operatorframework.io/os.<os>: supported 2
패키지 매니페스트를 라벨별로 필터링하는 경우 기본 채널의 채널 헤드에 있는 라벨만 사용됩니다. 예를 들어 기본이 아닌 채널에서 Operator에 추가 아키텍처를 제공할 수는 있지만 이러한 아키텍처는 PackageManifest API에서 필터링하는 데는 사용할 수 없습니다.
CSV에 os 라벨이 포함되지 않은 경우 기본적으로 다음 Linux 지원 라벨이 있는 것처럼 처리됩니다.
labels:
operatorframework.io/os.linux: supported
CSV에 arch 라벨이 포함되지 않은 경우 기본적으로 다음 AMD64 지원 라벨이 있는 것처럼 처리됩니다.
labels:
operatorframework.io/arch.amd64: supportedOperator에서 여러 개의 노드 아키텍처 또는 운영 체제를 지원하는 경우 라벨을 여러 개 추가할 수 있습니다.
사전 요구 사항
- Operator 프로젝트에 CSV가 포함되어 있습니다.
- 여러 아키텍처 및 운영 체제를 나열하기 위해서는 CSV에서 참조하는 Operator 이미지가 매니페스트 목록 이미지여야 합니다.
- Operator가 제한된 네트워크 또는 연결이 끊긴 환경에서 제대로 작동하려면 참조하는 이미지도 태그가 아닌 다이제스트(SHA)를 사용하여 지정해야 합니다.
프로세스
Operator에서 지원하는 각 지원 아키텍처 및 운영 체제에 대해 CSV의
metadata.labels에 라벨을 추가합니다.labels: operatorframework.io/arch.s390x: supported operatorframework.io/os.zos: supported operatorframework.io/os.linux: supported 1 operatorframework.io/arch.amd64: supported 2
추가 리소스
- 매니페스트 목록에 대한 자세한 내용은 Image Manifest V 2, Schema 2 사양을 참조하십시오.
5.7.4.1. Operator에 대한 아키텍처 및 운영 체제 지원
여러 아키텍처 및 운영 체제를 지원하는 Operator에 라벨을 지정하거나 해당 Operator를 필터링할 때는 OpenShift Container Platform의 OLM(Operator Lifecycle Manager)에서 다음 문자열이 지원됩니다.
표 5.10. OpenShift Container Platform에서 지원되는 아키텍처
| 아키텍처 | 문자열 |
|---|---|
| AMD64 |
|
| 64비트 PowerPC little-endian |
|
| IBM Z |
|
표 5.11. OpenShift Container Platform에서 지원되는 운영 체제
| 운영 체제 | 문자열 |
|---|---|
| Linux |
|
| z/OS |
|
다른 버전의 OpenShift Container Platform 및 기타 Kubernetes 기반 배포에서는 다른 아키텍처 및 운영 체제를 지원할 수 있습니다.
5.7.5. 제안된 네임스페이스 설정
일부 Operator는 특정 네임스페이스에 배포하거나 특정 네임스페이스에 보조 리소스가 있어야 제대로 작동합니다. 서브스크립션에서 확인된 경우 OLM(Operator Lifecycle Manager)은 기본적으로 Operator의 네임스페이스 리소스를 해당 서브스크립션의 네임스페이스로 설정합니다.
Operator 작성자는 원하는 대상 네임스페이스를 CSV(클러스터 서비스 버전)의 일부로 표시하여 Operator용으로 설치된 리소스의 최종 네임스페이스를 제어할 수 있습니다. OperatorHub를 사용하여 클러스터에 Operator를 추가하면 설치 프로세스 중 웹 콘솔에서 클러스터 관리자에게 제안된 네임스페이스를 자동으로 채울 수 있습니다.
프로세스
CSV에서
operatorframework.io/suggested-namespace주석을 제안된 네임스페이스로 설정합니다.metadata: annotations: operatorframework.io/suggested-namespace: <namespace> 1- 1
- 제안된 네임스페이스를 설정합니다.
5.7.6. Operator 조건 활성화
OLM(Operator Lifecycle Manager)에서는 Operator에 Operator를 관리하는 동안 OLM 동작에 영향을 미치는 복잡한 상태를 보고하는 채널을 제공합니다. 기본적으로 OLM은 Operator를 설치할 때 OperatorCondition CRD(사용자 정의 리소스 정의)를 생성합니다. OperatorCondition CR(사용자 정의)에 설정된 조건에 따라 OLM의 동작이 적절하게 변경됩니다.
Operator 조건을 지원하려면 Operator가 OLM에서 생성한 OperatorCondition CR을 읽고 다음 작업을 완료할 수 있어야 합니다.
- 특정 조건을 가져옵니다.
- 특정 조건의 상태를 설정합니다.
이 작업은 operator-lib 라이브러리를 사용하여 수행할 수 있습니다. Operator 작성자는 라이브러리에서 클러스터의 Operator 보유 OperatorCondition CR에 액세스할 수 있도록 Operator에 controller-runtime 클라이언트를 제공할 수 있습니다.
라이브러리에서는 일반 Conditions 인터페이스를 제공합니다. 이 인터페이스는 OperatorCondition CR에서 다음과 같은 방법으로 conditionType을 Get 및 Set합니다.
Get-
라이브러리는 특정 조건을 가져오기 위해
controller-runtime의client.Get함수를 사용합니다. 이 함수에는conditionAccessor에 있는types.NamespacedName유형의ObjectKey가 필요합니다. Set-
특정 조건의 상태를 업데이트하기 위해 라이브러리는
controller-runtime의client.Update함수를 사용합니다.conditionType이 CRD에 없으면 오류가 발생합니다.
Operator는 CR의 status 하위 리소스만 수정할 수 있습니다. Operator는 조건을 포함하도록 status.conditions 어레이를 삭제하거나 업데이트할 수 있습니다. 조건에 있는 필드의 형식 및 설명에 대한 자세한 내용은 업스트림 조건 GoDocs를 참조하십시오.
Operator SDK v1.8.0은 operator-lib v0.3.0을 지원합니다.
사전 요구 사항
- Operator SDK를 사용하여 생성한 Operator 프로젝트입니다.
프로세스
Operator 프로젝트에서 Operator 조건을 활성화하려면 다음을 수행합니다.
Operator 프로젝트의
go.mod파일에operator-framework/operator-lib을 필수 라이브러리로 추가합니다.module github.com/example-inc/memcached-operator go 1.15 require ( k8s.io/apimachinery v0.19.2 k8s.io/client-go v0.19.2 sigs.k8s.io/controller-runtime v0.7.0 operator-framework/operator-lib v0.3.0 )
Operator 논리에 다음과 같은 결과가 발생하는 자체 생성자를 작성합니다.
-
controller-runtime클라이언트를 허용합니다. -
conditionType을 허용합니다. -
Condition인터페이스를 반환하여 조건을 업데이트하거나 추가합니다.
OLM은 현재
Upgradeable조건을 지원하므로Upgradeable조건에 액세스할 수 있는 인터페이스를 생성할 수 있습니다. 예를 들면 다음과 같습니다.import ( ... apiv1 "github.com/operator-framework/api/pkg/operators/v1" ) func NewUpgradeable(cl client.Client) (Condition, error) { return NewCondition(cl, "apiv1.OperatorUpgradeable") } cond, err := NewUpgradeable(cl);이 예제에서는 유형
Condition의 변수cond를 생성하는 데NewUpgradeable생성자가 추가로 사용됩니다. 결국cond변수에는 OLMUpgradeable조건을 처리하는 데 사용할 수 있는Get및Set방법이 포함됩니다.-
추가 리소스
5.7.7. Webhook 정의
Operator 작성자는 Webhook를 통해 리소스를 오브젝트 저장소에 저장하고 Operator 컨트롤러에서 이를 처리하기 전에 리소스를 가로채기, 수정, 수락 또는 거부할 수 있습니다. Operator와 함께 webhook 가 제공 될 때 OLM (Operator Lifecycle Manager)은 이러한 Webhook의 라이프 사이클을 관리할 수 있습니다.
Operator의 CSV(클러스터 서비스 버전) 리소스에는 다음 유형의 Webhook를 정의하는 webhookdefinitions 섹션을 포함할 수 있습니다.
- 승인 Webhook(검증 및 변경)
- 변환 Webhook
프로세스
Operator CSV의
spec섹션에webhookdefinitions섹션을 추가하고ValidatingAdmissionWebhook,MutatingAdmissionWebhook또는ConversionWebhooktype을 사용하여 Webhook 정의를 포함합니다. 다음 예제에는 세 가지 유형의 Webhook가 모두 포함되어 있습니다.Webhook를 포함하는 CSV
apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: name: webhook-operator.v0.0.1 spec: customresourcedefinitions: owned: - kind: WebhookTest name: webhooktests.webhook.operators.coreos.io 1 version: v1 install: spec: deployments: - name: webhook-operator-webhook ... ... ... strategy: deployment installModes: - supported: false type: OwnNamespace - supported: false type: SingleNamespace - supported: false type: MultiNamespace - supported: true type: AllNamespaces webhookdefinitions: - type: ValidatingAdmissionWebhook 2 admissionReviewVersions: - v1beta1 - v1 containerPort: 443 targetPort: 4343 deploymentName: webhook-operator-webhook failurePolicy: Fail generateName: vwebhooktest.kb.io rules: - apiGroups: - webhook.operators.coreos.io apiVersions: - v1 operations: - CREATE - UPDATE resources: - webhooktests sideEffects: None webhookPath: /validate-webhook-operators-coreos-io-v1-webhooktest - type: MutatingAdmissionWebhook 3 admissionReviewVersions: - v1beta1 - v1 containerPort: 443 targetPort: 4343 deploymentName: webhook-operator-webhook failurePolicy: Fail generateName: mwebhooktest.kb.io rules: - apiGroups: - webhook.operators.coreos.io apiVersions: - v1 operations: - CREATE - UPDATE resources: - webhooktests sideEffects: None webhookPath: /mutate-webhook-operators-coreos-io-v1-webhooktest - type: ConversionWebhook 4 admissionReviewVersions: - v1beta1 - v1 containerPort: 443 targetPort: 4343 deploymentName: webhook-operator-webhook generateName: cwebhooktest.kb.io sideEffects: None webhookPath: /convert conversionCRDs: - webhooktests.webhook.operators.coreos.io 5 ...
추가 리소스
- 웹 후크 승인 플러그인의 유형
Kubernetes 설명서:
5.7.7.1. OLM의 Webhook 고려 사항
OLM(Operator Lifecycle Manager)을 사용하여 Operator를 Webhook와 함께 배포할 때는 다음을 정의해야 합니다.
-
type필드는ValidatingAdmissionWebhook,MutatingAdmissionWebhook또는ConversionWebhook중 하나로 설정해야 합니다. 그러지 않으면 CSV가 실패한 단계에 배치됩니다. -
CSV에는
webhookdefinition의deploymentName필드에 제공된 값과 이름이 같은 배포가 포함되어야 합니다.
Webhook가 생성되면 OLM은 Operator가 배포된 Operator group과 일치하는 네임스페이스에서만 Webhook가 작동하는지 확인합니다.
인증 기관 제약 조건
OLM은 각 배포에 하나의 CA(인증 기관)를 제공하도록 구성되어 있습니다. 배포에 CA를 생성하고 마운트하는 논리는 원래 API 서비스 라이프사이클 논리에 사용되었습니다. 결과는 다음과 같습니다.
-
TLS 인증서 파일이 배포에 마운트됩니다(
/apiserver.local.config/certificates/apiserver.crt). -
TLS 키 파일이 배포에 마운트됩니다(
/apiserver.local.config/certificates/apiserver.key).
승인 Webhook 규칙 제약 조건
Operator에서 클러스터를 복구할 수 없는 상태로 구성하는 것을 방지하기 위해 OLM은 승인 Webhook에 정의된 규칙에서 다음 요청을 가로채는 경우 CSV를 실패한 단계에 배치합니다.
- 모든 그룹을 대상으로 하는 요청
-
operators.coreos.com그룹을 대상으로 하는 요청 -
ValidatingWebhookConfigurations또는MutatingWebhookConfigurations리소스를 대상으로 하는 요청
변환 Webhook 제약 조건
OLM은 변환 Webhook 정의가 다음 제약 조건을 준수하지 않는 경우 CSV를 실패한 단계에 배치합니다.
-
변환 Webhook가 있는 CSV는
AllNamespaces설치 모드만 지원할 수 있습니다. -
변환 Webhook에서 대상으로 하는 CRD는
spec.preserveUnknownFields필드가false또는nil로 설정되어 있어야 합니다. - CSV에 정의된 변환 Webhook는 고유한 CRD를 대상으로 해야 합니다.
- 지정된 CRD의 전체 클러스터에는 하나의 변환 Webhook만 있을 수 있습니다.
5.7.8. CRD(사용자 정의 리소스 정의) 이해
Operator에서 사용할 수 있는 CRD(사용자 정의 리소스 정의)에는 두 가지 유형이 있습니다. 하나는 보유 CRD이고 다른 하나는 의존하는 필수 CRD입니다.
5.7.8.1. 보유 CRD
Operator가 보유한 CRD(사용자 정의 리소스 정의)는 CSV에서 가장 중요한 부분입니다. 이를 통해 Operator와 필수 RBAC 규칙, 종속성 관리 및 기타 Kubernetes 개념 간 관계가 설정됩니다.
Operator는 여러 CRD를 사용하여 개념을 함께 연결하는 것이 일반적입니다(한 오브젝트의 최상위 데이터베이스 구성 및 다른 오브젝트의 복제본 세트 표현 등). 각각은 CSV 파일에 나열되어야 합니다.
표 5.12. 보유 CRD 필드
| 필드 | Description | 필수/선택 사항 |
|---|---|---|
|
| CRD의 전체 이름입니다. | 필수 항목 |
|
| 해당 오브젝트 API의 버전입니다. | 필수 항목 |
|
| 머신에서 읽을 수 있는 CRD 이름입니다. | 필수 항목 |
|
|
사람이 읽을 수 있는 버전의 CRD 이름입니다(예: | 필수 항목 |
|
| Operator에서 이 CRD를 사용하는 방법에 대한 간단한 설명 또는 CRD에서 제공하는 기능에 대한 설명입니다. | 필수 항목 |
|
|
이 CRD가 속하는 API 그룹입니다(예: | 선택 사항 |
|
|
CRD에는 하나 이상의 Kubernetes 오브젝트 유형이 있습니다. 이러한 항목은 오케스트레이션하는 모든 항목의 전체 목록이 아닌, 사용자에게 중요한 오브젝트만 나열하는 것이 좋습니다. 예를 들어 사용자가 수정할 수 없는 내부 상태를 저장하는 구성 맵은 나열하지 않도록 합니다. | 선택 사항 |
|
| 이러한 설명자는 Operator의 특정 입력 또는 출력에서 최종 사용자에게 가장 중요한 UI를 나타내는 방법입니다. CRD에 사용자가 제공해야 하는 보안 또는 구성 맵의 이름이 있는 경우 여기에서 지정할 수 있습니다. 이러한 항목은 호환되는 UI에서 연결되고 강조됩니다. 설명자에는 세 가지 유형이 있습니다.
모든 설명자에는 다음 필드를 사용할 수 있습니다.
일반적으로 설명자에 대한 자세한 내용은 openshift/console 프로젝트를 참조하십시오. | 선택 사항 |
다음 예제에서는 보안 및 구성 맵의 형태로 일부 사용자 입력이 필요하고 서비스, 상태 저장 세트, Pod, 구성 맵을 오케스트레이션하는 MongoDB Standalone CRD를 보여줍니다.
보유 CRD의 예
- displayName: MongoDB Standalone
group: mongodb.com
kind: MongoDbStandalone
name: mongodbstandalones.mongodb.com
resources:
- kind: Service
name: ''
version: v1
- kind: StatefulSet
name: ''
version: v1beta2
- kind: Pod
name: ''
version: v1
- kind: ConfigMap
name: ''
version: v1
specDescriptors:
- description: Credentials for Ops Manager or Cloud Manager.
displayName: Credentials
path: credentials
x-descriptors:
- 'urn:alm:descriptor:com.tectonic.ui:selector:core:v1:Secret'
- description: Project this deployment belongs to.
displayName: Project
path: project
x-descriptors:
- 'urn:alm:descriptor:com.tectonic.ui:selector:core:v1:ConfigMap'
- description: MongoDB version to be installed.
displayName: Version
path: version
x-descriptors:
- 'urn:alm:descriptor:com.tectonic.ui:label'
statusDescriptors:
- description: The status of each of the pods for the MongoDB cluster.
displayName: Pod Status
path: pods
x-descriptors:
- 'urn:alm:descriptor:com.tectonic.ui:podStatuses'
version: v1
description: >-
MongoDB Deployment consisting of only one host. No replication of
data.
5.7.8.2. 필수 CRD
기타 필수 CRD에 의존하는 것은 전적으로 선택 사항이며 개별 Operator의 범위를 줄이고 여러 Operator를 함께 구성하여 종단 간 사용 사례를 해결하는 방법을 제공하기 위해서만 존재합니다.
이에 대한 예로는 애플리케이션을 설정하고 (etcd Operator에서) 분산형 잠금에 사용할 etcd 클러스터를 설치하고, 데이터 저장을 위해 (Postgres Operator에서) Postgres 데이터베이스를 설치할 수 있는 Operator가 있습니다.
OLM(Operator Lifecycle Manager)은 이러한 요구 사항을 충족하기 위해 클러스터에서 사용 가능한 CRD 및 Operator를 점검합니다. 적합한 버전이 있는 경우 Operator는 원하는 네임스페이스 내에서 시작되고 각 Operator에서 필요한 Kubernetes 리소스를 생성, 조사, 수정할 수 있도록 서비스 계정이 생성됩니다.
표 5.13. 필수 CRD 필드
| 필드 | Description | 필수/선택 사항 |
|---|---|---|
|
| 필요한 CRD의 전체 이름입니다. | 필수 항목 |
|
| 해당 오브젝트 API의 버전입니다. | 필수 항목 |
|
| Kubernetes 오브젝트 종류입니다. | 필수 항목 |
|
| 사람이 읽을 수 있는 CRD 버전입니다. | 필수 항목 |
|
| 구성 요소가 더 큰 아키텍처에 어떻게 적용되는지 요약합니다. | 필수 항목 |
필수 CRD 예제
required:
- name: etcdclusters.etcd.database.coreos.com
version: v1beta2
kind: EtcdCluster
displayName: etcd Cluster
description: Represents a cluster of etcd nodes.
5.7.8.3. CRD 업그레이드
OLM은 CRD(사용자 정의 리소스 정의)가 단수형 CSV(클러스터 서비스 버전)에 속하는 경우 CRD를 즉시 업그레이드합니다. CRD가 여러 CSV에 속하는 경우에는 다음과 같은 하위 호환 조건을 모두 충족할 때 CRD가 업그레이드됩니다.
- 현재 CRD의 기존 서비스 버전은 모두 새 CRD에 있습니다.
- CRD 제공 버전과 연결된 기존의 모든 인스턴스 또는 사용자 정의 리소스는 새 CRD의 검증 스키마에 대해 검증할 때 유효합니다.
5.7.8.3.1. 새 CRD 버전 추가
프로세스
Operator에 새 버전의 CRD를 추가하려면 다음을 수행합니다.
CSV의
versions섹션에서 CRD 리소스에 새 항목을 추가합니다.예를 들어 현재 CRD에 버전
v1alpha1이 있고, 새 버전v1beta1을 추가한 후 새 스토리지 버전으로 표시하려면v1beta1에 새 항목을 추가합니다.versions: - name: v1alpha1 served: true storage: false - name: v1beta1 1 served: true storage: true- 1
- 새 항목입니다.
CSV에서 새 버전을 사용하려고 하는 경우 CSV의
owned섹션에 있는 CRD의 참조 버전이 업데이트되었는지 확인합니다.customresourcedefinitions: owned: - name: cluster.example.com version: v1beta1 1 kind: cluster displayName: Cluster- 1
version을 업데이트합니다.
- 업데이트된 CRD 및 CSV를 번들로 내보냅니다.
5.7.8.3.2. CRD 버전 사용 중단 또는 제거
OLM(Operator Lifecycle Manager)에서는 CRD(사용자 정의 리소스 정의)의 제공 버전을 즉시 제거하는 것을 허용하지 않습니다. 대신 CRD의 served 필드를 false로 설정하여 더 이상 사용되지 않는 CRD 버전을 먼저 비활성화해야 합니다. 그러면 후속 CRD 업그레이드에서 제공되지 않는 버전을 제거할 수 있습니다.
프로세스
특정 버전의 CRD를 사용 중단하고 제거하려면 다음을 수행합니다.
이 버전이 더 이상 사용되지 않으며 후속 업그레이드에서 제거될 수 있음을 나타내려면 더 이상 사용되지 않는 버전을 제공되지 않음으로 표시합니다. 예를 들면 다음과 같습니다.
versions: - name: v1alpha1 served: false 1 storage: true- 1
false로 설정합니다.
사용을 중단할 버전이 현재
storage버전인 경우storage버전을 제공 버전으로 전환합니다. 예를 들면 다음과 같습니다.versions: - name: v1alpha1 served: false storage: false 1 - name: v1beta1 served: true storage: true 2참고CRD에서
storage버전이거나 이 버전이었던 특정 버전을 제거하려면 CRD 상태의storedVersion에서 해당 버전을 제거해야 합니다. OLM은 저장된 버전이 새 CRD에 더 이상 존재하지 않는 것으로 탐지하면 이 작업을 수행합니다.- 위 변경 사항으로 CRD를 업그레이드합니다.
이어지는 업그레이드 주기에서는 서비스되지 않는 버전을 CRD에서 완전히 제거할 수 있습니다. 예를 들면 다음과 같습니다.
versions: - name: v1beta1 served: true storage: true-
CSV의
owned섹션에서 참조하는 CRD 버전이 CRD에서 제거된 경우 적절하게 업데이트되었는지 확인합니다.
5.7.8.4. CRD 템플릿
Operator 사용자는 필수 옵션과 선택 옵션을 알고 있어야 합니다. 각 CRD(사용자 정의 리소스 정의)에 대한 템플릿에 alm-examples라는 주석으로 최소 구성 세트를 제공할 수 있습니다. 사용자가 추가로 사용자 정의할 수 있도록 호환되는 UI가 이 템플릿에 미리 채워집니다.
주석은 종류 목록으로 구성되며, 예를 들면 CRD 이름 및 Kubernetes 오브젝트의 해당 metadata 및 spec입니다.
다음 전체 예제에서는 EtcdCluster, EtcdBackup, EtcdRestore에 대한 템플릿을 제공합니다.
metadata:
annotations:
alm-examples: >-
[{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdCluster","metadata":{"name":"example","namespace":"default"},"spec":{"size":3,"version":"3.2.13"}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdRestore","metadata":{"name":"example-etcd-cluster"},"spec":{"etcdCluster":{"name":"example-etcd-cluster"},"backupStorageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}},{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdBackup","metadata":{"name":"example-etcd-cluster-backup"},"spec":{"etcdEndpoints":["<etcd-cluster-endpoints>"],"storageType":"S3","s3":{"path":"<full-s3-path>","awsSecret":"<aws-secret>"}}}]5.7.8.5. 내부 오브젝트 숨기기
Operator는 작업을 수행하기 위해 내부적으로 CRD(사용자 정의 리소스 정의)를 사용하는 것이 일반적입니다. 이러한 오브젝트는 사용자 조작용이 아니며 Operator 사용자에게 혼동을 줄 수 있습니다. 예를 들어 데이터베이스 Operator에는 사용자가 replication: true를 사용하여 데이터베이스 오브젝트를 생성할 때마다 생성되는 Replication CRD가 있을 수 있습니다.
Operator 작성자는 operators.operatorframework.io/internal-objects 주석을 Operator의 CSV(클러스터 서비스 버전)에 추가하여 사용자 조작용이 아닌 사용자 인터페이스에서 CRD를 숨길 수 있습니다.
프로세스
-
CRD 중 하나를 내부로 표시하기 전에 애플리케이션을 관리하는 데 필요할 수 있는 디버깅 정보 또는 구성이 CR의 상태 또는
spec블록에 반영되는지 확인합니다(Operator에 적용 가능한 경우). operators.operatorframework.io/internal-objects주석을 Operator의 CSV에 추가하여 사용자 인터페이스에서 숨길 내부 오브젝트를 지정합니다.내부 오브젝트 주석
apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: name: my-operator-v1.2.3 annotations: operators.operatorframework.io/internal-objects: '["my.internal.crd1.io","my.internal.crd2.io"]' 1 ...- 1
- 내부 CRD를 문자열 배열로 설정합니다.
5.7.8.6. 필수 사용자 정의 리소스 초기화
Operator가 완전히 작동하기 위해서는 사용자가 사용자 정의 리소스를 인스턴스화해야 할 수 있습니다. 그러나 사용자가 필요한 내용과 리소스를 정의하는 방법을 결정하는 것이 어려울 수 있습니다.
Operator 개발자는 Operator 설치 중에 operatorframework.io/initialization-resource 를 CSV(클러스터 서비스 버전)에 추가하여 필요한 단일 사용자 정의 리소스를 지정할 수 있습니다. 그런 다음 CSV에 제공된 템플릿을 통해 사용자 정의 리소스를 생성하라는 메시지가 표시됩니다. 주석에는 설치 중 리소스를 초기화하는 데 필요한 전체 YAML 정의가 포함된 템플릿이 포함되어야 합니다.
OpenShift Container Platform 웹 콘솔에서 Operator를 설치한 후 이 주석을 정의한 경우 사용자에게 CSV에 제공된 템플릿을 사용하여 리소스를 생성하라는 메시지가 표시됩니다.
프로세스
Operator의 CSV에
operatorframework.io/initialization-resource주석을 추가하여 필요한 사용자 정의 리소스를 지정합니다. 예를 들어 다음 주석은StorageCluster리소스 생성이 필요하고 전체 YAML 정의를 제공합니다.초기화 리소스 주석
apiVersion: operators.coreos.com/v1alpha1 kind: ClusterServiceVersion metadata: name: my-operator-v1.2.3 annotations: operatorframework.io/initialization-resource: |- { "apiVersion": "ocs.openshift.io/v1", "kind": "StorageCluster", "metadata": { "name": "example-storagecluster" }, "spec": { "manageNodes": false, "monPVCTemplate": { "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "10Gi" } }, "storageClassName": "gp2" } }, "storageDeviceSets": [ { "count": 3, "dataPVCTemplate": { "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "1Ti" } }, "storageClassName": "gp2", "volumeMode": "Block" } }, "name": "example-deviceset", "placement": {}, "portable": true, "resources": {} } ] } } ...
5.7.9. API 서비스 이해
CRD와 마찬가지로 Operator에서 사용할 수 있는 API 서비스에는 두 가지 유형, 즉 보유 및 필수가 있습니다.
5.7.9.1. 보유 API 서비스
API 서비스가 CSV에 속하는 경우 CSV는 해당 서비스를 지원하는 확장 api-server 및 해당 서비스에서 제공하는 GVK(그룹/버전/종류)의 배포에 대해 설명해야 합니다.
API 서비스는 제공하는 그룹/버전별로 고유하게 식별되며 제공할 것으로 예상되는 다양한 종류를 나타내기 위해 여러 번 나열될 수 있습니다.
표 5.14. 보유 API 서비스 필드
| 필드 | Description | 필수/선택 사항 |
|---|---|---|
|
|
API 서비스에서 제공하는 그룹입니다(예: | 필수 항목 |
|
|
API 서비스의 버전입니다(예: | 필수 항목 |
|
| API 서비스에서 제공해야 하는 종류입니다. | 필수 항목 |
|
| 제공되는 API 서비스의 복수형 이름입니다. | 필수 항목 |
|
|
CSV에서 정의한 배포 이름으로, API 서비스에 해당합니다(보유 API 서비스의 경우 필수). OLM Operator는 CSV 보류 단계 동안 CSV의 | 필수 항목 |
|
|
사람이 읽을 수 있는 버전의 API 서비스 이름입니다(예: | 필수 항목 |
|
| Operator에서 이 API 서비스를 사용하는 방법에 대한 간단한 설명 또는 API 서비스에서 제공하는 기능에 대한 설명입니다. | 필수 항목 |
|
| 사용 중인 API 서비스에서 Kubernetes 오브젝트 유형을 한 개 이상 보유하고 있습니다. 이러한 항목은 resources 섹션에 나열되어 문제 해결에 필요할 수 있는 오브젝트 또는 애플리케이션에 연결하는 방법을 사용자에게 알립니다(예: 데이터베이스를 표시하는 서비스 또는 수신 규칙). 오케스트레이션하는 모든 항목의 전체 목록이 아닌, 사용자에게 중요한 오브젝트만 나열하는 것이 좋습니다. 예를 들어 사용자가 수정할 수 없는 내부 상태를 저장하는 구성 맵은 나열하지 않도록 합니다. | 선택 사항 |
|
| 본질적으로 보유 CRD와 동일합니다. | 선택 사항 |
5.7.9.1.1. API 서비스 리소스 생성
OLM(Operator Lifecycle Manager)은 각각의 고유한 보유 API 서비스에 대해 서비스 및 API 서비스 리소스를 생성하거나 교체합니다.
-
서비스 Pod 선택기는 API 서비스 설명의
DeploymentName필드와 일치하는 CSV 배포에서 복사합니다. - 각 설치에 대해 새 CA 키/인증서 쌍이 생성되고 base64로 인코딩된 CA 번들이 각 API 서비스 리소스에 포함됩니다.
5.7.9.1.2. API 서비스 제공 인증서
OLM은 보유 API 서비스가 설치될 때마다 제공 키/인증서 쌍을 생성합니다. 제공 인증서에는 생성된 Service 리소스의 호스트 이름을 포함하는 CN(일반 이름)이 있으며 해당 API 서비스 리소스에 포함된 CA 번들의 개인 키로 서명합니다.
인증서는 배포 네임스페이스에 유형 kubernetes.io/tls의 보안으로 저장되고 API 서비스 설명의 DeploymentName 필드와 일치하는 CSV의 배포 볼륨 섹션에 apiservice-cert라는 볼륨이 자동으로 추가됩니다.
아직 존재하지 않는 경우 이름이 일치하는 볼륨 마운트도 해당 배포의 모든 컨테이너에 추가됩니다. 그러면 사용자가 필요한 이름으로 볼륨 마운트를 정의하여 모든 사용자 정의 경로 요구 사항을 충족할 수 있습니다. 생성된 볼륨 마운트의 경로는 기본적으로 /apiserver.local.config/certificates이며 동일한 경로의 기존 볼륨 마운트는 교체됩니다.
5.7.9.2. 필수 API 서비스
OLM은 설치를 시도하기 전에 모든 필수 CSV에 사용 가능한 API 서비스가 있고 필요한 GVK를 모두 검색할 수 있는지 확인합니다. 이를 통해 CSV는 보유하지 않는 API 서비스에서 제공하는 특정 종류에 의존할 수 있습니다.
표 5.15. 필수 API 서비스 필드
| 필드 | Description | 필수/선택 사항 |
|---|---|---|
|
|
API 서비스에서 제공하는 그룹입니다(예: | 필수 항목 |
|
|
API 서비스의 버전입니다(예: | 필수 항목 |
|
| API 서비스에서 제공해야 하는 종류입니다. | 필수 항목 |
|
|
사람이 읽을 수 있는 버전의 API 서비스 이름입니다(예: | 필수 항목 |
|
| Operator에서 이 API 서비스를 사용하는 방법에 대한 간단한 설명 또는 API 서비스에서 제공하는 기능에 대한 설명입니다. | 필수 항목 |
