5.6.
5.6.1.
기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.
5.6.1.1. 사전 요구 사항
- Operator SDK CLI가 설치됨
5.6.1.2.
프로세스
프로젝트를 생성합니다.
프로젝트 디렉토리를 생성합니다.
$ mkdir memcached-operator
프로젝트 디렉터리로 변경합니다.
$ cd memcached-operator
$ operator-sdk init \ --plugins=quarkus \ --domain=example.com \ --project-name=memcached-operator
API를 생성합니다.
간단한 Memcached API를 생성합니다.
$ operator-sdk create api \ --plugins quarkus \ --group cache \ --version v1 \ --kind Memcached
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>
샘플 CR(사용자 정의 리소스)을 생성합니다.
샘플 CR을 생성합니다.
$ oc apply -f config/samples/cache_v1_memcached.yaml \ -n memcached-operator-system
CR에서 Operator를 조정하는지 확인합니다.
$ oc logs deployment.apps/memcached-operator-controller-manager \ -c manager \ -n memcached-operator-system
$ oc delete -f config/samples/cache_v1_memcached.yaml -n memcached-operator-system
정리합니다.
다음 명령을 실행하여 이 절차의 일부로 생성된 리소스를 정리합니다.
$ make undeploy
5.6.1.3. 다음 단계
5.6.2.
기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
OpenShift Container Platform에서 더 이상 사용되지 않거나 삭제된 주요 기능의 최신 목록은 OpenShift Container Platform 릴리스 노트에서 더 이상 사용되지 않고 삭제된 기능 섹션을 참조하십시오.
이 프로세스는 Operator 프레임워크의 두 가지 주요 요소를 사용하여 수행됩니다.
- Operator SDK
- OLM(Operator Lifecycle Manager)
- 클러스터에 대한 Operator의 설치, 업그레이드, RBAC(역할 기반 액세스 제어)
5.6.2.1. 사전 요구 사항
- Operator SDK CLI가 설치됨
5.6.2.2. 프로젝트 생성
Operator SDK CLI를 사용하여 memcached-operator
라는 프로젝트를 생성합니다.
프로세스
프로젝트에 사용할 디렉터리를 생성합니다.
$ mkdir -p $HOME/projects/memcached-operator
디렉터리로 변경합니다.
$ cd $HOME/projects/memcached-operator
$ operator-sdk init \ --plugins=quarkus \ --domain=example.com \ --project-name=memcached-operator
5.6.2.2.1. PROJECT 파일
operator-sdk init
명령으로 생성된 파일 중에는 Kubebuilder PROJECT
파일이 있습니다. 예를 들면 다음과 같습니다.
domain: example.com layout: - quarkus.javaoperatorsdk.io/v1-alpha projectName: memcached-operator version: "3"
5.6.2.3. API 및 컨트롤러 생성
Operator SDK CLI를 사용하여 CRD(사용자 정의 리소스 정의) API 및 컨트롤러를 생성합니다.
프로세스
$ operator-sdk create api \ --plugins=quarkus \1 --group=cache \2 --version=v1 \3 --kind=Memcached 4
검증
$ tree
출력 예
. ├── Makefile ├── PROJECT ├── pom.xml └── src └── main ├── java │ └── com │ └── example │ ├── Memcached.java │ ├── MemcachedReconciler.java │ ├── MemcachedSpec.java │ └── MemcachedStatus.java └── resources └── application.properties 6 directories, 8 files
5.6.2.3.1. API 정의
Memcached
CR(사용자 정의 리소스)의 API를 정의합니다.
프로세스
public class MemcachedSpec { private Integer size; public Integer getSize() { return size; } public void setSize(Integer size) { this.size = size; } }
- 참고
import java.util.ArrayList; import java.util.List; public class MemcachedStatus { // Add Status information here // Nodes are the names of the memcached pods private List<String> nodes; public List<String> getNodes() { if (nodes == null) { nodes = new ArrayList<>(); } return nodes; } public void setNodes(List<String> nodes) { this.nodes = nodes; } }
@Version("v1") @Group("cache.example.com") public class Memcached extends CustomResource<MemcachedSpec, MemcachedStatus> implements Namespaced {}
5.6.2.3.2. CRD 매니페스트 생성
프로세스
$ mvn clean install
검증
$ cat target/kubernetes/memcacheds.cache.example.com-v1.yaml
출력 예
# Generated by Fabric8 CRDGenerator, manual edits might get overwritten! apiVersion: apiextensions.k8s.io/v1 kind: CustomResourceDefinition metadata: name: memcacheds.cache.example.com spec: group: cache.example.com names: kind: Memcached plural: memcacheds singular: memcached scope: Namespaced versions: - name: v1 schema: openAPIV3Schema: properties: spec: properties: size: type: integer type: object status: properties: nodes: items: type: string type: array type: object type: object served: true storage: true subresources: status: {}
5.6.2.3.3.
프로세스
apiVersion: cache.example.com/v1 kind: Memcached metadata: name: memcached-sample spec: # Add spec fields here size: 1
5.6.2.4. 컨트롤러 구현
새 API 및 컨트롤러를 생성하면 컨트롤러 논리를 구현할 수 있습니다.
프로세스
<dependency> <groupId>commons-collections</groupId> <artifactId>commons-collections</artifactId> <version>3.2.2</version> </dependency>
예 5.10.
package com.example; import io.fabric8.kubernetes.client.KubernetesClient; import io.javaoperatorsdk.operator.api.reconciler.Context; import io.javaoperatorsdk.operator.api.reconciler.Reconciler; import io.javaoperatorsdk.operator.api.reconciler.UpdateControl; import io.fabric8.kubernetes.api.model.ContainerBuilder; import io.fabric8.kubernetes.api.model.ContainerPortBuilder; import io.fabric8.kubernetes.api.model.LabelSelectorBuilder; import io.fabric8.kubernetes.api.model.ObjectMetaBuilder; import io.fabric8.kubernetes.api.model.OwnerReferenceBuilder; import io.fabric8.kubernetes.api.model.Pod; import io.fabric8.kubernetes.api.model.PodSpecBuilder; import io.fabric8.kubernetes.api.model.PodTemplateSpecBuilder; import io.fabric8.kubernetes.api.model.apps.Deployment; import io.fabric8.kubernetes.api.model.apps.DeploymentBuilder; import io.fabric8.kubernetes.api.model.apps.DeploymentSpecBuilder; import org.apache.commons.collections.CollectionUtils; import java.util.HashMap; import java.util.List; import java.util.Map; import java.util.stream.Collectors; public class MemcachedReconciler implements Reconciler<Memcached> { private final KubernetesClient client; public MemcachedReconciler(KubernetesClient client) { this.client = client; } // TODO Fill in the rest of the reconciler @Override public UpdateControl<Memcached> reconcile( Memcached resource, Context context) { // TODO: fill in logic Deployment deployment = client.apps() .deployments() .inNamespace(resource.getMetadata().getNamespace()) .withName(resource.getMetadata().getName()) .get(); if (deployment == null) { Deployment newDeployment = createMemcachedDeployment(resource); client.apps().deployments().create(newDeployment); return UpdateControl.noUpdate(); } int currentReplicas = deployment.getSpec().getReplicas(); int requiredReplicas = resource.getSpec().getSize(); if (currentReplicas != requiredReplicas) { deployment.getSpec().setReplicas(requiredReplicas); client.apps().deployments().createOrReplace(deployment); return UpdateControl.noUpdate(); } List<Pod> pods = client.pods() .inNamespace(resource.getMetadata().getNamespace()) .withLabels(labelsForMemcached(resource)) .list() .getItems(); List<String> podNames = pods.stream().map(p -> p.getMetadata().getName()).collect(Collectors.toList()); if (resource.getStatus() == null || !CollectionUtils.isEqualCollection(podNames, resource.getStatus().getNodes())) { if (resource.getStatus() == null) resource.setStatus(new MemcachedStatus()); resource.getStatus().setNodes(podNames); return UpdateControl.updateResource(resource); } return UpdateControl.noUpdate(); } private Map<String, String> labelsForMemcached(Memcached m) { Map<String, String> labels = new HashMap<>(); labels.put("app", "memcached"); labels.put("memcached_cr", m.getMetadata().getName()); return labels; } private Deployment createMemcachedDeployment(Memcached m) { Deployment deployment = new DeploymentBuilder() .withMetadata( new ObjectMetaBuilder() .withName(m.getMetadata().getName()) .withNamespace(m.getMetadata().getNamespace()) .build()) .withSpec( new DeploymentSpecBuilder() .withReplicas(m.getSpec().getSize()) .withSelector( new LabelSelectorBuilder().withMatchLabels(labelsForMemcached(m)).build()) .withTemplate( new PodTemplateSpecBuilder() .withMetadata( new ObjectMetaBuilder().withLabels(labelsForMemcached(m)).build()) .withSpec( new PodSpecBuilder() .withContainers( new ContainerBuilder() .withImage("memcached:1.4.36-alpine") .withName("memcached") .withCommand("memcached", "-m=64", "-o", "modern", "-v") .withPorts( new ContainerPortBuilder() .withContainerPort(11211) .withName("memcached") .build()) .build()) .build()) .build()) .build()) .build(); deployment.addOwnerReference(m); return deployment; } }
예제 컨트롤러는 각
Memcached
CR(사용자 정의 리소스)에 대해 다음 조정 논리를 실행합니다.
다음 하위 섹션에서는 구현 예제의 컨트롤러에서 리소스를 조사하는 방법과 조정 반복문을 트리거하는 방법을 설명합니다. 이러한 하위 섹션을 건너뛰어 Operator 실행으로 직접 이동할 수 있습니다.
5.6.2.4.1. 조정 반복문
모든 컨트롤러에는 조정 반복문을 구현하는
Reconcile()
메서드가 포함된 조정기 오브젝트가 있습니다. 조정 루프는 다음 예와 같이Deployment
인수를 전달합니다.Deployment deployment = client.apps() .deployments() .inNamespace(resource.getMetadata().getNamespace()) .withName(resource.getMetadata().getName()) .get();
다음 예와 같이
Deployment
가null
인 경우 배포를 생성해야 합니다. 배포를 생성한 후 조정이 필요한지 여부를 확인할 수 있습니다.조정이 필요하지 않은 경우
UpdateControl.noUpdate()
의 값을 반환하고, 그렇지 않으면 'UpdateControl.updateStatus(resource) 값을 반환합니다.if (deployment == null) { Deployment newDeployment = createMemcachedDeployment(resource); client.apps().deployments().create(newDeployment); return UpdateControl.noUpdate(); }
배포를 가져온
후
다음 예와 같이 현재 및 필수 복제본을 가져옵니다.int currentReplicas = deployment.getSpec().getReplicas(); int requiredReplicas = resource.getSpec().getSize();
currentReplicas
가requiredReplicas
와 일치하지 않는 경우 다음 예와 같이Deployment
를 업데이트해야 합니다.if (currentReplicas != requiredReplicas) { deployment.getSpec().setReplicas(requiredReplicas); client.apps().deployments().createOrReplace(deployment); return UpdateControl.noUpdate(); }
다음 예제에서는 Pod 및 해당 이름 목록을 가져오는 방법을 보여줍니다.
List<Pod> pods = client.pods() .inNamespace(resource.getMetadata().getNamespace()) .withLabels(labelsForMemcached(resource)) .list() .getItems(); List<String> podNames = pods.stream().map(p -> p.getMetadata().getName()).collect(Collectors.toList());
리소스가 생성되었는지 확인하고 Memcached 리소스를 사용하여 podname을 확인합니다. 이러한 조건 중 하나에 불일치가 있는 경우 다음 예에 표시된 대로 조정을 수행합니다.
if (resource.getStatus() == null || !CollectionUtils.isEqualCollection(podNames, resource.getStatus().getNodes())) { if (resource.getStatus() == null) resource.setStatus(new MemcachedStatus()); resource.getStatus().setNodes(podNames); return UpdateControl.updateResource(resource); }
5.6.2.4.2. labelsForMemcached
정의
labelsForMemcached
는 리소스에 연결할 라벨 맵을 반환하는 유틸리티입니다.
private Map<String, String> labelsForMemcached(Memcached m) { Map<String, String> labels = new HashMap<>(); labels.put("app", "memcached"); labels.put("memcached_cr", m.getMetadata().getName()); return labels; }
5.6.2.4.3. createMemcachedDeployment
정의
createMemcachedDeployment
메서드는 fabric8 DeploymentBuilder
클래스를 사용합니다.
private Deployment createMemcachedDeployment(Memcached m) { Deployment deployment = new DeploymentBuilder() .withMetadata( new ObjectMetaBuilder() .withName(m.getMetadata().getName()) .withNamespace(m.getMetadata().getNamespace()) .build()) .withSpec( new DeploymentSpecBuilder() .withReplicas(m.getSpec().getSize()) .withSelector( new LabelSelectorBuilder().withMatchLabels(labelsForMemcached(m)).build()) .withTemplate( new PodTemplateSpecBuilder() .withMetadata( new ObjectMetaBuilder().withLabels(labelsForMemcached(m)).build()) .withSpec( new PodSpecBuilder() .withContainers( new ContainerBuilder() .withImage("memcached:1.4.36-alpine") .withName("memcached") .withCommand("memcached", "-m=64", "-o", "modern", "-v") .withPorts( new ContainerPortBuilder() .withContainerPort(11211) .withName("memcached") .build()) .build()) .build()) .build()) .build()) .build(); deployment.addOwnerReference(m); return deployment; }
5.6.2.5. Operator 실행
다음 세 가지 방법으로 Operator SDK CLI를 사용하여 Operator를 빌드하고 실행할 수 있습니다.
- Go 프로그램으로 클러스터 외부에서 로컬로 실행합니다.
- 클러스터에서 배포로 실행합니다.
- Operator를 번들로 제공하고 OLM(Operator Lifecycle Manager)을 사용하여 클러스터에 배포합니다.
5.6.2.5.1. 클러스터 외부에서 로컬로 실행
Operator 프로젝트를 클러스터 외부의 Go 프로그램으로 실행할 수 있습니다. 이는 배포 및 테스트 속도를 높이기 위한 개발 목적에 유용합니다.
프로세스
다음 명령을 실행하여 Operator를 컴파일합니다.
$ mvn clean install
출력 예
[INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 11.193 s [INFO] Finished at: 2021-05-26T12:16:54-04:00 [INFO] ------------------------------------------------------------------------
다음 명령을 실행하여 CRD를 기본 네임스페이스에 설치합니다.
$ oc apply -f target/kubernetes/memcacheds.cache.example.com-v1.yml
출력 예
customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com created
다음 예와 같이
rbac.yaml
이라는 파일을 생성합니다.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: memcached-operator-admin subjects: - kind: ServiceAccount name: memcached-quarkus-operator-operator namespace: <operator_namespace> roleRef: kind: ClusterRole name: cluster-admin apiGroup: ""
다음 명령을 실행하여
rbac.yaml
파일을 적용하여memcached-quarkus-operator-operator
에cluster-admin
권한을 부여합니다.$ oc apply -f rbac.yaml
다음 명령을 입력하여 Operator를 실행합니다.
$ java -jar target/quarkus-app/quarkus-run.jar
참고java
명령은 Operator를 실행하고 프로세스를 종료할 때까지 계속 실행됩니다. 이러한 명령의 나머지 부분을 완료하려면 다른 터미널이 필요합니다.다음 명령을 사용하여
memcached-sample.yaml
파일을 적용합니다.$ kubectl apply -f memcached-sample.yaml
출력 예
memcached.cache.example.com/memcached-sample created
검증
다음 명령을 실행하여 Pod가 시작되었는지 확인합니다.
$ oc get all
출력 예
NAME READY STATUS RESTARTS AGE pod/memcached-sample-6c765df685-mfqnz 1/1 Running 0 18s
5.6.2.5.2. 클러스터에서 배포로 실행
Operator 프로젝트를 클러스터에서 배포로 실행할 수 있습니다.
프로세스
다음
make
명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서IMG
인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.이미지를 빌드합니다.
$ make docker-build IMG=<registry>/<user>/<image_name>:<tag>
참고Operator용 SDK에서 생성한 Dockerfile은
Go 빌드에
대해GOARCH=amd64
를 명시적으로 참조합니다. AMD64 이외의 아키텍처의 경우GOARCH=$TARGETARCH
로 수정할 수 있습니다. Docker는 자동으로-platform
에서 지정한 값으로 환경 변수를 설정합니다. Buildah를 사용하면-build-arg
를 목적으로 사용해야 합니다. 자세한 내용은 다중 아키텍처를 참조하십시오.이미지를 리포지토리로 내보냅니다.
$ make docker-push IMG=<registry>/<user>/<image_name>:<tag>
참고두 명령 모두 이미지의 이름과 태그(예:
IMG=<registry>/<user>/<image_name>:<tag>
)를 Makefile에 설정할 수 있습니다. 기본 이미지 이름을 설정하려면IMG ?= controller:latest
값을 수정합니다.
다음 명령을 실행하여 CRD를 기본 네임스페이스에 설치합니다.
$ oc apply -f target/kubernetes/memcacheds.cache.example.com-v1.yml
출력 예
customresourcedefinition.apiextensions.k8s.io/memcacheds.cache.example.com created
다음 예와 같이
rbac.yaml
이라는 파일을 생성합니다.apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: memcached-operator-admin subjects: - kind: ServiceAccount name: memcached-quarkus-operator-operator namespace: <operator_namespace> roleRef: kind: ClusterRole name: cluster-admin apiGroup: ""
중요rbac.yaml
파일은 이후 단계에서 적용됩니다.다음 명령을 실행하여 Operator를 배포합니다.
$ make deploy IMG=<registry>/<user>/<image_name>:<tag>
다음 명령을 실행하여 이전 단계에서 생성한
rbac.yaml
파일을 적용하여memcached-quarkus-operator-operator
에cluster-admin
권한을 부여합니다.$ oc apply -f rbac.yaml
다음 명령을 실행하여 Operator가 실행 중인지 확인합니다.
$ oc get all -n default
출력 예
NAME READY UP-TO-DATE AVAILABLE AGE pod/memcached-quarkus-operator-operator-7db86ccf58-k4mlm 0/1 Running 0 18s
다음 명령을 실행하여
memcached-sample.yaml
을 적용하고memcached-sample
Pod를 생성합니다.$ oc apply -f memcached-sample.yaml
출력 예
memcached.cache.example.com/memcached-sample created
검증
다음 명령을 실행하여 Pod가 시작되었는지 확인합니다.
$ oc get all
출력 예
NAME READY STATUS RESTARTS AGE pod/memcached-quarkus-operator-operator-7b766f4896-kxnzt 1/1 Running 1 79s pod/memcached-sample-6c765df685-mfqnz 1/1 Running 0 18s
5.6.2.5.3. Operator 번들링 및 Operator Lifecycle Manager를 통한 배포
5.6.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 프로젝트를 초기화함
프로세스
Operator 프로젝트 디렉터리에서 다음
make
명령을 실행하여 Operator 이미지를 빌드하고 내보냅니다. 액세스할 수 있는 리포지토리를 참조하려면 다음 단계에서IMG
인수를 수정합니다. Quay.io와 같은 리포지토리 사이트에 컨테이너를 저장하기 위해 계정을 받을 수 있습니다.이미지를 빌드합니다.
$ make docker-build IMG=<registry>/<user>/<operator_image_name>:<tag>
참고Operator용 SDK에서 생성한 Dockerfile은
Go 빌드에
대해GOARCH=amd64
를 명시적으로 참조합니다. AMD64 이외의 아키텍처의 경우GOARCH=$TARGETARCH
로 수정할 수 있습니다. 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.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.6.2.6. 추가 리소스
- Operator SDK에서 생성한 디렉터리 구조에 대한 자세한 내용은 Java 기반 Operator의 프로젝트 레이아웃 을 참조하십시오.
- 클러스터 전체 송신 프록시가 구성된 경우 클러스터 관리자는 프록시 설정을 재정의하거나 OLM(Operator Lifecycle Manager)에서 실행되는 특정 Operator에 대한 사용자 정의 CA 인증서를 삽입 할 수 있습니다.
5.6.3. Java 기반 Operator의 프로젝트 레이아웃
Java 기반 Operator SDK는 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
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.6.3.1. Java 기반 프로젝트 레이아웃
operator-sdk init
명령으로 생성된 Java 기반 Operator 프로젝트에는 다음 파일과 디렉터리가 포함됩니다.
파일 또는 디렉터리 | 목적 |
---|---|
| Operator를 실행하는 데 필요한 종속 항목이 포함된 파일입니다. |
|
API를 나타내는 파일이 포함된 디렉터리입니다. 도메인이 |
| 컨트롤러 구현을 정의하는 Java 파일입니다. |
| Memcached CR의 원하는 상태를 정의하는 Java 파일입니다. |
| Memcached CR의 관찰 상태를 정의하는 Java 파일입니다. |
| Memcached API의 스키마를 정의하는 Java 파일입니다. |
| CRD yaml 파일이 포함된 디렉터리입니다. |
5.6.4. 최신 Operator SDK 버전을 위한 프로젝트 업데이트
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.6.4.1. Operator SDK 1.36.1에 대한 Java 기반 Operator 프로젝트 업데이트
다음 절차에서는 1.36.1과의 호환성을 위해 기존 Java 기반 Operator 프로젝트를 업데이트합니다.
사전 요구 사항
- Operator SDK 1.36.1 설치
- Operator SDK 1.31.0을 사용하여 생성되거나 유지 관리되는 Operator 프로젝트
프로세스
다음 예와 같이 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
RHEL(Red Hat Enterprise Linux) 9 기반 이미지를 사용하도록
kube-rbac-proxy
컨테이너를 업데이트합니다.다음 파일에서
kube-rbac-proxy
컨테이너 항목을 찾습니다.-
config/default/manager_auth_proxy_patch.yaml
-
Operator 프로젝트의
bundle/manifests/<operator_name>.clusterserviceversion.yaml
(예: 튜토리얼의memcached-operator.clusterserviceversion.yaml
)
-
ose-kube-rbac-proxy에서
ose-kube-rbac-proxy
-rhel9v4.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 # ...
-
kustomize/v2
플러그인은 이제 안정적인 상태이며go/v4
,ansible/v1
,helm/v1
,hybrid/v1-alpha
플러그인을 사용할 때 플러그인 체인에 사용되는 기본 버전입니다. 이 기본 스캐폴드에 대한 자세한 내용은 Kubebuilder 설명서의 Kustomize v2 를 참조하십시오. 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
1.29를 사용하려면 Operator 프로젝트의 Kubernetes 버전을 업그레이드해야 합니다. 프로젝트 구조, Makefile 및
go.mod
파일을 다음과 같이 변경해야 합니다.중요Go/v3
플러그인은 Kubebuilder에서 더 이상 사용되지 않으므로 Operator SDK도 향후 릴리스에서go/v4
로 마이그레이션되고 있습니다.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
다음 명령을 실행하여 업그레이드된 종속 항목을 다운로드합니다.
$ go mod tidy