5.5. Helm 기반 Operator


5.5.1. Helm 기반 Operator를 위한 Operator SDK 시작하기

Operator SDK에는 Go 코드를 작성하지 않고도 기존 Helm 차트를 활용하여 Kubernetes 리소스를 통합 애플리케이션으로 배포하는 Operator 프로젝트를 생성하는 옵션이 포함되어 있습니다.

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

Operator 개발자는 Operator SDK에서 제공하는 툴 및 라이브러리를 사용하여 Helm 기반 Operator를 설정 및 실행하는 기본 동작을 설명하기 위해 Nginx에 대한 Helm 기반 Operator 예제를 빌드하고 클러스터에 배포할 수 있습니다.

5.5.1.1. 사전 요구 사항

  • Operator SDK CLI가 설치됨
  • OpenShift CLI (oc) 4.17 이상이 설치됨
  • cluster-admin 권한이 있는 계정으로 oc 를 사용하여 OpenShift Container Platform 4.17 클러스터에 로그인함
  • 클러스터가 이미지를 가져올 수 있도록 하려면 이미지를 내보내는 리포지토리를 공개로 설정하거나 이미지 가져오기 보안을 구성해야 합니다.

5.5.1.2. Helm 기반 Operator 생성 및 배포

Operator SDK를 사용하여 Nginx에 대한 간단한 Helm 기반 Operator를 빌드하고 배포할 수 있습니다.

프로세스

  1. 프로젝트를 생성합니다.

    1. 프로젝트 디렉토리를 생성합니다.

      $ mkdir nginx-operator
    2. 프로젝트 디렉터리로 변경합니다.

      $ cd nginx-operator
    3. helm 플러그인과 함께 operator-sdk init 명령을 실행하여 프로젝트를 초기화합니다.

      $ operator-sdk init \
          --plugins=helm
  2. API를 생성합니다.

    간단한 Nginx API를 생성합니다.

    $ operator-sdk create api \
        --group demo \
        --version v1 \
        --kind Nginx

    이 API는 helm create 명령의 기본 제공 Helm 차트 상용구를 사용합니다.

  3. Operator 이미지를 빌드하여 내보냅니다.

    기본 Makefile 대상을 사용하여 Operator를 빌드하고 내보냅니다. 내보낼 수 있는 레지스트리를 사용하는 이미지의 가져오기 사양에 IMG를 설정합니다.

    $ make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>
  4. Operator를 실행합니다.

    1. CRD를 설치합니다.

      $ make install
    2. 클러스터에 프로젝트를 배포합니다. 내보낸 이미지에 IMG를 설정합니다.

      $ make deploy IMG=<registry>/<user>/<image_name>:<tag>
  5. SCC(보안 컨텍스트 제약 조건)를 추가합니다.

    Nginx 서비스 계정에는 OpenShift Container Platform에서 실행할 수 있는 권한이 필요합니다. nginx-sample Pod의 서비스 계정에 다음 SCC를 추가합니다.

    $ oc adm policy add-scc-to-user \
        anyuid system:serviceaccount:nginx-operator-system:nginx-sample
  6. 샘플 CR(사용자 정의 리소스)을 생성합니다.

    1. 샘플 CR을 생성합니다.

      $ oc apply -f config/samples/demo_v1_nginx.yaml \
          -n nginx-operator-system
    2. CR에서 Operator를 조정하는지 확인합니다.

      $ oc logs deployment.apps/nginx-operator-controller-manager \
          -c manager \
          -n nginx-operator-system
  7. CR을 삭제합니다.

    다음 명령을 실행하여 CR을 삭제합니다.

    $ oc delete -f config/samples/demo_v1_nginx.yaml -n nginx-operator-system
  8. 정리합니다.

    다음 명령을 실행하여 이 절차의 일부로 생성된 리소스를 정리합니다.

    $ make undeploy

5.5.1.3. 다음 단계

5.5.2. helm 기반 Operator를 위한 Operator SDK 튜토리얼

Operator 개발자는 Operator SDK에서 Helm 지원을 활용하여 Nginx에 대한 Helm 기반 Operator 예제를 빌드하고 라이프사이클을 관리할 수 있습니다. 이 튜토리얼에서는 다음 프로세스를 안내합니다.

  • Nginx 배포 생성
  • 배포 크기가 Nginx CR(사용자 정의 리소스) 사양에 지정된 것과 같은지 확인합니다.
  • 상태 작성기를 사용하여 Nginx CR 상태를 nginx Pod의 이름으로 업데이트합니다.
중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

이 프로세스는 Operator 프레임워크의 두 가지 주요 요소를 사용하여 수행됩니다.

Operator SDK
operator-sdk CLI 툴 및 controller-runtime 라이브러리 API
OLM(Operator Lifecycle Manager)
클러스터에 대한 Operator의 설치, 업그레이드, RBAC(역할 기반 액세스 제어)
참고

5.5.2.1. 사전 요구 사항

  • Operator SDK CLI가 설치됨
  • OpenShift CLI (oc) 4.17 이상이 설치됨
  • cluster-admin 권한이 있는 계정으로 oc 를 사용하여 OpenShift Container Platform 4.17 클러스터에 로그인함
  • 클러스터가 이미지를 가져올 수 있도록 하려면 이미지를 내보내는 리포지토리를 공개로 설정하거나 이미지 가져오기 보안을 구성해야 합니다.

5.5.2.2. 프로젝트 생성

Operator SDK CLI를 사용하여 nginx-operator라는 프로젝트를 생성합니다.

프로세스

  1. 프로젝트에 사용할 디렉터리를 생성합니다.

    $ mkdir -p $HOME/projects/nginx-operator
  2. 디렉터리로 변경합니다.

    $ cd $HOME/projects/nginx-operator
  3. helm 플러그인과 함께 operator-sdk init 명령을 실행하여 프로젝트를 초기화합니다.

    $ operator-sdk init \
        --plugins=helm \
        --domain=example.com \
        --group=demo \
        --version=v1 \
        --kind=Nginx
    참고

    기본적으로 helm 플러그인은 상용구 Helm 차트를 사용하여 프로젝트를 초기화합니다. 기존 Helm 차트를 사용하는 프로젝트를 초기화하려면 --helm-chart 플래그와 같은 추가 플래그를 사용하면 됩니다.

    init 명령은 API 버전이 example.com/v1이고 종류가 Nginx인 리소스를 조사하기 위해 특별히 nginx-operator 프로젝트를 생성합니다.

  4. Helm 기반 프로젝트의 경우 init 명령은 차트의 기본 매니페스트에 의해 배포되는 리소스를 기반으로 config/rbac/role.yaml 파일에 RBAC 규칙을 생성합니다. 이 파일에 생성된 규칙이 Operator의 권한 요구 사항을 충족하는지 확인합니다.
5.5.2.2.1. 기존 Helm 차트

상용구 Helm 차트로 프로젝트를 생성하는 대신 다음 플래그를 사용하여 로컬 파일 시스템 또는 원격 차트 리포지토리에서 기존 차트를 사용할 수 있습니다.

  • --helm-chart
  • --helm-chart-repo
  • --helm-chart-version

--helm-chart 플래그가 지정되면 --group, --version, --kind 플래그가 선택 사항이 됩니다. 설정되지 않으면 다음 기본값이 사용됩니다.

플래그

--domain

my.domain

--group

charts

--version

v1

--kind

지정된 차트에서 추론됨

--helm-chart 플래그가 로컬 차트 아카이브(예: example-chart-1.2.0.tgz 또는 디렉터리)를 지정하는 경우 차트를 검증하고 압축을 풀거나 프로젝트에 복사합니다. 그러지 않으면 Operator SDK가 원격 리포지토리에서 차트를 가져옵니다.

--helm-chart-repo 플래그로 사용자 정의 리포지토리 URL이 지정되지 않는 경우 다음 차트 참조 형식이 지원됩니다.

형식설명

<repo_name>/<chart_name>

$HELM_HOME/repositories/repositories.yaml 파일에 지정된 대로 helm 차트 리포지토리 <repo_name>에서 Helm 차트 <chart_name>을 가져옵니다. helm repo add 명령을 사용하여 이 파일을 구성합니다.

<url>

지정된 URL에서 Helm 차트 아카이브를 가져옵니다.

사용자 정의 리포지토리 URL이 --helm-chart-repo로 지정된 경우 다음 차트 참조 형식이 지원됩니다.

형식설명

<chart_name>

--helm-chart-repo URL 값으로 지정된 Helm 차트 리포지토리에서 <chart_name>이라는 Helm 차트를 가져옵니다.

