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 명령을 제공합니다.

  1. generate kustomize manifests
  2. generate bundle
  3. 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. 필수 항목
필드설명

metadata.name

이 CSV의 고유 이름입니다. 고유성을 유지하도록 이름에 Operator 버전이 포함되어야 합니다(예: app-operator.v0.1.1).

metadata.capabilities

Operator 완성 모델에 따른 기능 수준입니다. 옵션에는 Basic Install, Seamless Upgrades, Full Lifecycle, Deep Insights, Auto Pilot이 있습니다.

spec.displayName

Operator를 확인하는 공용 이름입니다.

spec.description

Operator 기능에 대한 간단한 설명입니다.

spec.keywords

Operator를 설명하는 키워드입니다.

spec.maintainers

nameemail을 사용하여 Operator를 유지 관리하는 사람 또는 조직 엔티티입니다.

spec.provider

name이 있는 Operator의 공급자입니다(일반적으로 조직).

spec.labels

Operator 내부에서 사용할 키-값 쌍입니다.

spec.version

Operator의 의미 체계 버전입니다(예: 0.1.1).

spec.customresourcedefinitions

Operator에서 사용하는 모든 CRD입니다. CRD YAML 파일이 deploy/에 있는 경우 이 필드는 Operator SDK에 의해 자동으로 채워집니다. 그러나 CRD 매니페스트 사양에 없는 몇몇 필드에는 사용자 입력이 필요합니다.

  • description: CRD 설명입니다.
  • resources: CRD에서 활용하는 모든 Kubernetes 리소스입니다(예: PodStatefulSet 오브젝트).
  • specDescriptors: Operator의 입력 및 출력에 대한 UI 힌트입니다.
표 5.8. 선택 사항
필드설명

spec.replaces

CSV 이름이 이 CSV로 교체됩니다.

spec.links

Operator 또는 애플리케이션과 관련된 URL(예: 웹 사이트 및 문서)을 각각 nameurl을 사용하여 관리합니다.

spec.selector

Operator에서 클러스터의 리소스와 연결할 수 있는 선택기입니다.

spec.icon

Operator 고유의 base64로 인코딩된 아이콘으로, mediatype을 사용하여 base64data 필드에 설정됩니다.

spec.maturity

이 버전의 소프트웨어에서 달성한 완성 수준입니다. 옵션에는 planning, pre-alpha, alpha, beta, stable, mature, inactive, deprecated가 포함됩니다.

위의 각 필드에 보관해야 하는 데이터에 대한 자세한 내용은 CSV 사양에서 확인할 수 있습니다.

참고

현재 사용자 개입이 필요한 여러 YAML 필드를 Operator 코드에서 구문 분석할 수 있습니다.

추가 리소스

5.7.2.1. Operator 메타데이터 주석

Operator 개발자는 CSV(클러스터 서비스 버전) 메타데이터에 특정 주석을 수동으로 정의하여 OperatorHub와 같은 UI의 기능을 활성화하거나 성능을 강조할 수 있습니다.

다음 테이블에는 metadata.annotations 필드를 사용하여 수동으로 정의할 수 있는 Operator 메타데이터 주석이 나열되어 있습니다.

표 5.9. 주석
필드설명

alm-examples

CRD(사용자 정의 리소스 정의) 템플릿에 최소 구성 세트를 제공합니다. 사용자가 추가로 사용자 정의할 수 있도록 호환되는 UI가 이 템플릿에 미리 채워집니다.

operatorframework.io/initialization-resource

Operator 설치 중에 operatorframework.io/initialization-resource 주석을 CSV(클러스터 서비스 버전)에 추가하여 단일 필수 사용자 정의 리소스를 지정합니다. 그런 다음 CSV에 제공된 템플릿을 통해 사용자 정의 리소스를 생성하라는 메시지가 표시됩니다. 전체 YAML 정의를 포함하는 템플릿을 포함해야 합니다.

operatorframework.io/suggested-namespace

Operator를 배포해야 하는 제안된 네임스페이스를 설정합니다.

operators.openshift.io/infrastructure-features

