5.6. Helm 기반 Operator
5.6.1. Helm 기반 Operator를 위한 Operator SDK 시작하기
Operator SDK에는 Go 코드를 작성하지 않고도 기존 Helm 차트를 활용하여 Kubernetes 리소스를 통합 애플리케이션으로 배포하는 Operator 프로젝트를 생성하는 옵션이 포함되어 있습니다.
Operator 개발자는 Operator SDK에서 제공하는 툴 및 라이브러리를 사용하여 Helm 기반 Operator를 설정 및 실행하는 기본 동작을 설명하기 위해 Nginx에 대한 Helm 기반 Operator 예제를 빌드하고 클러스터에 배포할 수 있습니다.
5.6.1.1. 사전 요구 사항
- Operator SDK CLI가 설치됨
-
OpenShift CLI(
oc
) v4.8 이상이 설치됨 -
cluster-admin
권한이 있는 계정으로oc
를 사용하여 OpenShift Container Platform 4.8 클러스터에 로그인함 - 클러스터에서 이미지를 가져올 수 있도록 하려면 이미지를 내보내는 리포지토리를 공개로 설정하거나 이미지 가져오기 보안을 구성해야 합니다.
5.6.1.2. Helm 기반 Operator 생성 및 배포
Operator SDK를 사용하여 Nginx에 대한 간단한 Helm 기반 Operator를 빌드하고 배포할 수 있습니다.
프로세스
프로젝트를 생성합니다.
프로젝트 디렉토리를 생성합니다.
$ mkdir nginx-operator
프로젝트 디렉터리로 변경합니다.
$ cd nginx-operator
helm
플러그인과 함께operator-sdk init
명령을 실행하여 프로젝트를 초기화합니다.$ operator-sdk init \ --plugins=helm
API를 생성합니다.
간단한 Nginx API를 생성합니다.
$ operator-sdk create api \ --group demo \ --version v1 \ --kind Nginx
이 API는
helm create
명령의 기본 제공 Helm 차트 상용구를 사용합니다.Operator 이미지를 빌드하여 내보냅니다.
기본
Makefile
대상을 사용하여 Operator를 빌드하고 내보냅니다. 내보낼 수 있는 레지스트리를 사용하는 이미지의 가져오기 사양에IMG
를 설정합니다.$ make docker-build docker-push IMG=<registry>/<user>/<image_name>:<tag>
Operator를 실행합니다.
CRD를 설치합니다.
$ make install
클러스터에 프로젝트를 배포합니다. 내보낸 이미지에
IMG
를 설정합니다.$ make deploy IMG=<registry>/<user>/<image_name>:<tag>
SCC(보안 컨텍스트 제약 조건)를 추가합니다.
Nginx 서비스 계정에는 OpenShift Container Platform에서 실행할 수 있는 권한이 필요합니다.
nginx-sample
Pod의 서비스 계정에 다음 SCC를 추가합니다.$ oc adm policy add-scc-to-user \ anyuid system:serviceaccount:nginx-operator-system:nginx-sample
샘플 CR(사용자 정의 리소스)을 생성합니다.
샘플 CR을 생성합니다.
$ oc apply -f config/samples/demo_v1_nginx.yaml \ -n nginx-operator-system
CR에서 Operator를 조정하는지 확인합니다.
$ oc logs deployment.apps/nginx-operator-controller-manager \ -c manager \ -n nginx-operator-system
정리합니다.
다음 명령을 실행하여 이 절차의 일부로 생성된 리소스를 정리합니다.
$ make undeploy
5.6.1.3. 다음 단계
- helm 기반 Operator를 빌드하는 방법에 대한 자세한 내용은 helm 기반 Operator를 위한 Operator SDK 튜토리얼을 참조하십시오.
5.6.2. helm 기반 Operator를 위한 Operator SDK 튜토리얼
Operator 개발자는 Operator SDK에서 Helm 지원을 활용하여 Nginx에 대한 Helm 기반 Operator 예제를 빌드하고 라이프사이클을 관리할 수 있습니다. 이 튜토리얼에서는 다음 프로세스를 안내합니다.
- Nginx 배포 생성
-
배포 크기가
Nginx
CR(사용자 정의 리소스) 사양에 지정된 것과 같은지 확인합니다. -
상태 작성기를 사용하여
Nginx
CR 상태를nginx
Pod의 이름으로 업데이트합니다.
이 프로세스는 Operator 프레임워크의 두 가지 주요 요소를 사용하여 수행됩니다.
- Operator SDK
-
operator-sdk
CLI 툴 및controller-runtime
라이브러리 API - OLM(Operator Lifecycle Manager)
- 클러스터에 대한 Operator의 설치, 업그레이드, RBAC(역할 기반 액세스 제어)
이 튜토리얼에는 Helm 기반 Operator용 Operator SDK 시작하기보다 자세히 설명되어 있습니다.
5.6.2.1. 사전 요구 사항
- Operator SDK CLI가 설치됨
-
OpenShift CLI(
oc
) v4.8 이상이 설치됨 -
cluster-admin
권한이 있는 계정으로oc
를 사용하여 OpenShift Container Platform 4.8 클러스터에 로그인함 - 클러스터에서 이미지를 가져올 수 있도록 하려면 이미지를 내보내는 리포지토리를 공개로 설정하거나 이미지 가져오기 보안을 구성해야 합니다.
5.6.2.2. 프로젝트 생성
Operator SDK CLI를 사용하여 nginx-operator
라는 프로젝트를 생성합니다.
프로세스
프로젝트에 사용할 디렉터리를 생성합니다.
$ mkdir -p $HOME/projects/nginx-operator
디렉터리로 변경합니다.
$ cd $HOME/projects/nginx-operator
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
프로젝트를 생성합니다.-
Helm 기반 프로젝트의 경우
init
명령은 차트의 기본 매니페스트에 의해 배포되는 리소스를 기반으로config/rbac/role.yaml
파일에 RBAC 규칙을 생성합니다. 이 파일에 생성된 규칙이 Operator의 권한 요구 사항을 충족하는지 확인합니다.
5.6.2.2.1. 기존 Helm 차트
상용구 Helm 차트로 프로젝트를 생성하는 대신 다음 플래그를 사용하여 로컬 파일 시스템 또는 원격 차트 리포지토리에서 기존 차트를 사용할 수 있습니다.
-
--helm-chart
-
--helm-chart-repo
-
--helm-chart-version
--helm-chart
플래그가 지정되면 --group
, --version
, --kind
플래그가 선택 사항이 됩니다. 설정되지 않으면 다음 기본값이 사용됩니다.
플래그 | 값 |
---|---|
|
|
|
|
|
|
| 지정된 차트에서 추론됨 |
--helm-chart
플래그가 로컬 차트 아카이브(예: example-chart-1.2.0.tgz
또는 디렉터리)를 지정하는 경우 차트를 검증하고 압축을 풀거나 프로젝트에 복사합니다. 그러지 않으면 Operator SDK가 원격 리포지토리에서 차트를 가져옵니다.
--helm-chart-repo
플래그로 사용자 정의 리포지토리 URL이 지정되지 않는 경우 다음 차트 참조 형식이 지원됩니다.
형식 | 설명 |
---|---|
|
|
| 지정된 URL에서 Helm 차트 아카이브를 가져옵니다. |
사용자 정의 리포지토리 URL이 --helm-chart-repo
로 지정된 경우 다음 차트 참조 형식이 지원됩니다.
형식 | 설명 |
---|---|
|
|
--helm-chart-version
플래그를 설정하지 않으면 Operator SDK에서 사용 가능한 최신 버전의 Helm 차트를 가져옵니다. 그러지 않으면 지정된 버전을 가져옵니다. --helm-chart
플래그로 지정한 차트에서 특정 버전을 참조하는 경우(예: 로컬 경로 또는 URL) 선택적 --helm-chart-version
플래그는 사용되지 않습니다.
자세한 내용 및 예를 보려면 다음을 실행합니다.
$ operator-sdk init --plugins helm --help
5.6.2.2.2. PROJECT 파일
operator-sdk init
명령으로 생성된 파일 중에는 Kubebuilder PROJECT
파일이 있습니다. 이어서 프로젝트 루트에서 실행되는 operator-sdk
명령과 help
출력에서는 이 파일을 읽고 프로젝트 유형이 Helm임을 확인합니다. 예를 들면 다음과 같습니다.
domain: example.com layout: helm.sdk.operatorframework.io/v1 projectName: helm-operator resources: - group: demo kind: Nginx version: v1 version: 3
5.6.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.6.2.3.1. 샘플 Helm 차트
Helm Operator 프로젝트가 생성되면 Operator SDK는 간단한 Nginx 릴리스에 대한 일련의 템플릿이 포함된 샘플 Helm 차트를 생성합니다.
이 예제에서는 Helm 차트 개발자가 릴리스에 대한 유용한 정보를 전달하는 데 사용하는 NOTES.txt
템플릿과 함께 배포, 서비스, 수신 리소스에 대해 템플릿을 사용할 수 있습니다.
Helm 차트에 대해 잘 모르는 경우 Helm 개발자 설명서를 검토하십시오.
5.6.2.3.2. 사용자 정의 리소스 사양 수정
Helm은 값이라는 개념을 사용하여 values.yaml
파일에 정의된 Helm 차트 기본값에 대한 사용자 정의 기능을 제공합니다.
CR(사용자 정의 리소스) 사양에 원하는 값을 설정하여 이러한 기본값을 덮어쓸 수 있습니다. 예를 들어 복제본 수를 사용할 수 있습니다.
프로세스
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
마찬가지로 기본 서비스 포트는
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.6.2.4. Operator 실행
다음 세 가지 방법으로 Operator SDK CLI를 사용하여 Operator를 빌드하고 실행할 수 있습니다.
- Go 프로그램으로 클러스터 외부에서 로컬로 실행합니다.
- 클러스터에서 배포로 실행합니다.
- Operator를 번들로 제공하고 OLM(Operator Lifecycle Manager)을 사용하여 클러스터에 배포합니다.
5.6.2.4.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.6.2.4.2. 클러스터에서 배포로 실행
Operator 프로젝트를 클러스터에서 배포로 실행할 수 있습니다.
프로세스
다음
make
명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서IMG
인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.이미지를 빌드합니다.
$ make docker-build IMG=<registry>/<user>/<image_name>:<tag>
참고Operator에 대해 SDK에서 생성한 Dockerfile은
Go 빌드
를 위해GOARCH=amd64
를 명시적으로 참조합니다. 이는AMD64 이외의 아키텍처의 경우GOARCH=$CACHEGETARCH
에 수정될 수 있습니다. Docker는 환경 변수를-platform
에서 지정한 값으로 자동 설정합니다. Buildah를 사용하면-build-arg
를 목적으로 사용해야 합니다. 자세한 내용은 여러 아키텍처를 참조하십시오.이미지를 리포지토리로 내보냅니다.
$ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
참고두 명령 모두 이미지의 이름과 태그(예:
IMG=<registry>/<user>/<image_name>:<tag>
)를 Makefile에 설정할 수 있습니다. 기본 이미지 이름을 설정하려면IMG ?= controller:latest
값을 수정합니다.
다음 명령을 실행하여 Operator를 배포합니다.
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>
기본적으로 이 명령은
<project_name>-system
형식으로 된 Operator 프로젝트 이름을 사용하여 네임스페이스를 생성하고 배포에 사용됩니다. 이 명령은 또한config/rbac
에서 RBAC 매니페스트를 설치합니다.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.6.2.4.3. Operator 번들링 및 Operator Lifecycle Manager를 통한 배포
5.6.2.4.3.1. Operator 번들
Operator 번들 형식은 Operator SDK 및 Operator Lifecycle Manager (OLM)의 기본 패키지 메서드입니다. Operator SDK를 사용하여 Operator 프로젝트를 번들 이미지로 빌드하고 푸시하여 OLM에서 Operator를 사용할 수 있습니다.
사전 요구 사항
- 개발 워크스테이션에 Operator SDK CLI가 설치됨
-
OpenShift CLI (
oc
) v4.8+ 설치됨 - Operator SDK를 사용하여 Operator 프로젝트를 초기화함
프로세스
Operator 프로젝트 디렉터리에서 다음
make
명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서IMG
인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.이미지를 빌드합니다.
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
참고Operator에 대해 SDK에서 생성한 Dockerfile은
Go 빌드
를 위해GOARCH=amd64
를 명시적으로 참조합니다. 이는AMD64 이외의 아키텍처의 경우GOARCH=$CACHEGETARCH
에 수정될 수 있습니다. Docker는 환경 변수를-platform
에서 지정한 값으로 자동 설정합니다. Buildah를 사용하면-build-arg
를 목적으로 사용해야 합니다. 자세한 내용은 여러 아키텍처를 참조하십시오.이미지를 리포지토리로 내보냅니다.
$ make docker-push IMG=<registry>/<user>/<operator_image_name>:<tag>
Operator SDK
generate bundle
및bundle 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
를 사용하여 이러한 파일을 자동으로 검증하고 디스크상의 번들 표현이 올바른지 확인합니다.-
다음 명령을 실행하여 번들 이미지를 빌드하고 내보냅니다. OLM에서는 하나 이상의 번들 이미지를 참조하는 인덱스 이미지를 통해 Operator 번들을 사용합니다.
번들 이미지를 빌드합니다. 이미지를 내보낼 레지스트리, 사용자 네임스페이스, 이미지 태그에 대한 세부 정보를 사용하여
BUNDLE_IMG
를 설정합니다.$ make bundle-build BUNDLE_IMG=<registry>/<user>/<bundle_image_name>:<tag>
번들 이미지를 내보냅니다.
$ docker push <registry>/<user>/<bundle_image_name>:<tag>
5.6.2.4.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.8)를 사용하는 경우 v1.16.0 이상) -
cluster-admin
권한이 있는 계정을 사용하여oc
로 클러스터에 로그인됨
절차
다음 명령을 입력하여 클러스터에서 Operator를 실행합니다.
$ operator-sdk run bundle \ [-n <namespace>] \1 <registry>/<user>/<bundle_image_name>:<tag>
- 1
- 기본적으로 이 명령은 현재 활성 프로젝트의
~/.kube/config
파일에 Operator를 설치합니다.-n
플래그를 추가하면 설치에 다른 네임스페이스 범위를 설정할 수 있습니다.
이 명령은 다음 작업을 수행합니다.
- 번들 이미지를 참조하는 인덱스 이미지를 생성합니다. 인덱스 이미지는 불투명하고 일시적이지만 프로덕션에서 카탈로그에 번들을 추가하는 방법을 정확하게 반영합니다.
- OperatorHub에서 Operator를 검색할 수 있도록 새 인덱스 이미지를 가리키는 카탈로그 소스를 생성합니다.
-
OperatorGroup
,Subscription
,InstallPlan
및 RBAC를 포함한 기타 모든 필수 오브젝트를 생성하여 Operator를 클러스터에 배포합니다.
5.6.2.5. 사용자 정의 리소스 생성
Operator가 설치되면 Operator에서 현재 클러스터에 제공하는 CR(사용자 정의 리소스)을 생성하여 Operator를 테스트할 수 있습니다.
사전 요구 사항
-
Nginx
CR을 제공하는 Nginx Operator 예제가 클러스터에 설치되어 있음
프로세스
Operator가 설치된 네임스페이스로 변경합니다. 예를 들어
make deploy
명령을 사용하여 Operator를 배포한 경우 다음을 실행합니다.$ oc project nginx-operator-system
다음 사양을 포함하도록
config/samples/demo_v1_nginx.yaml
에서 샘플Nginx
CR 매니페스트를 편집합니다.apiVersion: demo.example.com/v1 kind: Nginx metadata: name: nginx-sample ... spec: ... replicaCount: 3
Nginx 서비스 계정에는 OpenShift Container Platform에서 실행할 수 있는 권한이 필요합니다.
nginx-sample
Pod의 서비스 계정에 다음 SCC(보안 컨텍스트 제약 조건)를 추가합니다.$ oc adm policy add-scc-to-user \ anyuid system:serviceaccount:nginx-operator-system:nginx-sample
CR을 생성합니다.
$ oc apply -f config/samples/demo_v1_nginx.yaml
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
Pod 및 CR 상태를 확인하여 상태가 Nginx Pod 이름으로 업데이트되었는지 확인합니다.
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
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
배포 크기를 업데이트합니다.
config/samples/demo_v1_nginx.yaml
파일을 업데이트하여Nginx
CR의spec.size
필드를3
에서5
로 변경합니다.$ oc patch nginx nginx-sample \ -p '{"spec":{"replicaCount": 5}}' \ --type=merge
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
이 튜토리얼의 일부로 생성된 리소스를 정리합니다.
make deploy
명령을 사용하여 Operator를 테스트한 경우 다음 명령을 실행합니다.$ make undeploy
operator-sdk run bundle
명령을 사용하여 Operator를 테스트한 경우 다음 명령을 실행합니다.$ operator-sdk cleanup <project_name>
5.6.2.6. 추가 리소스
- Operator SDK에서 생성한 디렉터리 구조에 대한 자세한 내용은 Helm 기반 Operator의 프로젝트 레이아웃을 참조하십시오.
5.6.3. Helm 기반 Operator의 프로젝트 레이아웃
operator-sdk
CLI에서는 각 Operator 프로젝트에 대해 다양한 패키지 및 파일을 생성하거나 스캐폴드를 지정할 수 있습니다.
5.6.3.1. Helm 기반 프로젝트 레이아웃
operator-sdk init --plugins helm
명령을 사용하여 생성된 Helm 기반 Operator 프로젝트에는 다음 디렉터리 및 파일이 포함됩니다.
파일/폴더 | 목적 |
---|---|
| Kubernetes 클러스터에 Operator를 배포하는 Kustomize 매니페스트입니다. |
|
|
|
|
| GVK(그룹/버전/종류) 및 Helm 차트 위치입니다. |
| 프로젝트 관리에 사용되는 대상입니다. |
| Operator의 메타데이터 정보가 포함된 YAML 파일입니다. |
5.6.4. Operator SDK의 Helm 지원
5.6.4.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를 준수하기 때문에 프로덕션이 변경되는 것을 더 쉽게 방지할 수 있습니다.