--helm-chart-version 플래그를 설정하지 않으면 Operator SDK에서 사용 가능한 최신 버전의 Helm 차트를 가져옵니다. 그러지 않으면 지정된 버전을 가져옵니다. --helm-chart 플래그로 지정한 차트에서 특정 버전을 참조하는 경우(예: 로컬 경로 또는 URL) 선택적 --helm-chart-version 플래그는 사용되지 않습니다.

자세한 내용 및 예를 보려면 다음을 실행합니다.

$ operator-sdk init --plugins helm --help
5.5.2.2.2. PROJECT 파일

operator-sdk init 명령으로 생성된 파일 중에는 Kubebuilder PROJECT 파일이 있습니다. 이어서 프로젝트 루트에서 실행되는 operator-sdk 명령과 help 출력에서는 이 파일을 읽고 프로젝트 유형이 Helm임을 확인합니다. 예를 들면 다음과 같습니다.

domain: example.com
layout:
- helm.sdk.operatorframework.io/v1
plugins:
  manifests.sdk.operatorframework.io/v2: {}
  scorecard.sdk.operatorframework.io/v2: {}
  sdk.x-openshift.io/v1: {}
projectName: nginx-operator
resources:
- api:
    crdVersion: v1
    namespaced: true
  domain: example.com
  group: demo
  kind: Nginx
  version: v1
version: "3"

5.5.2.3. Operator 논리 이해

이 예제에서 nginx-operator 프로젝트는 각 Nginx CR(사용자 정의 리소스)에 대해 다음과 같은 조정 논리를 실행합니다.

  • Nginx 배포가 없는 경우 해당 배포를 생성합니다.
  • Nginx 서비스가 없는 경우 해당 서비스를 생성합니다.
  • Nginx 수신이 활성화되어 있지만 없는 경우 해당 수신을 생성합니다.
  • 배포, 서비스, 선택적 수신이 Nginx CR에 지정된 대로 원하는 구성(예 : 복제본 수, 이미지, 서비스 유형)과 일치하는지 확인합니다.

기본적으로 nginx-operator 프로젝트는 watches.yaml 파일에 표시된 Nginx 리소스 이벤트를 조사하고 지정된 차트를 사용하여 Helm 릴리스를 실행합니다.

# Use the 'create api' subcommand to add watches to this file.
- group: demo
  version: v1
  kind: Nginx
  chart: helm-charts/nginx
# +kubebuilder:scaffold:watch
5.5.2.3.1. 샘플 Helm 차트

Helm Operator 프로젝트가 생성되면 Operator SDK는 간단한 Nginx 릴리스에 대한 일련의 템플릿이 포함된 샘플 Helm 차트를 생성합니다.

이 예제에서는 Helm 차트 개발자가 릴리스에 대한 유용한 정보를 전달하는 데 사용하는 NOTES.txt 템플릿과 함께 배포, 서비스, 수신 리소스에 대해 템플릿을 사용할 수 있습니다.

Helm 차트에 대해 잘 모르는 경우 Helm 개발자 설명서를 검토하십시오.

5.5.2.3.2. 사용자 정의 리소스 사양 수정

Helm은 이라는 개념을 사용하여 values.yaml 파일에 정의된 Helm 차트 기본값에 대한 사용자 정의 기능을 제공합니다.

CR(사용자 정의 리소스) 사양에 원하는 값을 설정하여 이러한 기본값을 덮어쓸 수 있습니다. 예를 들어 복제본 수를 사용할 수 있습니다.

프로세스

  1. helm-charts/nginx/values.yaml 파일에는 replicaCount라는 값이 있으며 기본적으로 1로 설정되어 있습니다. 배포에 Nginx 인스턴스를 두 개 포함하려면 CR 사양에 replicaCount: 2를 포함해야 합니다.

    config/samples/demo_v1_nginx.yaml 파일을 편집하여 replicaCount: 2를 설정합니다.

    apiVersion: demo.example.com/v1
    kind: Nginx
    metadata:
      name: nginx-sample
    ...
    spec:
    ...
      replicaCount: 2
  2. 마찬가지로 기본 서비스 포트는 80으로 설정됩니다. 8080을 사용하려면 config/samples/demo_v1_nginx.yaml 파일을 편집하여 서비스 포트 덮어쓰기를 추가하는 spec.port: 8080을 설정합니다.

    apiVersion: demo.example.com/v1
    kind: Nginx
    metadata:
      name: nginx-sample
    spec:
      replicaCount: 2
      service:
        port: 8080

Helm Operator는 helm install -f ./overrides.yaml 명령과 마찬가지로 값 파일의 콘텐츠인 것처럼 전체 사양을 적용합니다.

5.5.2.4. 프록시 지원 활성화

Operator 작성자는 네트워크 프록시를 지원하는 Operator를 개발할 수 있습니다. 클러스터 관리자는 OLM(Operator Lifecycle Manager)에서 처리하는 환경 변수에 대한 프록시 지원을 구성합니다. 프록시된 클러스터를 지원하려면 Operator에서 다음 표준 프록시 변수에 대한 환경을 검사하고 해당 값을 Operands에 전달해야 합니다.

  • HTTP_PROXY
  • HTTPS_PROXY
  • NO_PROXY
참고

이 튜토리얼에서는 예제 환경 변수로 HTTP_PROXY를 사용합니다.

사전 요구 사항

  • 클러스터 전체 egress 프록시가 활성화된 클러스터입니다.

프로세스

  1. overrideValues 필드를 추가하여 환경 변수에 따라 덮어쓰기를 포함하도록 watches.yaml 파일을 편집합니다.

    ...
    - group: demo.example.com
      version: v1alpha1
      kind: Nginx
      chart: helm-charts/nginx
      overrideValues:
        proxy.http: $HTTP_PROXY
    ...
  2. helm-charts/nginx/values.yaml 파일에 proxy.http 값을 추가합니다.

    ...
    proxy:
      http: ""
      https: ""
      no_proxy: ""
  3. 차트 템플릿이 변수 사용을 지원하는지 확인하려면 다음을 포함하도록 helm-charts/nginx/templates/deployment.yaml 파일에서 차트 템플릿을 편집합니다.

    containers:
      - name: {{ .Chart.Name }}
        securityContext:
          - toYaml {{ .Values.securityContext | nindent 12 }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag | default .Chart.AppVersion }}"
        imagePullPolicy: {{ .Values.image.pullPolicy }}
        env:
          - name: http_proxy
            value: "{{ .Values.proxy.http }}"
  4. config/manager/manager.yaml 파일에 다음을 추가하여 Operator 배포에서 환경 변수를 설정합니다.

    containers:
     - args:
       - --leader-elect
       - --leader-election-id=ansible-proxy-demo
       image: controller:latest
       name: manager
       env:
         - name: "HTTP_PROXY"
           value: "http_proxy_test"

5.5.2.5. Operator 실행

다음 세 가지 방법으로 Operator SDK CLI를 사용하여 Operator를 빌드하고 실행할 수 있습니다.

  • Go 프로그램으로 클러스터 외부에서 로컬로 실행합니다.
  • 클러스터에서 배포로 실행합니다.
  • Operator를 번들로 제공하고 OLM(Operator Lifecycle Manager)을 사용하여 클러스터에 배포합니다.
5.5.2.5.1. 클러스터 외부에서 로컬로 실행

Operator 프로젝트를 클러스터 외부의 Go 프로그램으로 실행할 수 있습니다. 이는 배포 및 테스트 속도를 높이기 위한 개발 목적에 유용합니다.