Operator에서 지원하는 인프라 기능입니다. 사용자는 웹 콘솔에서 OperatorHub를 통해 Operator를 검색할 때 이러한 기능을 확인하고 필터링할 수 있습니다. 유효한 대소문자를 구분하는 값은 다음과 같습니다.

  • disconnected: Operator는 모든 종속성을 포함하여 연결이 끊긴 카탈로그로 미러링되며 인터넷 액세스가 필요하지 않습니다. Operator에서 미러링에 필요한 모든 관련 이미지를 나열합니다.
  • CNF: Operator는 CNF(클라우드 네이티브 네트워크 기능) Kubernetes 플러그인을 제공합니다.
  • CNI : Operator는 CNI(Container Network Interface) Kubernetes 플러그인을 제공합니다.
  • CSI: Operator는 CSI(Container Storage Interface) Kubernetes 플러그인을 제공합니다.
  • FIPS: Operator는 기본 플랫폼의 FIPS 모드를 허용하고 FIPS 모드로 부팅되는 노드에서 작동합니다.
중요

FIPS 검증 또는 모듈 In Process 암호화 라이브러리 사용은 x86_64,ppc64les390x 아키텍처의 OpenShift Container Platform 배포에서만 지원됩니다.

  • proxy-aware: Operator는 프록시 뒤의 클러스터에서 실행을 지원합니다. Operator는 클러스터가 프록시를 사용하도록 구성된 경우 OLM(Operator Lifecycle Manager)에서 Operator에 자동으로 제공하는 표준 프록시 환경 변수 HTTP_PROXYHTTPS_PROXY를 허용합니다. 필수 환경 변수는 관리되는 워크로드의 Operand로 전달됩니다.

operators.openshift.io/valid-subscription

Operator를 사용하는 데 필요한 특정 서브스크립션을 나열하기 위한 자유 양식 어레이입니다. 예를 들면 '["3Scale Commercial License", "Red Hat Managed Integration"]'입니다.

operators.operatorframework.io/internal-objects

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에 클러스터 외부 리소스가 필요하지 않아야 합니다.

사전 요구 사항

  • Operator 프로젝트에 CSV가 포함되어 있습니다. 다음 절차에서는 Memcached Operator를 Go-, Ansible- 및 Helm 기반 프로젝트의 예로 사용합니다.