프로세스

  • 다음 명령을 실행하여 ~/.kube/config 파일에 구성된 클러스터에 CRD(사용자 정의 리소스 정의)를 설치하고 Operator를 로컬로 실행합니다.

    $ make install run

    출력 예

    ...
    {"level":"info","ts":1612652419.9289865,"logger":"controller-runtime.metrics","msg":"metrics server is starting to listen","addr":":8080"}
    {"level":"info","ts":1612652419.9296563,"logger":"helm.controller","msg":"Watching resource","apiVersion":"demo.example.com/v1","kind":"Nginx","namespace":"","reconcilePeriod":"1m0s"}
    {"level":"info","ts":1612652419.929983,"logger":"controller-runtime.manager","msg":"starting metrics server","path":"/metrics"}
    {"level":"info","ts":1612652419.930015,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting EventSource","source":"kind source: demo.example.com/v1, Kind=Nginx"}
    {"level":"info","ts":1612652420.2307851,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting Controller"}
    {"level":"info","ts":1612652420.2309358,"logger":"controller-runtime.manager.controller.nginx-controller","msg":"Starting workers","worker count":8}

5.5.2.5.2. 클러스터에서 배포로 실행

Operator 프로젝트를 클러스터에서 배포로 실행할 수 있습니다.

프로세스

  1. 다음 make 명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서 IMG 인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

    1. 이미지를 빌드합니다.

      $ make docker-build IMG=<registry>/<user>/<image_name>:<tag>
      참고

      Operator용 SDK에서 생성한 Dockerfile은 Go 빌드에 대해 GOARCH=amd64 를 명시적으로 참조합니다. AMD64 이외의 아키텍처의 경우 GOARCH=$TARGETARCH 로 수정할 수 있습니다. Docker는 자동으로 -platform 에서 지정한 값으로 환경 변수를 설정합니다. Buildah를 사용하면 -build-arg 를 목적으로 사용해야 합니다. 자세한 내용은 다중 아키텍처를 참조하십시오.

    2. 이미지를 리포지토리로 내보냅니다.

      $ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
      참고

      두 명령 모두 이미지의 이름과 태그(예: IMG=<registry>/<user>/<image_name>:<tag>)를 Makefile에 설정할 수 있습니다. 기본 이미지 이름을 설정하려면 IMG ?= controller:latest 값을 수정합니다.

  2. 다음 명령을 실행하여 Operator를 배포합니다.

    $ make deploy IMG=<registry>/<user>/<image_name>:<tag>

    기본적으로 이 명령은 <project_name>-system 형식으로 된 Operator 프로젝트 이름을 사용하여 네임스페이스를 생성하고 배포에 사용됩니다. 이 명령은 또한 config/rbac에서 RBAC 매니페스트를 설치합니다.

  3. 다음 명령을 실행하여 Operator가 실행 중인지 확인합니다.

    $ oc get deployment -n <project_name>-system

    출력 예

    NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
    <project_name>-controller-manager       1/1     1            1           8m

5.5.2.5.3. Operator 번들링 및 Operator Lifecycle Manager를 통한 배포
5.5.2.5.3.1. Operator 번들

Operator 번들 형식은 Operator SDK 및 Operator Lifecycle Manager (OLM)의 기본 패키지 메서드입니다. Operator SDK를 사용하여 Operator 프로젝트를 번들 이미지로 빌드하고 푸시하여 OLM에서 Operator를 사용할 수 있습니다.

사전 요구 사항

  • 개발 워크스테이션에 Operator SDK CLI가 설치됨
  • OpenShift CLI (oc) v4.17 이상이 설치됨
  • Operator SDK를 사용하여 Operator 프로젝트를 초기화함

프로세스

  1. Operator 프로젝트 디렉터리에서 다음 make 명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서 IMG 인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

    1. 이미지를 빌드합니다.

      $ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
      참고

      Operator용 SDK에서 생성한 Dockerfile은 Go 빌드에 대해 GOARCH=amd64 를 명시적으로 참조합니다. AMD64 이외의 아키텍처의 경우 GOARCH=$TARGETARCH 로 수정할 수 있습니다. Docker는 자동으로 -platform 에서 지정한 값으로 환경 변수를 설정합니다. Buildah를 사용하면 -build-arg 를 목적으로 사용해야 합니다. 자세한 내용은 다중 아키텍처를 참조하십시오.

    2. 이미지를 리포지토리로 내보냅니다.

      $ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
  2. Operator SDK generate bundlebundle validate 명령을 비롯한 다양한 명령을 호출하는 make bundle 명령을 실행하여 Operator 번들 매니페스트를 생성합니다.

    $ make bundle IMG=<registry>/<user>/<operator_image_name>:<tag>

    Operator의 번들 매니페스트는 애플리케이션을 표시, 생성, 관리하는 방법을 설명합니다. make bundle 명령은 Operator 프로젝트에서 다음 파일 및 디렉터리를 생성합니다.

    • ClusterServiceVersion 오브젝트를 포함하는 bundle/manifests라는 번들 매니페스트 디렉터리
    • bundle/metadata라는 번들 메타데이터 디렉터리
    • config/crd 디렉터리의 모든 CRD(사용자 정의 리소스 정의)
    • Dockerfile bundle.Dockerfile

    그런 다음 operator-sdk bundle validate를 사용하여 이러한 파일을 자동으로 검증하고 디스크상의 번들 표현이 올바른지 확인합니다.

  3. 다음 명령을 실행하여 번들 이미지를 빌드하고 내보냅니다. OLM에서는 하나 이상의 번들 이미지를 참조하는 인덱스 이미지를 통해 Operator 번들을 사용합니다.

    1. 번들 이미지를 빌드합니다. 이미지를 내보낼 레지스트리, 사용자 네임스페이스, 이미지 태그에 대한 세부 정보를 사용하여 BUNDLE_IMG를 설정합니다.

      $ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
    2. 번들 이미지를 내보냅니다.

      $ docker push <registry>/<user>/<bundle_image_name>:<tag>
5.5.2.5.3.2. Operator Lifecycle Manager를 사용하여 Operator 배포

OLM(Operator Lifecycle Manager)은 Kubernetes 클러스터에서 Operator 및 관련 서비스를 설치, 업데이트하고 라이프사이클을 관리하는 데 도움이 됩니다. OLM은 기본적으로 OpenShift Container Platform에 설치되고 Kubernetes 확장으로 실행되므로 추가 툴 없이 모든 Operator 라이프사이클 관리 기능에 웹 콘솔과 OpenShift CLI(oc)를 사용할 수 있습니다.

Operator 번들 형식은 Operator SDK 및 OLM의 기본 패키지 메서드입니다. Operator SDK를 사용하여 OLM에서 번들 이미지를 신속하게 실행하여 올바르게 실행되는지 확인할 수 있습니다.

사전 요구 사항

  • 개발 워크스테이션에 Operator SDK CLI가 설치됨
  • Operator 번들 이미지를 빌드하여 레지스트리로 내보냄
  • Kubernetes 기반 클러스터에 OLM이 설치됨( apiextensions.k8s.io/v1 CRD(예: OpenShift Container Platform 4.17)를 사용하는 경우 v1.16.0 이상
  • cluster-admin 권한이 있는 계정을 사용하여 oc로 클러스터에 로그인됨

프로세스

  • 다음 명령을 입력하여 클러스터에서 Operator를 실행합니다.

    $ operator-sdk run bundle \1
        -n <namespace> \2
        <registry>/<user>/<bundle_image_name>:<tag> 3
    1
    run bundle 명령은 유효한 파일 기반 카탈로그를 생성하고 OLM을 사용하여 클러스터에 Operator 번들을 설치합니다.
    2
    선택 사항: 기본적으로 이 명령은 ~/.kube/config 파일의 현재 활성 프로젝트에 Operator를 설치합니다. -n 플래그를 추가하면 설치에 다른 네임스페이스 범위를 설정할 수 있습니다.
    3
    이미지를 지정하지 않으면 명령에서 quay.io/operator-framework/opm:latest 를 기본 인덱스 이미지로 사용합니다. 이미지를 지정하면 명령에서 번들 이미지 자체를 인덱스 이미지로 사용합니다.
    중요

    OpenShift Container Platform 4.11부터 run bundle 명령은 기본적으로 Operator 카탈로그의 파일 기반 카탈로그 형식을 지원합니다. Operator 카탈로그의 더 이상 사용되지 않는 SQLite 데이터베이스 형식은 계속 지원되지만 향후 릴리스에서 제거됩니다. Operator 작성자는 워크플로우를 파일 기반 카탈로그 형식으로 마이그레이션하는 것이 좋습니다.

    이 명령은 다음 작업을 수행합니다.

    • 번들 이미지를 참조하는 인덱스 이미지를 생성합니다. 인덱스 이미지는 불투명하고 일시적이지만 프로덕션에서 카탈로그에 번들을 추가하는 방법을 정확하게 반영합니다.
    • OperatorHub에서 Operator를 검색할 수 있도록 새 인덱스 이미지를 가리키는 카탈로그 소스를 생성합니다.
    • OperatorGroup,Subscription,InstallPlan 및 RBAC를 포함한 기타 모든 필수 리소스를 생성하여 Operator를 클러스터에 배포합니다.

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

Operator가 설치되면 Operator에서 현재 클러스터에 제공하는 CR(사용자 정의 리소스)을 생성하여 Operator를 테스트할 수 있습니다.

사전 요구 사항

  • Nginx CR을 제공하는 Nginx Operator 예제가 클러스터에 설치되어 있음

프로세스

  1. Operator가 설치된 네임스페이스로 변경합니다. 예를 들어 make deploy 명령을 사용하여 Operator를 배포한 경우 다음을 실행합니다.

    $ oc project nginx-operator-system
  2. 다음 사양을 포함하도록 config/samples/demo_v1_nginx.yaml에서 샘플 Nginx CR 매니페스트를 편집합니다.

    apiVersion: demo.example.com/v1
    kind: Nginx
    metadata:
      name: nginx-sample
    ...
    spec:
    ...
      replicaCount: 3
  3. Nginx 서비스 계정에는 OpenShift Container Platform에서 실행할 수 있는 권한이 필요합니다. nginx-sample Pod의 서비스 계정에 다음 SCC(보안 컨텍스트 제약 조건)를 추가합니다.

    $ oc adm policy add-scc-to-user \
        anyuid system:serviceaccount:nginx-operator-system:nginx-sample
  4. CR을 생성합니다.

    $ oc apply -f config/samples/demo_v1_nginx.yaml
  5. Nginx Operator에서 샘플 CR에 대한 배포를 올바른 크기로 생성하는지 확인합니다.

    $ oc get deployments

    출력 예

    NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
    nginx-operator-controller-manager       1/1     1            1           8m
    nginx-sample                            3/3     3            3           1m

  6. Pod 및 CR 상태를 확인하여 상태가 Nginx Pod 이름으로 업데이트되었는지 확인합니다.

    1. Pod를 확인합니다.

      $ oc get pods

      출력 예

      NAME                                  READY     STATUS    RESTARTS   AGE
      nginx-sample-6fd7c98d8-7dqdr          1/1       Running   0          1m
      nginx-sample-6fd7c98d8-g5k7v          1/1       Running   0          1m
      nginx-sample-6fd7c98d8-m7vn7          1/1       Running   0          1m

    2. CR 상태 확인:

      $ oc get nginx/nginx-sample -o yaml

      출력 예

      apiVersion: demo.example.com/v1
      kind: Nginx
      metadata:
      ...
        name: nginx-sample
      ...
      spec:
        replicaCount: 3
      status:
        nodes:
        - nginx-sample-6fd7c98d8-7dqdr
        - nginx-sample-6fd7c98d8-g5k7v
        - nginx-sample-6fd7c98d8-m7vn7

  7. 배포 크기를 업데이트합니다.

    1. config/samples/demo_v1_nginx.yaml 파일을 업데이트하여 Nginx CR의 spec.size 필드를 3에서 5로 변경합니다.

      $ oc patch nginx nginx-sample \
          -p '{"spec":{"replicaCount": 5}}' \
          --type=merge
    2. Operator에서 배포 크기를 변경하는지 확인합니다.

      $ oc get deployments

      출력 예

      NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
      nginx-operator-controller-manager       1/1     1            1           10m
      nginx-sample                            5/5     5            5           3m

  8. 다음 명령을 실행하여 CR을 삭제합니다.

    $ oc delete -f config/samples/demo_v1_nginx.yaml
  9. 이 튜토리얼의 일부로 생성된 리소스를 정리합니다.

    • make deploy 명령을 사용하여 Operator를 테스트한 경우 다음 명령을 실행합니다.

      $ make undeploy
    • operator-sdk run bundle 명령을 사용하여 Operator를 테스트한 경우 다음 명령을 실행합니다.

      $ operator-sdk cleanup <project_name>

5.5.2.7. 추가 리소스

5.5.3. Helm 기반 Operator의 프로젝트 레이아웃

operator-sdk CLI에서는 각 Operator 프로젝트에 대해 다양한 패키지 및 파일을 생성하거나 스캐폴드를 지정할 수 있습니다.

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

5.5.3.1. Helm 기반 프로젝트 레이아웃

operator-sdk init --plugins helm 명령을 사용하여 생성된 Helm 기반 Operator 프로젝트에는 다음 디렉터리 및 파일이 포함됩니다.

파일/폴더목적

config/

Kubernetes 클러스터에 Operator를 배포하는 Kustomize 매니페스트입니다.

helm-charts/

operator-sdk create api 명령을 사용하여 초기화한 Helm 차트입니다.

Dockerfile

make docker-build 명령을 사용하여 Operator 이미지를 빌드하는 데 사용합니다.

watches.yaml

GVK(그룹/버전/종류) 및 Helm 차트 위치입니다.

Makefile

프로젝트 관리에 사용되는 대상입니다.

PROJECT

Operator의 메타데이터 정보가 포함된 YAML 파일입니다.

5.5.4. 최신 Operator SDK 버전을 위한 Helm 기반 프로젝트 업데이트

OpenShift Container Platform 4.17은 Operator SDK 1.36.1을 지원합니다. 워크스테이션에 1.31.0 CLI가 이미 설치되어 있는 경우 최신 버전을 설치하여 CLI를 1.36.1으로 업데이트할 수 있습니다.

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

그러나 기존 Operator 프로젝트에서 Operator SDK 1.36.1과의 호환성을 유지하려면 1.31.0 이후의 중단된 변경 사항에 대한 업데이트 단계가 필요합니다. 1.31.0을 사용하여 이전에 생성되거나 유지 관리되는 Operator 프로젝트에서 업데이트 단계를 수동으로 수행해야 합니다.

5.5.4.1. Operator SDK 1.36.1의 Helm 기반 Operator 프로젝트 업데이트

다음 절차에서는 1.36.1과의 호환성을 위해 기존 Helm 기반 Operator 프로젝트를 업데이트합니다.

사전 요구 사항

  • Operator SDK 1.36.1 설치
  • Operator SDK 1.31.0을 사용하여 생성되거나 유지 관리되는 Operator 프로젝트

프로세스

  1. 다음 예와 같이 Operator 프로젝트의 Makefile을 편집하여 Operator SDK 버전을 v1.36.1-ocp 로 업데이트합니다.

    Makefile의 예

    # Set the Operator SDK version to use. By default, what is installed on the system is used.
    # This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit.
    OPERATOR_SDK_VERSION ?= v1.36.1-ocp

  2. RHEL(Red Hat Enterprise Linux) 9 기반 이미지를 사용하도록 kube-rbac-proxy 컨테이너를 업데이트합니다.

    1. 다음 파일에서 kube-rbac-proxy 컨테이너 항목을 찾습니다.

      • config/default/manager_auth_proxy_patch.yaml
      • Operator 프로젝트의 bundle/manifests/<operator_name>.clusterserviceversion.yaml (예: 튜토리얼의 memcached-operator.clusterserviceversion.yaml )
    2. ose-kube-rbac-proxy에서 ose-kube-rbac-proxy -rhel9 로 가져오기 사양의 이미지 이름을 업데이트하고 태그를 v4.17 으로 업데이트합니다.

      v4.17 이미지 태그가 있는 ose-kube-rbac-proxy-rhel9 풀 사양의 예

      # ...
            containers:
            - name: kube-rbac-proxy
              image: registry.redhat.io/openshift4/ose-kube-rbac-proxy-rhel9:v4.17
      # ...

  3. 다음 예와 같이 Operator의 Dockerfile을 편집하여 ose-helm-rhel9-operator 이미지 태그를 4.17 로 업데이트합니다.

    Dockerfile 예

    FROM registry.redhat.io/openshift4/ose-helm-rhel9-operator:v4.17

  4. kustomize/v2 플러그인은 이제 안정적인 상태이며 go/v4,ansible/v1,helm/v1, hybrid/v1-alpha 플러그인을 사용할 때 플러그인 체인에 사용되는 기본 버전입니다. 이 기본 스캐폴드에 대한 자세한 내용은 Kubebuilder 설명서의 Kustomize v2 를 참조하십시오.
  5. Operator 프로젝트에서 다중 플랫폼 또는 다중 아키텍처, 빌드를 사용하는 경우 기존 docker-buildx 대상을 프로젝트 Makefile의 다음 정의로 교체합니다.

    Makefile의 예

    docker-buildx:
    ## Build and push the Docker image for the manager for multi-platform support
    	- docker buildx create --name project-v3-builder
    	docker buildx use project-v3-builder
    	- docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile .
    	- docker buildx rm project-v3-builder

  6. 1.29를 사용하려면 Operator 프로젝트의 Kubernetes 버전을 업그레이드해야 합니다. 프로젝트 구조, Makefile 및 go.mod 파일을 다음과 같이 변경해야 합니다.

    중요

    Go/v3 플러그인은 Kubebuilder에서 더 이상 사용되지 않으므로 Operator SDK도 향후 릴리스에서 go/v4 로 마이그레이션되고 있습니다.

    1. go.mod 파일을 업데이트하여 종속 항목을 업그레이드합니다.

      k8s.io/api v0.29.2
      k8s.io/apimachinery v0.29.2
      k8s.io/client-go v0.29.2
      sigs.k8s.io/controller-runtime v0.17.3
    2. 다음 명령을 실행하여 업그레이드된 종속 항목을 다운로드합니다.

      $ go mod tidy
  7. 다음과 같이 변경하여 Makefile에서 Kustomize 버전을 업데이트합니다.

    - curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.2.1/kustomize_v5.2.1_$(OS)_$(ARCH).tar.gz | \
    + curl -sSLo - https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/v5.3.0/kustomize_v5.3.0_$(OS)_$(ARCH).tar.gz | \

5.5.4.2. 추가 리소스

5.5.5. Operator SDK의 Helm 지원

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

5.5.5.1. Helm 차트

Operator 프로젝트를 생성하기 위한 Operator SDK 옵션 중 하나는 Go 코드를 작성하지 않고 Kubernetes 리소스를 통합 애플리케이션으로 배포하기 위해 기존 Helm 차트를 활용하는 것입니다. 이러한 Helm 기반 Operator는 차트의 일부로 생성되는 Kubernetes 오브젝트에 변경 사항을 적용해야 하기 때문에 롤아웃 시 논리가 거의 필요하지 않은 상태 비저장 애플리케이션에서 잘 작동하도록 설계되었습니다. 이는 제한적으로 들릴 수 있지만 Kubernetes 커뮤니티에서 빌드한 Helm 차트의 확산으로 알 수 있듯이 대용량 사용 사례에도 충분할 수 있습니다.

Operator의 주요 기능은 애플리케이션 인스턴스를 표시하는 사용자 정의 오브젝트에서 읽고 원하는 상태가 실행 중인 것과 일치하도록 하는 것입니다. Helm 기반 Operator의 경우 오브젝트의 spec 필드는 일반적으로 Helm values.yaml 파일에 설명된 구성 옵션의 목록입니다. Helm CLI(예: helm install -f values.yaml)를 사용하여 이러한 값을 플래그로 설정하는 대신 CR(사용자 정의 리소스) 내에 표시할 수 있습니다. 그러면 네이티브 Kubernetes 개체로서 여기에 적용된 RBAC 및 감사 추적의 이점을 활용할 수 있습니다.

Tomcat이라는 간단한 CR 예제를 살펴보겠습니다.

apiVersion: apache.org/v1alpha1
kind: Tomcat
metadata:
  name: example-app
spec:
  replicaCount: 2

이 경우 replicaCount 값인 2가 다음이 사용되는 차트의 템플릿으로 전파됩니다.

{{ .Values.replicaCount }}

Operator를 빌드하고 배포한 후에는 CR 인스턴스를 새로 생성하여 앱의 새 인스턴스를 배포하거나 oc 명령을 사용하여 모든 환경에서 실행 중인 다른 인스턴스를 나열할 수 있습니다.

$ oc get Tomcats --all-namespaces

Helm CLI를 사용하거나 Tiller를 설치할 필요가 없습니다. Helm 기반 Operator는 Helm 프로젝트에서 코드를 가져옵니다. Operator의 인스턴스를 실행하고 CRD(사용자 정의 리소스 정의)를 사용하여 CR을 등록하기만 하면 됩니다. RBAC를 준수하기 때문에 프로덕션이 변경되는 것을 더 쉽게 방지할 수 있습니다.

5.5.6. 하이브리드 Helm Operator를 위한 Operator SDK 튜토리얼

Operator SDK의 표준 Helm 기반 Operator 지원은 Operator 완성 모델의 Auto Pilot 기능(level V)에 도달한 Go 기반 및 Ansible 기반 Operator 지원에 비해 기능이 제한되어 있습니다.

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

Hybrid Helm Operator는 Go API를 통해 기존 Helm 기반 지원 기능을 향상시킵니다. 이 Helm 및 Go의 하이브리드 접근 방식을 통해 Operator 작성자는 Operator 작성자가 다음 프로세스를 사용할 수 있습니다.

  • Helm과 동일한 프로젝트에서 Go API의 기본 구조를 생성하거나 스캐폴드 를 생성합니다.
  • 하이브리드 Helm Operator에서 제공하는 라이브러리를 통해 프로젝트의 main.go 파일에서 Helm 조정기를 구성합니다.
중요

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

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

이 튜토리얼에서는 Hybrid Helm Operator를 사용하여 다음 프로세스를 안내합니다.

  • Helm 차트가 없는 경우 Memcached 배포를 생성
  • 배포 크기가 Memcached CR(사용자 정의 리소스) 사양에 지정된 것과 동일한지 확인합니다.
  • Go API를 사용하여 MemcachedBackup 배포 생성

5.5.6.1. 사전 요구 사항

  • Operator SDK CLI가 설치됨
  • OpenShift CLI (oc) 4.17 이상이 설치됨
  • cluster-admin 권한이 있는 계정으로 oc 를 사용하여 OpenShift Container Platform 4.17 클러스터에 로그인함
  • 클러스터가 이미지를 가져올 수 있도록 하려면 이미지를 내보내는 리포지토리를 공개로 설정하거나 이미지 가져오기 보안을 구성해야 합니다.

5.5.6.2. 프로젝트 생성

Operator SDK CLI를 사용하여 memcached-operator라는 프로젝트를 생성합니다.

프로세스

  1. 프로젝트에 사용할 디렉터리를 생성합니다.

    $ mkdir -p $HOME/github.com/example/memcached-operator
  2. 디렉터리로 변경합니다.

    $ cd $HOME/github.com/example/memcached-operator
  3. operator-sdk init 명령을 실행하여 프로젝트를 초기화합니다. 이 예제에서는 모든 API 그룹이 . my.domain 이 되도록 my.domain 의 도메인을 사용합니다.

    $ operator-sdk init \
        --plugins=hybrid.helm.sdk.operatorframework.io \
        --project-version="3" \
        --domain my.domain \
        --repo=github.com/example/memcached-operator

    init 명령은 차트의 기본 매니페스트로 배포할 리소스를 기반으로 config/rbac/role.yaml 파일에 RBAC 규칙을 생성합니다. config/rbac/role.yaml 파일에서 생성된 규칙이 Operator의 권한 요구 사항을 충족하는지 확인합니다.

추가 리소스

  • 이 절차에서는 Helm 및 Go API와 호환되는 프로젝트 구조를 생성합니다. 프로젝트 디렉터리 구조에 대한 자세한 내용은 프로젝트 레이아웃 을 참조하십시오.

5.5.6.3. Helm API 생성

Operator SDK CLI를 사용하여 Helm API를 생성합니다.

프로세스

  • 다음 명령을 실행하여 그룹 캐시, 버전 v1 및 kind Memcached 를 사용하여 Helm API를 생성합니다.

    $ operator-sdk create api \
        --plugins helm.sdk.operatorframework.io/v1 \
        --group cache \
        --version v1 \
        --kind Memcached
참고

이 절차에서는 API 버전 v1 을 사용하여 Memcached 리소스를 감시하고 상용구 Helm 차트를 스캐폴드하도록 Operator 프로젝트를 구성합니다. Operator SDK가 스캐폴드한 상용구 Helm 차트에서 프로젝트를 생성하는 대신 로컬 파일 시스템 또는 원격 차트 리포지터리의 기존 차트를 사용할 수 있습니다.

기존 또는 새 차트를 기반으로 Helm API 생성에 대한 자세한 내용 및 예제를 보려면 다음 명령을 실행합니다.

$ operator-sdk create api --plugins helm.sdk.operatorframework.io/v1 --help

추가 리소스

5.5.6.3.1. Helm API에 대한 Operator 논리

기본적으로 스캐폴드된 Operator 프로젝트는 watches.yaml 파일에 표시된 대로 Memcached 리소스 이벤트를 감시하고 지정된 차트를 사용하여 Helm 릴리스를 실행합니다.

예 5.3. watches.yaml 파일의 예

# Use the 'create api' subcommand to add watches to this file.
- group: cache.my.domain
  version: v1
  kind: Memcached
  chart: helm-charts/memcached
#+kubebuilder:scaffold:watch

추가 리소스

  • 차트를 통해 Helm Operator 논리 사용자 지정에 대한 자세한 문서는 Operator 논리 이해를 참조하십시오.
5.5.6.3.2. 제공된 라이브러리 API를 사용한 사용자 정의 Helm 조정기 구성

기존 Helm 기반 Operator의 단점은 사용자가 추상화하므로 Helm 조정기를 구성할 수 없다는 것입니다. Helm 기반 Operator가 기존 Helm 차트를 재사용하는 Seamless Upgrades 기능(단계 II 이상)에 도달하려면 Go와 Helm Operator 유형 간의 하이브리드가 값을 추가합니다.

helm-operator-plugins 라이브러리에 제공된 API를 사용하면 Operator 작성자가 다음 구성을 수행할 수 있습니다.

  • 클러스터 상태를 기반으로 값 매핑 사용자 정의
  • 조정기의 이벤트 레코더를 구성하여 특정 이벤트에서 코드를 실행
  • 조정기의 로거 사용자 지정
  • 조정기에서 조사한 사용자 정의 리소스에 있는 주석을 기반으로 Helm의 작업을 구성할 수 있도록 설치,업그레이드설치 제거를 설정합니다.
  • 사전사후 후크로 실행되도록 조정기를 구성합니다.

조정기에 대한 위의 구성은 main.go 파일에서 수행할 수 있습니다.

main.go 파일 예

// Operator's main.go
// With the help of helpers provided in the library, the reconciler can be
// configured here before starting the controller with this reconciler.
reconciler := reconciler.New(
 reconciler.WithChart(*chart),
 reconciler.WithGroupVersionKind(gvk),
)

if err := reconciler.SetupWithManager(mgr); err != nil {
 panic(fmt.Sprintf("unable to create reconciler: %s", err))
}

5.5.6.4. Go API 생성

Operator SDK CLI를 사용하여 Go API를 생성합니다.

프로세스

  1. 다음 명령을 실행하여 그룹 캐시, 버전 v1 및 kind MemcachedBackup 으로 Go API를 생성합니다.

    $ operator-sdk create api \
        --group=cache \
        --version v1 \
        --kind MemcachedBackup \
        --resource \
        --controller \
        --plugins=go/v4
  2. 메시지가 표시되면 리소스 및 컨트롤러를 모두 생성하도록 y 를 입력합니다.

    $ Create Resource [y/n]
    y
    Create Controller [y/n]
    y

이 절차에서는 api/v1/memcachedbackup_types.goMemcachedBackup 리소스 API와 controller /memcachedbackup_controller.go에 컨트롤러 를 생성합니다.

5.5.6.4.1. API 정의

MemcachedBackup CR(사용자 정의 리소스)의 API를 정의합니다.

배포할 MemcachedBackup 인스턴스(CR)의 수량을 설정하는 MemcachedBackupSpec.Size 필드와 CR의 Pod 이름을 저장하기 위한 MemcachedBackupStatus.Nodes 필드를 정의하여 이 Go API를 나타냅니다.

참고

Node 필드는 Status 필드의 예를 설명하는 데 사용됩니다.

프로세스

  1. 다음 사양상태를 갖도록 api/v1/memcachedbackup_types.go 파일에서 Go 유형 정의를 수정하여 MemcachedBackup CR의 API를 정의합니다.

    예 5.4. api/v1/memcachedbackup_types.go 파일의 예

    // MemcachedBackupSpec defines the desired state of MemcachedBackup
    type MemcachedBackupSpec struct {
    	// INSERT ADDITIONAL SPEC FIELDS - desired state of cluster
    	// Important: Run "make" to regenerate code after modifying this file
    
    	//+kubebuilder:validation:Minimum=0
    	// Size is the size of the memcached deployment
    	Size int32 `json:"size"`
    }
    
    // MemcachedBackupStatus defines the observed state of MemcachedBackup
    type MemcachedBackupStatus struct {
    	// INSERT ADDITIONAL STATUS FIELD - define observed state of cluster
    	// Important: Run "make" to regenerate code after modifying this file
    	// Nodes are the names of the memcached pods
    	Nodes []string `json:"nodes"`
    }
  2. 리소스 유형에 대해 생성된 코드를 업데이트합니다.

    $ make generate
    작은 정보

    *_types.go 파일을 수정한 후에는 make generate 명령을 실행하여 해당 리소스 유형에 대해 생성된 코드를 업데이트해야 합니다.

  3. specstatus 필드 및 CRD 검증 마커를 사용하여 API를 정의한 후 CRD 매니페스트를 생성하고 업데이트합니다.

    $ make manifests

이 Makefile 대상은 controller-gen 유틸리티를 호출하여 config/crd/bases/cache.my.domain_memcachedbackups.yaml 파일에서 CRD 매니페스트를 생성합니다.

5.5.6.4.2. 컨트롤러 구현

이 튜토리얼의 컨트롤러는 다음 작업을 수행합니다.

  • Memcached 배포가 없는 경우 생성합니다.
  • 배포 크기가 Memcached CR 사양에 지정된 것과 같은지 확인합니다.
  • Memcached CR 상태를 memcached Pod의 이름으로 업데이트합니다.

위 작업을 수행하도록 컨트롤러를 구성하는 방법에 대한 자세한 내용은 표준 Go 기반 Operator 를 위해 Operator SDK 튜토리얼에서 컨트롤러 구현을 참조하십시오.

5.5.6.4.3. main.go의 차이점

표준 Go 기반 Operator 및 하이브리드 Helm Operator의 경우 main.go 파일은 Go API용 Manager 프로그램의 초기화 및 실행을 스캐폴드합니다. 그러나 Hybrid Helm Operator의 경우 main.go 파일은 watches.yaml 파일을 로드하고 Helm 조정기를 구성하는 논리도 노출합니다.

예 5.5. main.go 파일 예

...
	for _, w := range ws {
		// Register controller with the factory
		reconcilePeriod := defaultReconcilePeriod
		if w.ReconcilePeriod != nil {
			reconcilePeriod = w.ReconcilePeriod.Duration
		}

		maxConcurrentReconciles := defaultMaxConcurrentReconciles
		if w.MaxConcurrentReconciles != nil {
			maxConcurrentReconciles = *w.MaxConcurrentReconciles
		}

		r, err := reconciler.New(
			reconciler.WithChart(*w.Chart),
			reconciler.WithGroupVersionKind(w.GroupVersionKind),
			reconciler.WithOverrideValues(w.OverrideValues),
			reconciler.SkipDependentWatches(w.WatchDependentResources != nil && !*w.WatchDependentResources),
			reconciler.WithMaxConcurrentReconciles(maxConcurrentReconciles),
			reconciler.WithReconcilePeriod(reconcilePeriod),
			reconciler.WithInstallAnnotations(annotation.DefaultInstallAnnotations...),
			reconciler.WithUpgradeAnnotations(annotation.DefaultUpgradeAnnotations...),
			reconciler.WithUninstallAnnotations(annotation.DefaultUninstallAnnotations...),
		)
...

관리자는 HelmGo 조정기 모두로 초기화됩니다.

예 5.6. HelmGo 조정기의 예

...
// Setup manager with Go API
   if err = (&controllers.MemcachedBackupReconciler{
		Client: mgr.GetClient(),
		Scheme: mgr.GetScheme(),
	}).SetupWithManager(mgr); err != nil {
		setupLog.Error(err, "unable to create controller", "controller", "MemcachedBackup")
		os.Exit(1)
	}

   ...
// Setup manager with Helm API
	for _, w := range ws {

      ...
		if err := r.SetupWithManager(mgr); err != nil {
			setupLog.Error(err, "unable to create controller", "controller", "Helm")
			os.Exit(1)
		}
		setupLog.Info("configured watch", "gvk", w.GroupVersionKind, "chartPath", w.ChartPath, "maxConcurrentReconciles", maxConcurrentReconciles, "reconcilePeriod", reconcilePeriod)
	}

// Start the manager
   if err := mgr.Start(ctrl.SetupSignalHandler()); err != nil {
		setupLog.Error(err, "problem running manager")
		os.Exit(1)
	}
5.5.6.4.4. 권한 및 RBAC 매니페스트

컨트롤러에서 관리하는 리소스와 상호 작용하려면 특정 역할 기반 액세스 제어(RBAC) 권한이 필요합니다. Go API의 경우 표준 Go 기반 Operator를 위한 Operator SDK 튜토리얼에 표시된 대로 RBAC 마커를 사용하여 지정됩니다.

Helm API의 경우 기본적으로 roles.yaml 에서 권한이 스캐폴드됩니다. 그러나 현재 Go API가 스캐폴드될 때 알려진 문제로 인해 Helm API에 대한 권한을 덮어씁니다. 이 문제로 인해 roles.yaml 에 정의된 권한이 요구 사항과 일치하는지 확인합니다.

참고

이 알려진 문제는 https://github.com/operator-framework/helm-operator-plugins/issues/142 에서 추적되고 있습니다.

다음은 Memcached Operator의 예제 role.yaml 입니다.

예 5.7. HelmGo 조정기의 예

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: manager-role
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
- apiGroups:
  - apps
  resources:
  - deployments
  - daemonsets
  - replicasets
  - statefulsets
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - cache.my.domain
  resources:
  - memcachedbackups
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - cache.my.domain
  resources:
  - memcachedbackups/finalizers
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - pods
  - services
  - services/finalizers
  - endpoints
  - persistentvolumeclaims
  - events
  - configmaps
  - secrets
  - serviceaccounts
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - cache.my.domain
  resources:
  - memcachedbackups/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - policy
  resources:
  - events
  - poddisruptionbudgets
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - cache.my.domain
  resources:
  - memcacheds
  - memcacheds/status
  - memcacheds/finalizers
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch

5.5.6.5. 클러스터 외부에서 로컬로 실행

Operator 프로젝트를 클러스터 외부의 Go 프로그램으로 실행할 수 있습니다. 이는 배포 및 테스트 속도를 높이기 위한 개발 목적에 유용합니다.

프로세스

  • 다음 명령을 실행하여 ~/.kube/config 파일에 구성된 클러스터에 CRD(사용자 정의 리소스 정의)를 설치하고 Operator를 로컬로 실행합니다.

    $ make install run

5.5.6.6. 클러스터에서 배포로 실행

Operator 프로젝트를 클러스터에서 배포로 실행할 수 있습니다.

프로세스

  1. 다음 make 명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서 IMG 인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.

    1. 이미지를 빌드합니다.

      $ make docker-build IMG=<registry>/<user>/<image_name>:<tag>
      참고

      Operator용 SDK에서 생성한 Dockerfile은 Go 빌드에 대해 GOARCH=amd64 를 명시적으로 참조합니다. AMD64 이외의 아키텍처의 경우 GOARCH=$TARGETARCH 로 수정할 수 있습니다. Docker는 자동으로 -platform 에서 지정한 값으로 환경 변수를 설정합니다. Buildah를 사용하면 -build-arg 를 목적으로 사용해야 합니다. 자세한 내용은 다중 아키텍처를 참조하십시오.

    2. 이미지를 리포지토리로 내보냅니다.

      $ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
      참고

      두 명령 모두 이미지의 이름과 태그(예: IMG=<registry>/<user>/<image_name>:<tag>)를 Makefile에 설정할 수 있습니다. 기본 이미지 이름을 설정하려면 IMG ?= controller:latest 값을 수정합니다.

  2. 다음 명령을 실행하여 Operator를 배포합니다.

    $ make deploy IMG=<registry>/<user>/<image_name>:<tag>

    기본적으로 이 명령은 <project_name>-system 형식으로 된 Operator 프로젝트 이름을 사용하여 네임스페이스를 생성하고 배포에 사용됩니다. 이 명령은 또한 config/rbac에서 RBAC 매니페스트를 설치합니다.

  3. 다음 명령을 실행하여 Operator가 실행 중인지 확인합니다.

    $ oc get deployment -n <project_name>-system

    출력 예

    NAME                                    READY   UP-TO-DATE   AVAILABLE   AGE
    <project_name>-controller-manager       1/1     1            1           8m

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

Operator가 설치되면 Operator에서 현재 클러스터에 제공하는 CR(사용자 정의 리소스)을 생성하여 Operator를 테스트할 수 있습니다.

프로세스

  1. Operator가 설치된 네임스페이스로 변경합니다.

    $ oc project <project_name>-system
  2. replicaCount 필드를 3 으로 업데이트하여 config/samples/cache_v1_memcached.yaml 파일에서 샘플 Memcached CR 매니페스트를 업데이트합니다.

    예 5.8. Example config/samples/cache_v1_memcached.yaml file

    apiVersion: cache.my.domain/v1
    kind: Memcached
    metadata:
      name: memcached-sample
    spec:
      # Default values copied from <project_dir>/helm-charts/memcached/values.yaml
      affinity: {}
      autoscaling:
        enabled: false
        maxReplicas: 100
        minReplicas: 1
        targetCPUUtilizationPercentage: 80
      fullnameOverride: ""
      image:
        pullPolicy: IfNotPresent
        repository: nginx
        tag: ""
      imagePullSecrets: []
      ingress:
        annotations: {}
        className: ""
        enabled: false
        hosts:
        - host: chart-example.local
          paths:
          - path: /
            pathType: ImplementationSpecific
        tls: []
      nameOverride: ""
      nodeSelector: {}
      podAnnotations: {}
      podSecurityContext: {}
      replicaCount: 3
      resources: {}
      securityContext: {}
      service:
        port: 80
        type: ClusterIP
      serviceAccount:
        annotations: {}
        create: true
        name: ""
      tolerations: []
  3. Memcached CR을 생성합니다.

    $ oc apply -f config/samples/cache_v1_memcached.yaml
  4. Memcached Operator가 샘플 CR에 대한 배포를 올바른 크기로 생성하는지 확인합니다.

    $ oc get pods

    출력 예

    NAME                                  READY     STATUS    RESTARTS   AGE
    memcached-sample-6fd7c98d8-7dqdr      1/1       Running   0          18m
    memcached-sample-6fd7c98d8-g5k7v      1/1       Running   0          18m
    memcached-sample-6fd7c98d8-m7vn7      1/1       Running   0          18m

  5. 크기를 2 로 업데이트하여 config/samples/cache_v1_memcachedbackup.yaml 파일에서 샘플 MemcachedBackup CR 매니페스트를 업데이트합니다.

    예 5.9. Example config/samples/cache_v1_memcachedbackup.yaml file

    apiVersion: cache.my.domain/v1
    kind: MemcachedBackup
    metadata:
      name: memcachedbackup-sample
    spec:
      size: 2
  6. MemcachedBackup CR을 생성합니다.

    $ oc apply -f config/samples/cache_v1_memcachedbackup.yaml
  7. memcachedbackup Pod 수가 CR에 지정된 것과 동일한지 확인합니다.

    $ oc get pods

    출력 예

    NAME                                        READY     STATUS    RESTARTS   AGE
    memcachedbackup-sample-8649699989-4bbzg     1/1       Running   0          22m
    memcachedbackup-sample-8649699989-mq6mx     1/1       Running   0          22m

  8. 위의 각 CR에서 사양 을 업데이트한 다음 다시 적용할 수 있습니다. 컨트롤러가 다시 조정되고 Pod 크기가 해당 CR의 사양에 지정된 대로 있는지 확인합니다.
  9. 이 튜토리얼의 일부로 생성된 리소스를 정리합니다.

    1. Memcached 리소스를 삭제합니다.

      $ oc delete -f config/samples/cache_v1_memcached.yaml
    2. MemcachedBackup 리소스를 삭제합니다.

      $ oc delete -f config/samples/cache_v1_memcachedbackup.yaml
    3. make deploy 명령을 사용하여 Operator를 테스트한 경우 다음 명령을 실행합니다.

      $ make undeploy

5.5.6.8. 프로젝트 레이아웃

Hybrid Helm Operator 스캐폴딩은 Helm 및 Go API와 호환되도록 사용자 지정됩니다.

파일/폴더목적

Dockerfile

make docker-build 명령을 사용하여 컨테이너 엔진에서 Operator 이미지를 빌드하는 데 사용하는 지침입니다.

Makefile

프로젝트 작업에 도움이 되도록 도우미 대상으로 파일을 빌드합니다.Build file with helper targets to help you work with your project.

PROJECT

Operator의 메타데이터 정보가 포함된 YAML 파일입니다. 프로젝트의 구성을 나타내며 CLI 및 플러그인에 대한 유용한 정보를 추적하는 데 사용됩니다.

bin/

로컬에서 프로젝트를 실행하는 데 사용되는 관리자 및 프로젝트 구성에 사용되는 kustomize 유틸리티와 같은 유용한 바이너리가 포함되어 있습니다.

config/

클러스터에서 Operator 프로젝트를 시작하기 위해 모든 Kustomize 매니페스트를 포함한 구성 파일이 포함되어 있습니다. 플러그인을 사용하여 기능을 제공할 수 있습니다. 예를 들어 Operator 번들을 생성하는 데 도움이 되는 Operator SDK의 경우 CLI는 이 디렉터리에 스캐폴드된 CRD 및 CR을 조회합니다.

config/crd/
CRD(사용자 정의 리소스 정의)가 포함되어 있습니다.
config/default/
컨트롤러를 표준 구성으로 시작하기 위한 Kustomize 기반이 포함되어 있습니다.
config/manager/
Operator 프로젝트를 클러스터에서 Pod로 시작하는 매니페스트를 포함합니다.
config/manifests/
bundle/ 디렉터리에 OLM 매니페스트를 생성하는 기반을 포함합니다.
config/prometheus/
ServiceMonitor 리소스와 같은 Prometheus에 프로젝트를 제공하는 데 필요한 매니페스트를 포함합니다.
config/scorecard/
스코어 카드 툴로 프로젝트를 테스트할 수 있도록 하는 데 필요한 매니페스트가 포함되어 있습니다.
config/rbac/
프로젝트를 실행하는 데 필요한 RBAC 권한이 포함되어 있습니다.
config/samples/
사용자 정의 리소스에 대한 샘플을 포함합니다.

api/

Go API 정의를 포함합니다.

internal/controllers/

Go API의 컨트롤러를 포함합니다.

#159/

프로젝트 파일의 라이센스 헤더를 스캐폴드하는 데 사용되는 파일과 같은 유틸리티 파일을 포함합니다.

main.go

Operator의 기본 프로그램으로, apis/ 디렉터리에 모든 CRD(사용자 정의 리소스 정의)를 등록하고 controllers/ 디렉터리의 모든 컨트롤러를 시작하는 새 관리자를 인스턴스화합니다.

helm-charts/

Helm 플러그인과 함께 create api 명령을 사용하여 지정할 수 있는 Helm 차트를 포함합니다.

watches.yaml

GVK(그룹/버전/종류) 및 Helm 차트 위치를 포함합니다. Helm 감시를 구성하는 데 사용됩니다.

5.5.7. 최신 Operator SDK 버전을 위한 하이브리드 Helm 기반 프로젝트 업데이트

OpenShift Container Platform 4.17은 Operator SDK 1.36.1을 지원합니다. 워크스테이션에 1.31.0 CLI가 이미 설치되어 있는 경우 최신 버전을 설치하여 CLI를 1.36.1으로 업데이트할 수 있습니다.

중요

Operator 프로젝트의 관련 스캐폴딩 및 테스트 툴을 포함한 Red Hat 지원 버전의 Operator SDK CLI 툴은 더 이상 사용되지 않으며 향후 OpenShift Container Platform 릴리스에서 제거될 예정입니다. Red Hat은 현재 릴리스 라이프사이클 동안 이 기능에 대한 버그 수정 및 지원을 제공하지만 이 기능은 더 이상 개선 사항을 받지 않으며 향후 OpenShift Container Platform 릴리스에서 제거됩니다.

새 Operator 프로젝트를 생성하는 데 Red Hat 지원 버전의 Operator SDK는 권장되지 않습니다. 기존 Operator 프로젝트가 있는 Operator 작성자는 OpenShift Container Platform 4.17과 함께 릴리스된 Operator SDK CLI 툴 버전을 사용하여 프로젝트를 유지 관리하고 최신 버전의 OpenShift Container Platform을 대상으로 하는 Operator 릴리스를 생성할 수 있습니다.

Operator 프로젝트의 다음과 같은 관련 기본 이미지는 더 이상 사용되지 않습니다. 이러한 기본 이미지의 런타임 기능 및 구성 API는 버그 수정 및 CVE 문제를 해결하는 데 계속 지원됩니다.

  • Ansible 기반 Operator 프로젝트의 기본 이미지
  • Helm 기반 Operator 프로젝트의 기본 이미지

OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.

지원되지 않는 커뮤니티 유지 관리 버전에 대한 자세한 내용은 Operator SDK(Operator Framework) 를 참조하십시오.

그러나 기존 Operator 프로젝트에서 Operator SDK 1.36.1과의 호환성을 유지하려면 1.31.0 이후의 중단된 변경 사항에 대한 업데이트 단계가 필요합니다. 1.31.0을 사용하여 이전에 생성되거나 유지 관리되는 Operator 프로젝트에서 업데이트 단계를 수동으로 수행해야 합니다.

5.5.7.1. Operator SDK 1.36.1의 하이브리드 Helm 기반 Operator 프로젝트 업데이트

다음 절차에서는 1.36.1과의 호환성을 위해 기존 하이브리드 Helm 기반 Operator 프로젝트를 업데이트합니다.

사전 요구 사항

  • Operator SDK 1.36.1 설치
  • Operator SDK 1.31.0을 사용하여 생성되거나 유지 관리되는 Operator 프로젝트

프로세스

  1. 다음 예와 같이 Operator 프로젝트의 Makefile을 편집하여 Operator SDK 버전을 v1.36.1-ocp 로 업데이트합니다.

    Makefile의 예

    # Set the Operator SDK version to use. By default, what is installed on the system is used.
    # This is useful for CI or a project to utilize a specific version of the operator-sdk toolkit.
    OPERATOR_SDK_VERSION ?= v1.36.1-ocp

  2. RHEL(Red Hat Enterprise Linux) 9 기반 이미지를 사용하도록 kube-rbac-proxy 컨테이너를 업데이트합니다.

    1. 다음 파일에서 kube-rbac-proxy 컨테이너 항목을 찾습니다.

      • config/default/manager_auth_proxy_patch.yaml
      • Operator 프로젝트의 bundle/manifests/<operator_name>.clusterserviceversion.yaml (예: 튜토리얼의 memcached-operator.clusterserviceversion.yaml )
    2. ose-kube-rbac-proxy에서 ose-kube-rbac-proxy -rhel9 로 가져오기 사양의 이미지 이름을 업데이트하고 태그를 v4.17 으로 업데이트합니다.

      v4.17 이미지 태그가 있는 ose-kube-rbac-proxy-rhel9 풀 사양의 예

      # ...
            containers:
            - name: kube-rbac-proxy
              image: registry.redhat.io/openshift4/ose-kube-rbac-proxy-rhel9:v4.17
      # ...

  3. 이제 Go /v4 플러그인이 안정적이며 Go 기반 Operator를 스캐폴드할 때 사용되는 기본 버전입니다. Golang v2 및 v3 플러그인에서 새로운 Golang v4 플러그인으로 전환하면 상당한 변경 사항이 추가되었습니다. 이 마이그레이션은 Golang 개발의 진화하는 환경을 반영하여 프로젝트의 기능과 호환성을 개선하도록 설계되었습니다.

    이러한 변경 사항의 추론에 대한 자세한 내용은 Kubebuilder 설명서의 go/v3 vs go/v4 를 참조하십시오.

    v4 플러그인 형식으로의 마이그레이션 프로세스 및 자세한 마이그레이션 단계를 포괄적으로 이해하려면 Kubebuilder 문서에서 수동으로 파일을 업데이트하여 이동/v3에서 go/v4로 마이그레이션을 참조하십시오.

  4. kustomize/v2 플러그인은 이제 안정적인 상태이며 go/v4,ansible/v1,helm/v1, hybrid/v1-alpha 플러그인을 사용할 때 플러그인 체인에 사용되는 기본 버전입니다. 이 기본 스캐폴드에 대한 자세한 내용은 Kubebuilder 설명서의 Kustomize v2 를 참조하십시오.
  5. Operator 프로젝트에서 다중 플랫폼 또는 다중 아키텍처, 빌드를 사용하는 경우 기존 docker-buildx 대상을 프로젝트 Makefile의 다음 정의로 교체합니다.

    Makefile의 예

    docker-buildx:
    ## Build and push the Docker image for the manager for multi-platform support
    	- docker buildx create --name project-v3-builder
    	docker buildx use project-v3-builder
    	- docker buildx build --push --platform=$(PLATFORMS) --tag ${IMG} -f Dockerfile .
    	- docker buildx rm project-v3-builder

  6. 1.29를 사용하려면 Operator 프로젝트의 Kubernetes 버전을 업그레이드해야 합니다. 프로젝트 구조, Makefile 및 go.mod 파일을 다음과 같이 변경해야 합니다.

    중요

    Go/v3 플러그인은 Kubebuilder에서 더 이상 사용되지 않으므로 Operator SDK도 향후 릴리스에서 go/v4 로 마이그레이션되고 있습니다.

    1. go.mod 파일을 업데이트하여 종속 항목을 업그레이드합니다.

      k8s.io/api v0.29.2
      k8s.io/apimachinery v0.29.2
      k8s.io/client-go v0.29.2
      sigs.k8s.io/controller-runtime v0.17.3
    2. 다음 명령을 실행하여 업그레이드된 종속 항목을 다운로드합니다.

      $ go mod tidy

5.5.7.2. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.