프로세스

  1. config/manager/manager.yaml 파일에서 Operator에서 사용하는 추가 이미지 참조에 대한 환경 변수를 설정합니다.

    예 5.10. config/manager/manager.yaml 파일 예

    ...
    spec:
      ...
        spec:
          ...
          containers:
          - command:
            - /manager
            ...
            env:
            - name: <related_image_environment_variable> 1
              value: "<related_image_reference_with_tag>" 2
    1
    RELATED_IMAGE_MEMCACHED 와 같은 환경 변수를 정의합니다.
    2
    docker.io/memcached:1.4.36-alpine 과 같은 관련 이미지 참조 및 태그를 설정합니다.
  2. 하드 코딩된 이미지 참조를 Operator 프로젝트 유형의 관련 파일에서 환경 변수로 교체합니다.

    • Go 기반 Operator 프로젝트의 경우 다음 예와 같이 controllers/memcached_controller.go 파일에 환경 변수를 추가합니다.

      예 5.11. controllers/memcached_controller.go 파일의 예

        // deploymentForMemcached returns a memcached Deployment object
      
      ...
      
      	Spec: corev1.PodSpec{
              	Containers: []corev1.Container{{
      -			Image:   "memcached:1.4.36-alpine", 1
      +			Image:   os.Getenv("<related_image_environment_variable>"), 2
      			Name:    "memcached",
      			Command: []string{"memcached", "-m=64", "-o", "modern", "-v"},
      			Ports: []corev1.ContainerPort{{
      
      ...
      1
      이미지 참조 및 태그를 삭제합니다.
      2
      os.Getenv 함수를 사용하여 < related_image_environment_variable>을 호출합니다.
      참고

      os.Getenv 함수는 변수가 설정되지 않은 경우 빈 문자열을 반환합니다. 파일을 변경하기 전에 <related_image_environment_variable >을 설정합니다.

    • Ansible 기반 Operator 프로젝트의 경우 다음 예와 같이 roles/memcached/tasks/main.yml 파일에 환경 변수를 추가합니다.

      예 5.12. roles/memcached/tasks/main.yml 파일의 예

      spec:
        containers:
        - name: memcached
          command:
          - memcached
          - -m=64
          - -o
          - modern
          - -v
      -   image: "docker.io/memcached:1.4.36-alpine" 1
      +   image: "{{ lookup('env', '<related_image_environment_variable>') }}" 2
          ports:
            - containerPort: 11211
      
      ...
      1
      이미지 참조 및 태그를 삭제합니다.
      2
      lookup 함수를 사용하여 < related_image_environment_variable>을 호출합니다.
    • Helm 기반 Operator 프로젝트의 경우 다음 예와 같이 watches.yaml 파일에 overrideValues 필드를 추가합니다.

      예 5.13. watches.yaml 파일의 예

      ...
      - group: demo.example.com
        version: v1alpha1
        kind: Memcached
        chart: helm-charts/memcached
        overrideValues: 1
          relatedImage: ${<related_image_environment_variable>} 2
      1
      overrideValues 필드를 추가합니다.
      2
      RELATED_IMAGE_MEMCACHED 와 같이 < related_image_environment_variable >을 사용하여 overrideValues 필드를 정의합니다.
      1. 다음 예와 같이 overrideValues 필드의 값을 helm-charts/memchached/values.yaml 파일에 추가합니다.

        helm-charts/memchached/values.yaml 파일의 예

        ...
        relatedImage: ""

      2. 다음 예와 같이 helm-charts/memcached/templates/deployment.yaml 파일에서 차트 템플릿을 편집합니다.

        예 5.14. helm-charts/memcached/templates/deployment.yaml 파일의 예

        containers:
          - name: {{ .Chart.Name }}
            securityContext:
              - toYaml {{ .Values.securityContext | nindent 12 }}
            image: "{{ .Values.image.pullPolicy }}
            env: 1
              - name: related_image 2
                value: "{{ .Values.relatedImage }}" 3
        1
        env 필드를 추가합니다.
        2
        환경 변수의 이름을 지정합니다.
        3
        환경 변수의 값을 정의합니다.
  3. 다음 변경 사항으로 BUNDLE_GEN_FLAGS 변수 정의를 Makefile 에 추가합니다.

    Makefile의 예

       BUNDLE_GEN_FLAGS ?= -q --overwrite --version $(VERSION) $(BUNDLE_METADATA_OPTS)
    
       # USE_IMAGE_DIGESTS defines if images are resolved via tags or digests
       # You can enable this value if you would like to use SHA Based Digests
       # To enable set flag to true
       USE_IMAGE_DIGESTS ?= false
       ifeq ($(USE_IMAGE_DIGESTS), true)
             BUNDLE_GEN_FLAGS += --use-image-digests
       endif
    
    ...
    
    -  $(KUSTOMIZE) build config/manifests | operator-sdk generate bundle -q --overwrite --version $(VERSION) $(BUNDLE_METADATA_OPTS) 1
    +  $(KUSTOMIZE) build config/manifests | operator-sdk generate bundle $(BUNDLE_GEN_FLAGS) 2
    
    ...

    1
    Makefile 에서 이 행을 삭제합니다.
    2
    위의 행을 이 줄로 바꿉니다.
  4. 태그가 아닌 다이제스트(SHA)를 사용하도록 Operator 이미지를 업데이트하려면 make bundle 명령을 실행하고 USE_IMAGE_DIGESTStrue 로 설정합니다.

    $ make bundle USE_IMAGE_DIGESTS=true
  5. 연결이 끊긴 환경에서도 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
1
<arch>를 지원되는 문자열로 설정합니다.
2
<os>를 지원되는 문자열로 설정합니다.
참고

패키지 매니페스트를 라벨별로 필터링하는 경우 기본 채널의 채널 헤드에 있는 라벨만 사용됩니다. 예를 들어 기본이 아닌 채널에서 Operator에 추가 아키텍처를 제공할 수는 있지만 이러한 아키텍처는 PackageManifest API에서 필터링하는 데는 사용할 수 없습니다.

CSV에 os 라벨이 포함되지 않은 경우 기본적으로 다음 Linux 지원 라벨이 있는 것처럼 처리됩니다.

labels:
    operatorframework.io/os.linux: supported

CSV에 arch 라벨이 포함되지 않은 경우 기본적으로 다음 AMD64 지원 라벨이 있는 것처럼 처리됩니다.

labels:
    operatorframework.io/arch.amd64: supported

Operator에서 여러 개의 노드 아키텍처 또는 운영 체제를 지원하는 경우 라벨을 여러 개 추가할 수 있습니다.

사전 요구 사항

  • 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
    1 2
    새 아키텍처 또는 운영 체제를 추가한 후에는 기본 os.linuxarch.amd64 변형도 명시적으로 포함해야 합니다.

추가 리소스

5.7.4.1. Operator에 대한 아키텍처 및 운영 체제 지원

여러 아키텍처 및 운영 체제를 지원하는 Operator에 라벨을 지정하거나 해당 Operator를 필터링할 때는 OpenShift Container Platform의 OLM(Operator Lifecycle Manager)에서 다음 문자열이 지원됩니다.

표 5.10. OpenShift Container Platform에서 지원되는 아키텍처
아키텍처문자열

AMD64

amd64

IBM Power

ppc64le

IBM Z

s390x

표 5.11. OpenShift Container Platform에서 지원되는 운영 체제
운영 체제문자열

Linux

linux

z/OS

zos

참고

다른 버전의 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에서 다음과 같은 방법으로 conditionTypeGetSet합니다.

Get
라이브러리는 특정 조건을 가져오기 위해 controller-runtimeclient.Get 함수를 사용합니다. 이 함수에는 conditionAccessor에 있는 types.NamespacedName 유형의 ObjectKey가 필요합니다.
Set
특정 조건의 상태를 업데이트하기 위해 라이브러리는 controller-runtimeclient.Update 함수를 사용합니다. conditionType이 CRD에 없으면 오류가 발생합니다.

Operator는 CR의 status 하위 리소스만 수정할 수 있습니다. Operator는 조건을 포함하도록 status.conditions 어레이를 삭제하거나 업데이트할 수 있습니다. 조건에 있는 필드의 형식 및 설명에 대한 자세한 내용은 업스트림 조건 GoDocs를 참조하십시오.

참고

Operator SDK v1.10.1은 operator-lib v0.3.0을 지원합니다.

사전 요구 사항

  • Operator SDK를 사용하여 생성한 Operator 프로젝트입니다.

프로세스

Operator 프로젝트에서 Operator 조건을 활성화하려면 다음을 수행합니다.

  1. 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
    )
  2. 다음과 같은 결과를 초래할 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 변수에는 OLM Upgradeable 조건을 처리하는 데 사용할 수 있는 GetSet 방법이 포함됩니다.

추가 리소스

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 또는 ConversionWebhook type을 사용하여 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
    ...

    1
    변환 Webhook에서 대상으로 하는 CRD는 여기에 있어야 합니다.
    2
    검증 승인 Webhook입니다.
    3
    변경 승인 Webhook.
    4
    변환 Webhook입니다.
    5
    각 CRD의 spec.PreserveUnknownFields 속성을 false 또는 nil로 설정해야 합니다.

5.7.7.1. OLM의 Webhook 고려 사항

OLM(Operator Lifecycle Manager)을 사용하여 Operator를 Webhook와 함께 배포할 때는 다음을 정의해야 합니다.

  • type 필드는 ValidatingAdmissionWebhook, MutatingAdmissionWebhook 또는 ConversionWebhook 중 하나로 설정해야 합니다. 그러지 않으면 CSV가 실패한 단계에 배치됩니다.
  • CSV에는 webhookdefinitiondeploymentName 필드에 제공된 값과 이름이 같은 배포가 포함되어야 합니다.

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필수/선택 사항

Name

CRD의 전체 이름입니다.

필수 항목

Version

해당 오브젝트 API의 버전입니다.

필수 항목

Kind

머신에서 읽을 수 있는 CRD 이름입니다.

필수 항목

DisplayName

사람이 읽을 수 있는 버전의 CRD 이름입니다(예: MongoDB Standalone).

필수 항목

Description

Operator에서 이 CRD를 사용하는 방법에 대한 간단한 설명 또는 CRD에서 제공하는 기능에 대한 설명입니다.

필수 항목

Group

이 CRD가 속하는 API 그룹입니다(예: database.example.com).

선택 사항

Resources

CRD에는 하나 이상의 Kubernetes 오브젝트 유형이 있습니다. 이러한 항목은 resources 섹션에 나열되어 문제 해결에 필요할 수 있는 오브젝트 또는 애플리케이션에 연결하는 방법을 사용자에게 알립니다(예: 데이터베이스를 표시하는 서비스 또는 수신 규칙).

오케스트레이션하는 모든 항목의 전체 목록이 아닌, 사용자에게 중요한 오브젝트만 나열하는 것이 좋습니다. 예를 들어 사용자가 수정할 수 없는 내부 상태를 저장하는 구성 맵은 나열하지 않도록 합니다.

선택 사항

SpecDescriptors, StatusDescriptors, ActionDescriptors

이러한 설명자는 Operator의 특정 입력 또는 출력에서 최종 사용자에게 가장 중요한 UI를 나타내는 방법입니다. CRD에 사용자가 제공해야 하는 보안 또는 구성 맵의 이름이 있는 경우 여기에서 지정할 수 있습니다. 이러한 항목은 호환되는 UI에서 연결되고 강조됩니다.

설명자에는 세 가지 유형이 있습니다.

  • SpecDescriptors: 오브젝트의 spec 블록에 있는 필드에 대한 참조입니다.
  • StatusDescriptors: 오브젝트의 status 블록에 있는 필드에 대한 참조입니다.
  • ActionDescriptors: 오브젝트에서 수행할 수 있는 작업에 대한 참조입니다.

모든 설명자에는 다음 필드를 사용할 수 있습니다.

  • DisplayName: 사람이 읽을 수 있는 Spec, Status 또는 Action의 이름입니다.
  • Description: Spec, Status 또는 Action 및 Operator에서 사용하는 방법에 대한 간단한 설명입니다.
  • Path: 이 설명자에서 설명하는 오브젝트상의 점으로 구분된 필드 경로입니다.
  • X-Descriptors: 이 설명자의 “기능”과 사용할 UI 구성 요소를 결정하는 데 사용합니다. OpenShift Container Platform의 표준 React UI X-Descriptor 목록openshift/console 프로젝트를 참조하십시오.

일반적으로 설명자에 대한 자세한 내용은 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필수/선택 사항

Name

필요한 CRD의 전체 이름입니다.

필수 항목

Version

해당 오브젝트 API의 버전입니다.

필수 항목

Kind

Kubernetes 오브젝트 종류입니다.

필수 항목

DisplayName

사람이 읽을 수 있는 CRD 버전입니다.

필수 항목

Description

구성 요소가 더 큰 아키텍처에 어떻게 적용되는지 요약합니다.

필수 항목

필수 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를 추가하려면 다음을 수행합니다.

  1. CSV의 versions 섹션에서 CRD 리소스에 새 항목을 추가합니다.

    예를 들어 현재 CRD에 버전 v1alpha1이 있고, 새 버전 v1beta1을 추가한 후 새 스토리지 버전으로 표시하려면 v1beta1에 새 항목을 추가합니다.

    versions:
      - name: v1alpha1
        served: true
        storage: false
      - name: v1beta1 1
        served: true
        storage: true
    1
    새 항목입니다.
  2. CSV에서 새 버전을 사용하려고 하는 경우 CSV의 owned 섹션에 있는 CRD의 참조 버전이 업데이트되었는지 확인합니다.

    customresourcedefinitions:
      owned:
      - name: cluster.example.com
        version: v1beta1 1
        kind: cluster
        displayName: Cluster
    1
    version을 업데이트합니다.
  3. 업데이트된 CRD 및 CSV를 번들로 내보냅니다.
5.7.8.3.2. CRD 버전 사용 중단 또는 제거

OLM(Operator Lifecycle Manager)에서는 CRD(사용자 정의 리소스 정의)의 제공 버전을 즉시 제거하는 것을 허용하지 않습니다. 대신 CRD의 served 필드를 false로 설정하여 더 이상 사용되지 않는 CRD 버전을 먼저 비활성화해야 합니다. 그러면 후속 CRD 업그레이드에서 제공되지 않는 버전을 제거할 수 있습니다.

프로세스

특정 버전의 CRD를 사용 중단하고 제거하려면 다음을 수행합니다.

  1. 이 버전이 더 이상 사용되지 않으며 후속 업그레이드에서 제거될 수 있음을 나타내려면 더 이상 사용되지 않는 버전을 제공되지 않음으로 표시합니다. 예를 들면 다음과 같습니다.

    versions:
      - name: v1alpha1
        served: false 1
        storage: true
    1
    false로 설정합니다.
  2. 사용을 중단할 버전이 현재 storage 버전인 경우 storage 버전을 제공 버전으로 전환합니다. 예를 들면 다음과 같습니다.

    versions:
      - name: v1alpha1
        served: false
        storage: false 1
      - name: v1beta1
        served: true
        storage: true 2
    1 2
    storage 필드를 적절하게 업데이트합니다.
    참고

    CRD에서 storage 버전이거나 이 버전이었던 특정 버전을 제거하려면 CRD 상태의 storedVersion에서 해당 버전을 제거해야 합니다. OLM은 저장된 버전이 새 CRD에 더 이상 존재하지 않는 것으로 탐지하면 이 작업을 수행합니다.

  3. 위 변경 사항으로 CRD를 업그레이드합니다.
  4. 이어지는 업그레이드 주기에서는 서비스되지 않는 버전을 CRD에서 완전히 제거할 수 있습니다. 예를 들면 다음과 같습니다.

    versions:
      - name: v1beta1
        served: true
        storage: true
  5. CSV의 owned 섹션에서 참조하는 CRD 버전이 CRD에서 제거된 경우 적절하게 업데이트되었는지 확인합니다.

5.7.8.4. CRD 템플릿

Operator 사용자는 필수 옵션과 선택 옵션을 알고 있어야 합니다. 각 CRD(사용자 정의 리소스 정의)에 대한 템플릿에 alm-examples라는 주석으로 최소 구성 세트를 제공할 수 있습니다. 사용자가 추가로 사용자 정의할 수 있도록 호환되는 UI가 이 템플릿에 미리 채워집니다.

주석은 종류 목록으로 구성되며, 예를 들면 CRD 이름 및 Kubernetes 오브젝트의 해당 metadataspec입니다.

다음 전체 예제에서는 EtcdCluster, EtcdBackup, EtcdRestore에 대한 템플릿을 제공합니다.

metadata:
  annotations:
    alm-examples: >-
      [{"apiVersion":"etcd.database.coreos.com/v1beta2","kind":"EtcdCluster","metadata":{"name":"example","namespace":"<operator_namespace>"},"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를 숨길 수 있습니다.

프로세스

  1. CRD 중 하나를 내부로 표시하기 전에 애플리케이션을 관리하는 데 필요할 수 있는 디버깅 정보 또는 구성이 CR의 상태 또는 spec 블록에 반영되는지 확인합니다(Operator에 적용 가능한 경우).
  2. 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필수/선택 사항

Group

API 서비스에서 제공하는 그룹입니다(예: database.example.com).

필수 항목

Version

API 서비스의 버전입니다(예: v1alpha1).

필수 항목

Kind

API 서비스에서 제공해야 하는 종류입니다.

필수 항목

Name

제공되는 API 서비스의 복수형 이름입니다.

필수 항목

DeploymentName

CSV에서 정의한 배포 이름으로, API 서비스에 해당합니다(보유 API 서비스의 경우 필수). OLM Operator는 CSV 보류 단계 동안 CSV의 InstallStrategy에서 이름이 일치하는 Deployment 사양을 검색한 후 찾을 수 없는 경우 CSV를 "설치 준비" 단계로 전환하지 않습니다.

필수 항목

DisplayName

사람이 읽을 수 있는 버전의 API 서비스 이름입니다(예: MongoDB Standalone).

필수 항목

Description

Operator에서 이 API 서비스를 사용하는 방법에 대한 간단한 설명 또는 API 서비스에서 제공하는 기능에 대한 설명입니다.

필수 항목

Resources

사용 중인 API 서비스에서 Kubernetes 오브젝트 유형을 한 개 이상 보유하고 있습니다. 이러한 항목은 resources 섹션에 나열되어 문제 해결에 필요할 수 있는 오브젝트 또는 애플리케이션에 연결하는 방법을 사용자에게 알립니다(예: 데이터베이스를 표시하는 서비스 또는 수신 규칙).

오케스트레이션하는 모든 항목의 전체 목록이 아닌, 사용자에게 중요한 오브젝트만 나열하는 것이 좋습니다. 예를 들어 사용자가 수정할 수 없는 내부 상태를 저장하는 구성 맵은 나열하지 않도록 합니다.

선택 사항

SpecDescriptors, StatusDescriptors, ActionDescriptors

본질적으로 보유 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필수/선택 사항

Group

API 서비스에서 제공하는 그룹입니다(예: database.example.com).

필수 항목

Version

API 서비스의 버전입니다(예: v1alpha1).

필수 항목

Kind

API 서비스에서 제공해야 하는 종류입니다.

필수 항목

DisplayName

사람이 읽을 수 있는 버전의 API 서비스 이름입니다(예: MongoDB Standalone).

필수 항목

Description

Operator에서 이 API 서비스를 사용하는 방법에 대한 간단한 설명 또는 API 서비스에서 제공하는 기능에 대한 설명입니다.

필수 항목

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.