Operator

프로세스

1. 이 절차를 위해 OpenShift Container Platform 웹 콘솔에 새 프로젝트를 생성합니다. 이 예제에서는 my-etcd라는 프로젝트를 사용합니다.

2. Operator → 설치된 Operator 페이지로 이동합니다. 이 페이지에는 클러스터 관리자가 클러스터에 설치하여 사용할 수 있는 Operator가 CSV(클러스터 서비스 버전) 목록으로 표시됩니다. CSV는 Operator에서 제공하는 소프트웨어를 시작하고 관리하는 데 사용됩니다.

   작은 정보

   다음을 사용하여 CLI에서 이 목록을 가져올 수 있습니다.

   $ oc get csv

3. 자세한 내용과 사용 가능한 작업을 확인하려면 설치된 Operator 페이지에서 etcd Operator를 클릭합니다.

   이 Operator에서는 제공된 API 아래에 표시된 것과 같이 etcd 클러스터(EtcdCluster 리소스)용 하나를 포함하여 새로운 리소스 유형 세 가지를 사용할 수 있습니다. 이러한 오브젝트는 내장된 네이티브 Kubernetes 오브젝트(예: Deployment 또는 ReplicaSet)와 비슷하게 작동하지만 etcd 관리와 관련된 논리가 포함됩니다.

4. 새 etcd 클러스터를 생성합니다.

   1. etcd 클러스터 API 상자에서 인스턴스 생성을 클릭합니다.
   2. 다음 화면을 사용하면 클러스터 크기와 같은 EtcdCluster 오브젝트의 최소 시작 템플릿을 수정할 수 있습니다. 지금은 생성을 클릭하여 종료하십시오. 그러면 Operator에서 새 etcd 클러스터의 Pod, 서비스 및 기타 구성 요소를 가동합니다.

5. 예제 etcd 클러스터를 클릭한 다음 리소스 탭을 클릭하여 Operator에서 자동으로 생성 및 구성한 리소스 수가 프로젝트에 포함되는지 확인합니다.

   프로젝트의 다른 Pod에서 데이터베이스에 액세스할 수 있도록 Kubernetes 서비스가 생성되었는지 확인합니다.

6. 지정된 프로젝트에서 edit 역할을 가진 모든 사용자는 클라우드 서비스와 마찬가지로 셀프 서비스 방식으로 프로젝트에 이미 생성된 Operator에서 관리하는 애플리케이션 인스턴스(이 예제의 etcd 클러스터)를 생성, 관리, 삭제할 수 있습니다. 이 기능을 사용하여 추가 사용자를 활성화하려면 프로젝트 관리자가 다음 명령을 사용하여 역할을 추가하면 됩니다.

   $ oc policy add-role-to-user edit <user> -n <target_project>

프로세스

1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.

2. 원하는 Operator를 찾으려면 키워드를 Filter by keyword 상자에 입력하거나 스크롤합니다. 예를 들어 Kubernetes Operator의 고급 클러스터 관리 기능을 찾으려면 advanced를 입력합니다.

   인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.

3. Operator를 선택하여 추가 정보를 표시합니다.

   참고

   커뮤니티 Operator를 선택하면 Red Hat이 커뮤니티 Operator를 인증하지 않는다고 경고합니다. 계속하기 전에 경고를 확인해야합니다.

4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.

5. Operator 설치 페이지에서 다음을 수행합니다.

   1. Operator를 설치할 특정 단일 네임스페이스를 선택합니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
   2. Update Channe을 선택합니다 (하나 이상이 사용 가능한 경우).
   3. 앞에서 설명한 대로 자동 또는 수동 승인 전략을 선택합니다.

6. 이 OpenShift Container Platform 클러스터에서 선택한 네임스페이스에서 Operator를 사용할 수 있도록 하려면 설치를 클릭합니다.

   1. 수동 승인 전략을 선택한 경우 설치 계획을 검토하고 승인할 때까지 서브스크립션의 업그레이드 상태가 업그레이드 중으로 유지됩니다.

      Install Plan 페이지에서 승인 한 후 subscription 업그레이드 상태가 Up to date로 이동합니다.

   2. 자동 승인 전략을 선택한 경우 업그레이드 상태가 개입 없이 최신 상태로 확인되어야 합니다.

7. 서브스크립션의 업그레이드 상태가 최신이면 Operator → 설치된 Operator를 선택하여 설치된 Operator의 CSV(클러스터 서비스 버전)가 최종적으로 표시되는지 확인합니다. 상태는 최종적으로 관련 네임스페이스에서 InstallSucceeded로 확인되어야 합니다.

   참고

   모든 네임 스페이스…​ 설치 모드에서는 openshift-operators 네임스페이스에서 상태가 InstallSucceeded 로 확인 되지만 다른 네임스페이스에서 확인하면 상태가 복사됩니다.

   그러지 않은 경우 다음을 수행합니다.

   1. openshift-operators 프로젝트(또는 A 특정 네임 스페이스…​ 워크로드 → Pod 페이지에서 추가 문제 해결을 위해 문제를 보고하는 설치 모드가 선택되었습니다.

프로세스

1. OperatorHub에서 클러스터에 사용 가능한 Operator의 목록을 표시합니다.

   $ oc get packagemanifests -n openshift-marketplace

   출력 예

   NAME                               CATALOG               AGE
   3scale-operator                    Red Hat Operators     91m
   advanced-cluster-management        Red Hat Operators     91m
   amq7-cert-manager                  Red Hat Operators     91m
   ...
   couchbase-enterprise-certified     Certified Operators   91m
   crunchy-postgres-operator          Certified Operators   91m
   mongodb-enterprise                 Certified Operators   91m
   ...
   etcd                               Community Operators   91m
   jaeger                             Community Operators   91m
   kubefed                            Community Operators   91m
   ...

   필요한 Operator의 카탈로그를 기록해 둡니다.

2. 필요한 Operator를 검사하여 지원되는 설치 모드 및 사용 가능한 채널을 확인합니다.

   $ oc describe packagemanifests <operator_name> -n openshift-marketplace

3. OperatorGroup 오브젝트로 정의되는 Operator group에서 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

   Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces를 사용하는 경우 openshift-operators 네임스페이스에 적절한 Operator group이 이미 있습니다.

   그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

   참고

   이 프로세스의 웹 콘솔 버전에서는 SingleNamespace 모드를 선택할 때 자동으로 OperatorGroup 및 Subscription 개체 생성을 자동으로 처리합니다.

   1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

   2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml

4. Subscription 개체 YAML 파일을 생성하여 OpenShift Pipelines Operator에 네임스페이스를 등록합니다(예: sub.yaml).

   Subscription 개체 예

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: <subscription_name>
     namespace: openshift-operators 1
   spec:
     channel: <channel_name> 2
     name: <operator_name> 3
     source: redhat-operators 4
     sourceNamespace: openshift-marketplace 5
     config:
       env: 6
       - name: ARGS
         value: "-v=10"
       envFrom: 7
       - secretRef:
           name: license-secret
       volumes: 8
       - name: <volume_name>
         configMap:
           name: <configmap_name>
       volumeMounts: 9
       - mountPath: <directory_name>
         name: <volume_name>
       tolerations: 10
       - operator: "Exists"
       resources: 11
         requests:
           memory: "64Mi"
           cpu: "250m"
         limits:
           memory: "128Mi"
           cpu: "500m"
       nodeSelector: 12
         foo: bar

   1

   AllNamespaces 설치 모드를 사용하려면 openshift-operators 네임스페이스를 지정합니다. 그 외에는 SingleNamespace 설치 모드를 사용하도록 관련 단일 네임스페이스를 지정합니다.

   2

   등록할 채널의 이름입니다.

   3

   등록할 Operator의 이름입니다.

   4

   Operator를 제공하는 카탈로그 소스의 이름입니다.

   5

   카탈로그 소스의 네임스페이스입니다. 기본 OperatorHub 카탈로그 소스에는 openshift-marketplace를 사용합니다.

   6

   env 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 존재해야 하는 환경 변수 목록을 정의합니다.

   7

   envFrom 매개 변수는 컨테이너에 환경 변수를 채울 소스 목록을 정의합니다.

   8

   volumes 매개변수는 OLM에서 생성한 Pod에 있어야 하는 볼륨 목록을 정의합니다.

   9

   volumeMounts 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 존재해야 하는 VolumeMounts 목록을 정의합니다. volumeMount 가 존재하지 않는 볼륨을 참조하는 경우 OLM에서 Operator를 배포하지 못합니다.

   10

   tolerations 매개변수는 OLM에서 생성한 Pod의 허용 오차 목록을 정의합니다.

   11

   resources 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.

   12

   nodeSelector 매개변수는 OLM에서 생성한 Pod에 대한 NodeSelector 를 정의합니다.

5. Subscription 오브젝트를 생성합니다.

   $ oc apply -f sub.yaml

   이 시점에서 OLM은 이제 선택한 Operator를 인식합니다. Operator의 CSV(클러스터 서비스 버전)가 대상 네임스페이스에 표시되고 Operator에서 제공하는 API를 생성에 사용할 수 있어야 합니다.

프로세스

1. startingCSV 필드를 설정하여 특정 버전의 Operator에 네임스페이스를 서브스크립션하는 Subscription 오브젝트 YAML 파일을 생성합니다. 카탈로그에 이후 버전이 있는 경우 Operator가 자동으로 업그레이드되지 않도록 installPlanApproval 필드를 Manual로 설정합니다.

   예를 들어 다음 sub.yaml 파일을 사용하여 특별히 3.4.0 버전에 Red Hat Quay Operator를 설치할 수 있습니다.

   특정 시작 Operator 버전이 있는 서브스크립션

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: quay-operator
     namespace: quay
   spec:
     channel: quay-v3.4
     installPlanApproval: Manual 1
     name: quay-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: quay-operator.v3.4.0 2

   1

   지정된 버전이 카탈로그의 이후 버전으로 대체될 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.

   2

   Operator CSV의 특정 버전을 설정합니다.

2. Subscription 오브젝트를 생성합니다.

   $ oc apply -f sub.yaml

3. 보류 중인 설치 계획을 수동으로 승인하여 Operator 설치를 완료합니다.

프로세스

1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.

2. 원하는 Operator를 찾으려면 키워드를 Filter by keyword 상자에 입력하거나 스크롤합니다. 예를 들어 Kubernetes Operator의 고급 클러스터 관리 기능을 찾으려면 advanced를 입력합니다.

   인프라 기능에서 옵션을 필터링할 수 있습니다. 예를 들어, 연결이 끊긴 환경 (제한된 네트워크 환경이라고도 함)에서 작업하는 Operator를 표시하려면 Disconnected를 선택합니다.

3. Operator를 선택하여 추가 정보를 표시합니다.

   참고

   커뮤니티 Operator를 선택하면 Red Hat이 커뮤니티 Operator를 인증하지 않는다고 경고합니다. 계속하기 전에 경고를 확인해야합니다.

4. Operator에 대한 정보를 확인하고 Install을 클릭합니다.

5. Operator 설치 페이지에서 다음을 수행합니다.

   1. 다음 명령 중 하나를 선택합니다.

      • All namespaces on the cluster (default)에서는 기본 openshift-operators 네임스페이스에 Operator가 설치되므로 Operator가 클러스터의 모든 네임스페이스를 모니터링하고 사용할 수 있습니다. 이 옵션을 항상 사용할 수있는 것은 아닙니다.
      • A specific namespace on the cluster를 사용하면 Operator를 설치할 특정 단일 네임 스페이스를 선택할 수 있습니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
   2. Operator를 설치할 특정 단일 네임스페이스를 선택합니다. Operator는 이 단일 네임 스페이스에서만 모니터링 및 사용할 수 있게 됩니다.
   3. Update Channe을 선택합니다 (하나 이상이 사용 가능한 경우).
   4. 앞에서 설명한 대로 자동 또는 수동 승인 전략을 선택합니다.

6. 이 OpenShift Container Platform 클러스터에서 선택한 네임스페이스에서 Operator를 사용할 수 있도록 하려면 설치를 클릭합니다.

   1. 수동 승인 전략을 선택한 경우 설치 계획을 검토하고 승인할 때까지 서브스크립션의 업그레이드 상태가 업그레이드 중으로 유지됩니다.

      Install Plan 페이지에서 승인 한 후 subscription 업그레이드 상태가 Up to date로 이동합니다.

   2. 자동 승인 전략을 선택한 경우 업그레이드 상태가 개입 없이 최신 상태로 확인되어야 합니다.

7. 서브스크립션의 업그레이드 상태가 최신이면 Operator → 설치된 Operator를 선택하여 설치된 Operator의 CSV(클러스터 서비스 버전)가 최종적으로 표시되는지 확인합니다. 상태는 최종적으로 관련 네임스페이스에서 InstallSucceeded로 확인되어야 합니다.

   참고

   모든 네임 스페이스…​ 설치 모드에서는 openshift-operators 네임스페이스에서 상태가 InstallSucceeded 로 확인 되지만 다른 네임스페이스에서 확인하면 상태가 복사됩니다.

   그러지 않은 경우 다음을 수행합니다.

   1. openshift-operators 프로젝트(또는 A 특정 네임 스페이스…​ 워크로드 → Pod 페이지에서 추가 문제 해결을 위해 문제를 보고하는 설치 모드가 선택되었습니다.

프로세스

1. OperatorHub에서 클러스터에 사용 가능한 Operator의 목록을 표시합니다.

   $ oc get packagemanifests -n openshift-marketplace

   출력 예

   NAME                               CATALOG               AGE
   3scale-operator                    Red Hat Operators     91m
   advanced-cluster-management        Red Hat Operators     91m
   amq7-cert-manager                  Red Hat Operators     91m
   ...
   couchbase-enterprise-certified     Certified Operators   91m
   crunchy-postgres-operator          Certified Operators   91m
   mongodb-enterprise                 Certified Operators   91m
   ...
   etcd                               Community Operators   91m
   jaeger                             Community Operators   91m
   kubefed                            Community Operators   91m
   ...

   필요한 Operator의 카탈로그를 기록해 둡니다.

2. 필요한 Operator를 검사하여 지원되는 설치 모드 및 사용 가능한 채널을 확인합니다.

   $ oc describe packagemanifests <operator_name> -n openshift-marketplace

3. OperatorGroup 오브젝트로 정의되는 Operator group에서 Operator group과 동일한 네임스페이스에 있는 모든 Operator에 대해 필요한 RBAC 액세스 권한을 생성할 대상 네임스페이스를 선택합니다.

   Operator를 서브스크립션하는 네임스페이스에는 Operator의 설치 모드, 즉 AllNamespaces 또는 SingleNamespace 모드와 일치하는 Operator group이 있어야 합니다. 설치하려는 Operator에서 AllNamespaces를 사용하는 경우 openshift-operators 네임스페이스에 적절한 Operator group이 이미 있습니다.

   그러나 Operator에서 SingleNamespace 모드를 사용하고 적절한 Operator group이 없는 경우 이를 생성해야 합니다.

   참고

   이 프로세스의 웹 콘솔 버전에서는 SingleNamespace 모드를 선택할 때 자동으로 OperatorGroup 및 Subscription 개체 생성을 자동으로 처리합니다.

   1. OperatorGroup 개체 YAML 파일을 만듭니다 (예: operatorgroup.yaml).

      OperatorGroup 오브젝트의 예

      apiVersion: operators.coreos.com/v1
      kind: OperatorGroup
      metadata:
        name: <operatorgroup_name>
        namespace: <namespace>
      spec:
        targetNamespaces:
        - <namespace>

   2. OperatorGroup 개체를 생성합니다.

      $ oc apply -f operatorgroup.yaml

4. Subscription 개체 YAML 파일을 생성하여 OpenShift Pipelines Operator에 네임스페이스를 등록합니다(예: sub.yaml).

   Subscription 개체 예

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: <subscription_name>
     namespace: openshift-operators 1
   spec:
     channel: <channel_name> 2
     name: <operator_name> 3
     source: redhat-operators 4
     sourceNamespace: openshift-marketplace 5
     config:
       env: 6
       - name: ARGS
         value: "-v=10"
       envFrom: 7
       - secretRef:
           name: license-secret
       volumes: 8
       - name: <volume_name>
         configMap:
           name: <configmap_name>
       volumeMounts: 9
       - mountPath: <directory_name>
         name: <volume_name>
       tolerations: 10
       - operator: "Exists"
       resources: 11
         requests:
           memory: "64Mi"
           cpu: "250m"
         limits:
           memory: "128Mi"
           cpu: "500m"
       nodeSelector: 12
         foo: bar

   1

   AllNamespaces 설치 모드를 사용하려면 openshift-operators 네임스페이스를 지정합니다. 그 외에는 SingleNamespace 설치 모드를 사용하도록 관련 단일 네임스페이스를 지정합니다.

   2

   등록할 채널의 이름입니다.

   3

   등록할 Operator의 이름입니다.

   4

   Operator를 제공하는 카탈로그 소스의 이름입니다.

   5

   카탈로그 소스의 네임스페이스입니다. 기본 OperatorHub 카탈로그 소스에는 openshift-marketplace를 사용합니다.

   6

   env 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 존재해야 하는 환경 변수 목록을 정의합니다.

   7

   envFrom 매개 변수는 컨테이너에 환경 변수를 채울 소스 목록을 정의합니다.

   8

   volumes 매개변수는 OLM에서 생성한 Pod에 있어야 하는 볼륨 목록을 정의합니다.

   9

   volumeMounts 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 존재해야 하는 VolumeMounts 목록을 정의합니다. volumeMount 가 존재하지 않는 볼륨을 참조하는 경우 OLM에서 Operator를 배포하지 못합니다.

   10

   tolerations 매개변수는 OLM에서 생성한 Pod의 허용 오차 목록을 정의합니다.

   11

   resources 매개변수는 OLM에서 생성한 Pod의 모든 컨테이너에 대한 리소스 제약 조건을 정의합니다.

   12

   nodeSelector 매개변수는 OLM에서 생성한 Pod에 대한 NodeSelector 를 정의합니다.

5. Subscription 오브젝트를 생성합니다.

   $ oc apply -f sub.yaml

   이 시점에서 OLM은 이제 선택한 Operator를 인식합니다. Operator의 CSV(클러스터 서비스 버전)가 대상 네임스페이스에 표시되고 Operator에서 제공하는 API를 생성에 사용할 수 있어야 합니다.

프로세스

1. startingCSV 필드를 설정하여 특정 버전의 Operator에 네임스페이스를 서브스크립션하는 Subscription 오브젝트 YAML 파일을 생성합니다. 카탈로그에 이후 버전이 있는 경우 Operator가 자동으로 업그레이드되지 않도록 installPlanApproval 필드를 Manual로 설정합니다.

   예를 들어 다음 sub.yaml 파일을 사용하여 특별히 3.4.0 버전에 Red Hat Quay Operator를 설치할 수 있습니다.

   특정 시작 Operator 버전이 있는 서브스크립션

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: quay-operator
     namespace: quay
   spec:
     channel: quay-v3.4
     installPlanApproval: Manual 1
     name: quay-operator
     source: redhat-operators
     sourceNamespace: openshift-marketplace
     startingCSV: quay-operator.v3.4.0 2

   1

   지정된 버전이 카탈로그의 이후 버전으로 대체될 경우 승인 전략을 Manual로 설정합니다. 이 계획에서는 이후 버전으로 자동 업그레이드할 수 없으므로 시작 CSV에서 설치를 완료하려면 수동 승인이 필요합니다.

   2

   Operator CSV의 특정 버전을 설정합니다.

2. Subscription 오브젝트를 생성합니다.

   $ oc apply -f sub.yaml

3. 보류 중인 설치 계획을 수동으로 승인하여 Operator 설치를 완료합니다.

절차

1. OpenShift Container Platform 웹 콘솔의 관리자 관점에서 Operator → 설치된 Operator로 이동합니다.
2. 업데이트 채널을 변경할 Operator 이름을 클릭합니다.
3. 서브스크립션 탭을 클릭합니다.
4. 채널에서 업데이트 채널의 이름을 클릭합니다.
5. 변경할 최신 업데이트 채널을 클릭한 다음 저장을 클릭합니다.

6. 자동 승인 전략이 있는 서브스크립션의 경우 업그레이드가 자동으로 시작됩니다. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공 및 최신으로 변경됩니다.

   수동 승인 전략이 있는 서브스크립션의 경우 서브스크립션 탭에서 업그레이드를 수동으로 승인할 수 있습니다.

절차

1. OpenShift Container Platform 웹 콘솔의 관리자 관점에서 Operator → 설치된 Operator로 이동합니다.
2. 보류 중인 업그레이드가 있는 Operator에 업그레이드 사용 가능 상태가 표시됩니다. 업그레이드할 Operator 이름을 클릭합니다.
3. 서브스크립션 탭을 클릭합니다. 승인이 필요한 업그레이드는 업그레이드 상태 옆에 표시됩니다. 예를 들어 1 승인 필요가 표시될 수 있습니다.
4. 1 승인 필요를 클릭한 다음 설치 계획 프리뷰를 클릭합니다.
5. 업그레이드할 수 있는 것으로 나열된 리소스를 검토합니다. 문제가 없는 경우 승인을 클릭합니다.
6. Operator → 설치된 Operator 페이지로 이동하여 업그레이드 진행 상황을 모니터링합니다. 완료되면 상태가 성공 및 최신으로 변경됩니다.

프로세스

1. Operator → 설치된 Operator 페이지에서 스크롤하거나 이름별 필터링에 키워드를 입력하여 원하는 Operator를 찾습니다. 그런 다음 해당 Operator를 클릭합니다.

2. Operator 세부 정보 페이지 오른쪽에 있는 작업 목록에서 Operator 제거를 선택합니다.

   Operator를 설치 제거하시겠습니까? 대화 상자가 표시되고 다음 메시지가 표시됩니다.

   Operator를 제거해도 사용자 정의 리소스 정의 또는 관리형 리소스는 제거되지 않습니다. Operator에서 클러스터에 애플리케이션을 배포하거나 클러스터 외부 리소스를 구성한 경우 해당 리소스는 계속 실행되며 수동으로 정리해야 합니다.

   이 작업은 Operator 및 Operator 배포 및 Pod(있는 경우)를 제거합니다. CRD 및 CR을 포함하여 Operator에서 관리하는 Operand 및 리소스는 제거되지 않습니다. 웹 콘솔에서는 일부 Operator의 대시보드 및 탐색 항목을 활성화합니다. Operator를 설치 제거한 후 해당 항목을 제거하려면 Operator CRD를 수동으로 삭제해야 할 수 있습니다.

3. 설치 제거를 선택합니다. 이 Operator는 실행을 중지하고 더 이상 업데이트를 수신하지 않습니다.

프로세스

1. currentCSV 필드에서 구독한 Operator(예: jaeger)의 현재 버전을 확인합니다.

   $ oc get subscription jaeger -n openshift-operators -o yaml | grep currentCSV

   출력 예

     currentCSV: jaeger-operator.v1.8.2

2. 서브스크립션을 삭제합니다(예: jaeger).

   $ oc delete subscription jaeger -n openshift-operators

   출력 예

   subscription.operators.coreos.com "jaeger" deleted

3. 이전 단계의 currentCSV 값을 사용하여 대상 네임스페이스에서 Operator의 CSV를 삭제합니다.

   $ oc delete clusterserviceversion jaeger-operator.v1.8.2 -n openshift-operators

   출력 예

   clusterserviceversion.operators.coreos.com "jaeger-operator.v1.8.2" deleted

프로세스

1. Operator가 설치된 네임스페이스에서 Subscription 및 ClusterServiceVersion 오브젝트의 이름을 가져옵니다.

   $ oc get sub,csv -n <namespace>

   출력 예

   NAME                                                       PACKAGE                  SOURCE             CHANNEL
   subscription.operators.coreos.com/elasticsearch-operator   elasticsearch-operator   redhat-operators   5.0
   
   NAME                                                                         DISPLAY                            VERSION    REPLACES   PHASE
   clusterserviceversion.operators.coreos.com/elasticsearch-operator.5.0.0-65   OpenShift Elasticsearch Operator   5.0.0-65              Succeeded

2. 서브스크립션을 삭제합니다.

   $ oc delete subscription <subscription_name> -n <namespace>

3. 클러스터 서비스 버전을 삭제합니다.

   $ oc delete csv <csv_name> -n <namespace>

4. openshift-marketplace 네임스페이스에서 실패한 모든 작업 및 관련 구성 맵의 이름을 가져옵니다.

   $ oc get job,configmap -n openshift-marketplace

   출력 예

   NAME                                                                        COMPLETIONS   DURATION   AGE
   job.batch/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   1/1           26s        9m30s
   
   NAME                                                                        DATA   AGE
   configmap/1de9443b6324e629ddf31fed0a853a121275806170e34c926d69e53a7fcbccb   3      9m30s

5. 작업을 삭제합니다.

   $ oc delete job <job_name> -n openshift-marketplace

   이렇게 하면 액세스할 수 없는 이미지를 가져오려는 Pod가 다시 생성되지 않습니다.

6. 구성 맵을 삭제합니다.

   $ oc delete configmap <configmap_name> -n openshift-marketplace

7. 웹 콘솔에서 OperatorHub를 사용하여 Operator를 다시 설치합니다.

프로세스

1. 웹 콘솔에서 Operators → OperatorHub 페이지로 이동합니다.
2. Operator를 선택하고 설치를 클릭합니다.

3. Operator 설치 페이지에서 spec 섹션에 다음 환경 변수를 하나 이상 포함하도록 Subscription 오브젝트를 수정합니다.

   • HTTP_PROXY
   • HTTPS_PROXY
   • NO_PROXY

   예를 들면 다음과 같습니다.

   프록시 설정 덮어쓰기가 포함된 Subscription 오브젝트

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: etcd-config-test
     namespace: openshift-operators
   spec:
     config:
       env:
       - name: HTTP_PROXY
         value: test_http
       - name: HTTPS_PROXY
         value: test_https
       - name: NO_PROXY
         value: test
     channel: clusterwide-alpha
     installPlanApproval: Automatic
     name: etcd
     source: community-operators
     sourceNamespace: openshift-marketplace
     startingCSV: etcdoperator.v0.9.4-clusterwide

   참고

   이러한 환경 변수는 이전에 설정한 클러스터 수준 또는 사용자 정의 프록시 설정을 제거하기 위해 빈 값을 사용하여 설정을 해제할 수도 있습니다.

   OLM에서는 이러한 환경 변수를 단위로 처리합니다. 환경 변수가 한 개 이상 설정되어 있으면 세 개 모두 덮어쓰는 것으로 간주하며 구독한 Operator의 배포에 클러스터 수준 기본값이 사용되지 않습니다.

4. 선택한 네임스페이스에서 Operator를 사용할 수 있도록 설치를 클릭합니다.

5. Operator의 CSV가 관련 네임스페이스에 표시되면 사용자 정의 프록시 환경 변수가 배포에 설정되어 있는지 확인할 수 있습니다. 예를 들면 CLI를 사용합니다.

   $ oc get deployment -n openshift-operators \
       etcd-operator -o yaml \
       | grep -i "PROXY" -A 2

   출력 예

           - name: HTTP_PROXY
             value: test_http
           - name: HTTPS_PROXY
             value: test_https
           - name: NO_PROXY
             value: test
           image: quay.io/coreos/etcd-operator@sha256:66a37fd61a06a43969854ee6d3e21088a98b93838e284a6086b13917f96b0d9c
   ...

프로세스

1. Operator의 서브스크립션이 존재하고 다음 라벨을 포함하는 네임스페이스에 빈 구성 맵을 생성합니다.

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: trusted-ca 1
     labels:
       config.openshift.io/inject-trusted-cabundle: "true" 2

   1

   구성 맵의 이름입니다.

   2

   CNO(Cluster Network Operator)에 병합된 번들을 삽입하도록 요청합니다.

   이 구성 맵이 생성되면 병합된 번들의 인증서 콘텐츠로 즉시 채워집니다.

2. Subscription 오브젝트를 업데이트하여 사용자 정의 CA가 필요한 Pod 내의 각 컨테이너에 trusted-ca 구성 맵을 볼륨으로 마운트하는 spec.config 섹션을 포함합니다.

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: my-operator
   spec:
     package: etcd
     channel: alpha
     config: 1
       selector:
         matchLabels:
           <labels_for_pods> 2
       volumes: 3
       - name: trusted-ca
         configMap:
           name: trusted-ca
           items:
             - key: ca-bundle.crt 4
               path: tls-ca-bundle.pem 5
       volumeMounts: 6
       - name: trusted-ca
         mountPath: /etc/pki/ca-trust/extracted/pem
         readOnly: true

   1

   config 섹션이 없는 경우 추가합니다.

   2

   Operator에서 보유한 Pod와 일치하도록 라벨을 지정합니다.

   3

   trusted-ca 볼륨을 생성합니다.

   4

   구성 맵 키로 ca-bundle.crt가 필요합니다.

   5

   구성 맵 경로로 tls-ca-bundle.pem이 필요합니다.

   6

   trusted-ca 볼륨 마운트를 생성합니다.

프로세스

1. Operator 서브스크립션을 나열합니다.

   $ oc get subs -n <operator_namespace>

2. oc describe 명령을 사용하여 Subscription 리소스를 검사합니다.

   $ oc describe sub <subscription_name> -n <operator_namespace>

3. 명령 출력에서 Operator 서브스크립션 조건 유형의 상태에 대한 Conditions 섹션을 확인합니다. 다음 예에서 사용 가능한 모든 카탈로그 소스가 정상이므로 CatalogSourcesUnhealthy 조건 유형의 상태가 false입니다.

   출력 예

   Conditions:
      Last Transition Time:  2019-07-29T13:42:57Z
      Message:               all available catalogsources are healthy
      Reason:                AllCatalogSourcesHealthy
      Status:                False
      Type:                  CatalogSourcesUnhealthy

절차

1. 네임스페이스의 카탈로그 소스를 나열합니다. 예를 들어 클러스터 전체 카탈로그 소스에 사용되는 openshift-marketplace 네임스페이스를 확인할 수 있습니다.

   $ oc get catalogsources -n openshift-marketplace

   출력 예

   NAME                  DISPLAY               TYPE   PUBLISHER   AGE
   certified-operators   Certified Operators   grpc   Red Hat     55m
   community-operators   Community Operators   grpc   Red Hat     55m
   example-catalog       Example Catalog       grpc   Example Org 2m25s
   redhat-marketplace    Red Hat Marketplace   grpc   Red Hat     55m
   redhat-operators      Red Hat Operators     grpc   Red Hat     55m

2. oc describe 명령을 사용하여 카탈로그 소스에 대한 자세한 내용 및 상태를 가져옵니다.

   $ oc describe catalogsource example-catalog -n openshift-marketplace

   출력 예

   Name:         example-catalog
   Namespace:    openshift-marketplace
   ...
   Status:
     Connection State:
       Address:              example-catalog.openshift-marketplace.svc:50051
       Last Connect:         2021-09-09T17:07:35Z
       Last Observed State:  TRANSIENT_FAILURE
     Registry Service:
       Created At:         2021-09-09T17:05:45Z
       Port:               50051
       Protocol:           grpc
       Service Name:       example-catalog
       Service Namespace:  openshift-marketplace

   앞의 예제 출력에서 마지막으로 관찰된 상태는 TRANSIENT_FAILURE입니다. 이 상태는 카탈로그 소스에 대한 연결을 설정하는 데 문제가 있음을 나타냅니다.

3. 카탈로그 소스가 생성된 네임스페이스의 Pod를 나열합니다.

   $ oc get pods -n openshift-marketplace

   출력 예

   NAME                                    READY   STATUS             RESTARTS   AGE
   certified-operators-cv9nn               1/1     Running            0          36m
   community-operators-6v8lp               1/1     Running            0          36m
   marketplace-operator-86bfc75f9b-jkgbc   1/1     Running            0          42m
   example-catalog-bwt8z                   0/1     ImagePullBackOff   0          3m55s
   redhat-marketplace-57p8c                1/1     Running            0          36m
   redhat-operators-smxx8                  1/1     Running            0          36m

   카탈로그 소스가 네임스페이스에 생성되면 해당 네임스페이스에 카탈로그 소스의 Pod가 생성됩니다. 위 예제 출력에서 example-catalog-bwt8z pod의 상태는 ImagePullBackOff입니다. 이 상태는 카탈로그 소스의 인덱스 이미지를 가져오는 데 문제가 있음을 나타냅니다.

4. 자세한 정보는 oc describe 명령을 사용하여 Pod를 검사합니다.

   $ oc describe pod example-catalog-bwt8z -n openshift-marketplace

   출력 예

   Name:         example-catalog-bwt8z
   Namespace:    openshift-marketplace
   Priority:     0
   Node:         ci-ln-jyryyg2-f76d1-ggdbq-worker-b-vsxjd/10.0.128.2
   ...
   Events:
     Type     Reason          Age                From               Message
     ----     ------          ----               ----               -------
     Normal   Scheduled       48s                default-scheduler  Successfully assigned openshift-marketplace/example-catalog-bwt8z to ci-ln-jyryyf2-f76d1-fgdbq-worker-b-vsxjd
     Normal   AddedInterface  47s                multus             Add eth0 [10.131.0.40/23] from openshift-sdn
     Normal   BackOff         20s (x2 over 46s)  kubelet            Back-off pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          20s (x2 over 46s)  kubelet            Error: ImagePullBackOff
     Normal   Pulling         8s (x3 over 47s)   kubelet            Pulling image "quay.io/example-org/example-catalog:v1"
     Warning  Failed          8s (x3 over 47s)   kubelet            Failed to pull image "quay.io/example-org/example-catalog:v1": rpc error: code = Unknown desc = reading manifest v1 in quay.io/example-org/example-catalog: unauthorized: access to the requested resource is not authorized
     Warning  Failed          8s (x3 over 47s)   kubelet            Error: ErrImagePull

   앞의 예제 출력에서 오류 메시지는 권한 부여 문제로 인해 카탈로그 소스의 인덱스 이미지를 성공적으로 가져오지 못한 것으로 표시됩니다. 예를 들어 인덱스 이미지는 로그인 인증 정보가 필요한 레지스트리에 저장할 수 있습니다.

프로세스

1. 새 네임스페이스를 생성합니다.

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: scoped
   EOF

2. Operator를 제한할 권한을 할당합니다. 이를 위해서는 새 서비스 계정, 관련 역할, 역할 바인딩을 생성해야 합니다.

   $ cat <<EOF | oc create -f -
   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: scoped
     namespace: scoped
   EOF

   다음 예제에서는 간소화를 위해 지정된 네임스페이스에서 모든 작업을 수행할 수 있는 서비스 계정 권한을 부여합니다. 프로덕션 환경에서는 더 세분화된 권한 세트를 생성해야 합니다.

   $ cat <<EOF | oc create -f -
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: scoped
     namespace: scoped
   rules:
   - apiGroups: ["*"]
     resources: ["*"]
     verbs: ["*"]
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: scoped-bindings
     namespace: scoped
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: scoped
   subjects:
   - kind: ServiceAccount
     name: scoped
     namespace: scoped
   EOF

3. 지정된 네임스페이스에 OperatorGroup 오브젝트를 생성합니다. 이 Operator group은 지정된 네임스페이스를 대상으로 하여 테넌시가 제한되도록 합니다.

   또한 Operator group에서는 사용자가 서비스 계정을 지정할 수 있습니다. 이전 단계에서 생성한 서비스 계정을 지정합니다.

   $ cat <<EOF | oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: scoped
     namespace: scoped
   spec:
     serviceAccountName: scoped
     targetNamespaces:
     - scoped
   EOF

   지정된 네임스페이스에 설치된 Operator는 모두 이 Operator group 및 지정된 서비스 계정에 연결됩니다.

4. 지정된 네임스페이스에 Subscription 오브젝트를 생성하여 Operator를 설치합니다.

   $ cat <<EOF | oc create -f -
   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: etcd
     namespace: scoped
   spec:
     channel: singlenamespace-alpha
     name: etcd
     source: <catalog_source_name> 1
     sourceNamespace: <catalog_source_namespace> 2
   EOF

   1

   지정된 네임스페이스에 이미 존재하는 카탈로그 소스 또는 글로벌 카탈로그 네임스페이스에 있는 카탈로그 소스를 지정합니다.

   2

   카탈로그 소스가 생성된 네임스페이스를 지정합니다.

   Operator group에 연결된 모든 Operator의 권한이 지정된 서비스 계정에 부여된 권한으로 제한됩니다. Operator에서 서비스 계정 외부에 있는 권한을 요청하는 경우 설치가 실패하고 관련 오류가 표시됩니다.

프로세스

1. Subscription 오브젝트를 검토합니다. 해당 상태에는 Operator에 필요한 [Cluster]Role[Binding] 오브젝트를 생성하는 InstallPlan 오브젝트를 가리키는 오브젝트 참조 installPlanRef가 있습니다.

   apiVersion: operators.coreos.com/v1
   kind: Subscription
   metadata:
     name: etcd
     namespace: scoped
   status:
     installPlanRef:
       apiVersion: operators.coreos.com/v1
       kind: InstallPlan
       name: install-4plp8
       namespace: scoped
       resourceVersion: "117359"
       uid: 2c1df80e-afea-11e9-bce3-5254009c9c23

2. InstallPlan 오브젝트의 상태에 오류가 있는지 확인합니다.

   apiVersion: operators.coreos.com/v1
   kind: InstallPlan
   status:
     conditions:
     - lastTransitionTime: "2019-07-26T21:13:10Z"
       lastUpdateTime: "2019-07-26T21:13:10Z"
       message: 'error creating clusterrole etcdoperator.v0.9.4-clusterwide-dsfx4: clusterroles.rbac.authorization.k8s.io
         is forbidden: User "system:serviceaccount:scoped:scoped" cannot create resource
         "clusterroles" in API group "rbac.authorization.k8s.io" at the cluster scope'
       reason: InstallComponentFailed
       status: "False"
       type: Installed
     phase: Failed

   오류 메시지에는 다음이 표시됩니다.

   • 리소스의 API 그룹을 포함하여 생성할 수 없는 리소스 유형. 이 경우 rbac.authorization.k8s.io 그룹의 clusterroles입니다.
   • 리소스의 이름.
   • 오류 유형 is forbidden은 사용자에게 작업을 수행할 수 있는 권한이 충분하지 않음을 나타냅니다.
   • 리소스를 생성하거나 업데이트하려고 시도한 사용자의 이름. 이 경우 Operator group에 지정된 서비스 계정을 나타냅니다.

   • 작업 범위: cluster scope 여부

     사용자는 서비스 계정에 누락된 권한을 추가한 다음 다시 수행할 수 있습니다.

     참고

     OLM(Operator Lifecycle Manager)은 현재 첫 번째 시도에서 전체 오류 목록을 제공하지 않습니다.

절차

1. 웹 콘솔의 관리자 화면에서 관리자 → 클러스터 설정으로 이동합니다.
2. 글로벌 구성 탭을 클릭한 다음 OperatorHub를 클릭합니다.
3. 소스 탭을 클릭합니다.
4. 제거할 카탈로그의 옵션 메뉴 를 선택한 다음 카탈로그 소스 삭제를 클릭합니다.

절차

1. registry.redhat.io로 인증합니다.

   $ podman login registry.redhat.io

2. 대상 레지스트리로 인증합니다.

   $ podman login <target_registry>

3. 정리된 인덱스에 포함하려는 패키지 목록을 결정합니다.

   1. 컨테이너에서 정리하려는 소스 인덱스 이미지를 실행합니다. 예를 들면 다음과 같습니다.

      $ podman run -p50051:50051 \
          -it registry.redhat.io/redhat/redhat-operator-index:v4.6

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.6...
      Getting image source signatures
      Copying blob ae8a0c23f5b1 done
      ...
      INFO[0000] serving registry                              database=/database/index.db port=50051

   2. 별도의 터미널 세션에서 grpcurl 명령을 사용하여 인덱스에서 제공하는 패키지 목록을 가져옵니다.

      $ grpcurl -plaintext localhost:50051 api.Registry/ListPackages > packages.out

   3. packages.out 파일을 검사하고 정리된 인덱스에 보관할 이 목록에 있는 패키지 이름을 확인합니다. 예를 들면 다음과 같습니다.

      패키지 목록 조각의 예

      ...
      {
        "name": "advanced-cluster-management"
      }
      ...
      {
        "name": "jaeger-product"
      }
      ...
      {
      {
        "name": "quay-operator"
      }
      ...

   4. podman run 명령을 실행한 터미널 세션에서 Ctrl 및 C를 눌러 컨테이너 프로세스를 중지합니다.

4. 다음 명령을 실행하여 지정된 패키지를 제외한 소스 인덱스를 모두 정리합니다.

   $ opm index prune \
       -f registry.redhat.io/redhat/redhat-operator-index:v4.6 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.6] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6 4

   1

   정리할 인덱스입니다.

   2

   쉼표로 구분된 보관할 패키지 목록입니다.

   3

   IBM Power Systems 및 IBM Z 이미지에만 필요합니다. 대상 OpenShift Container Platform 클러스터 주 버전 및 부 버전과 일치하는 태그가 있는 Operator 레지스트리 기본 이미지입니다.

   4

   빌드 중인 새 인덱스 이미지에 대한 사용자 정의 태그입니다.

5. 다음 명령을 실행하여 새 인덱스 이미지를 대상 레지스트리로 내보냅니다.

   $ podman push <target_registry>:<port>/<namespace>/redhat-operator-index:v4.6

   <namespace>는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

프로세스

1. Red Hat 제공 카탈로그를 미러링하려면 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 registry.redhat.io로 인증합니다.

   $ podman login registry.redhat.io

2. oc adm catalog mirror 명령은 인덱스 이미지의 콘텐츠를 추출하여 미러링에 필요한 매니페스트를 생성합니다. 명령의 기본 동작은 매니페스트를 생성한 다음 인덱스 이미지 자체뿐만 아니라 인덱스 이미지의 모든 이미지 콘텐츠를 미러 레지스트리에 자동으로 미러링합니다. 또는 미러 레지스트리가 완전히 연결이 끊긴 호스트 또는 에어갭(Airgap) 호스트에 있는 경우 먼저 콘텐츠를 이동식 미디어로 미러링하고 미디어를 연결이 끊긴 환경으로 이동한 다음 미디어에서 레지스트리로 해당 콘텐츠를 미러링할 수 있습니다.

   • 옵션 A: 미러 레지스트리가 무제한 네트워크 액세스 권한이 있는 워크스테이션과 동일한 네트워크에 있는 경우 워크스테이션에서 다음 작업을 수행합니다.

     1. 미러 레지스트리에 인증이 필요한 경우 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>

     2. 다음 명령을 실행하여 콘텐츠를 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \3
            [--insecure] \4
            [--index-filter-by-os='<platform>/<arch>'] \5
            [--manifests-only] 6

        1

        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.6 과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.

        2

        Operator 콘텐츠를 미러링할 대상 레지스트리 및 네임스페이스의 정규화된 도메인 이름(FQDN)을 지정합니다. 여기서 <namespace> 는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

        3

        선택 사항: 필요한 경우 registry. redhat.io 에 {REG_CREDS} 가 필요합니다.

        4

        선택 사항: 대상 레지스트리에 대한 신뢰성을 구성하지 않으려면 --insecure 플래그를 추가합니다.

        5

        선택 사항: 여러 변형을 사용할 수 있을 때 선택할 인덱스 이미지의 플랫폼 및 아키텍처를 지정합니다. 이미지는 '<platform>/<arch>[/<variant>]’로 전달됩니다. 이는 인덱스에서 참조하는 이미지에는 적용되지 않습니다. 유효한 값은 linux/amd64, linux/ppc64le 및 linux/s390x입니다.

        6

        선택 사항: 미러링에 필요한 매니페스트만 생성하고 실제로 이미지 콘텐츠를 레지스트리에 미러링하지 않습니다. 이 선택 사항은 미러링할 항목을 검토하는 데 유용할 수 있으며 패키지의 서브 세트만 필요한 경우 매핑 목록을 변경할 수 있습니다. 그런 다음 oc image mirror 명령과 함께 mapping.txt 파일을 사용하여 이후 단계에서 수정된 이미지 목록을 미러링할 수 있습니다. 이 플래그는 카탈로그에서 콘텐츠의 고급 선택적 미러링에만 사용됩니다. 이전에 인덱스 이미지를 정리하기 위해 사용한 경우 opm index prune 명령은 대부분의 카탈로그 관리 사용 사례에 적합합니다.

        출력 예

        src image has index label for database path: /database/index.db
        using database path mapping: /database/index.db:/tmp/153048078
        wrote database to /tmp/153048078 1
        ...
        wrote mirroring manifests to manifests-redhat-operator-index-1614211642 2

        1

        명령으로 생성된 임시 index.db 데이터베이스용 디렉터리입니다.

        2

        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.

        참고

        Red Hat Quay는 중첩 리포지토리를 지원하지 않습니다. 결과적으로 oc adm catalog mirror 명령을 실행하면 401 무단 오류와 함께 실패합니다. 이 문제를 해결하려면 oc adm catalog mirror 명령을 실행할 때 --max-components=2 옵션을 사용하여 중첩된 리포지토리 생성을 비활성화할 수 있습니다. 이 해결 방법에 대한 자세한 내용은 Quay 레지스트리 Knowledgebase 솔루션과 함께 catalog mirror 명령을 사용하는 동안 인가되지 않은 오류가 발생한 것을 참조하십시오.

   • 옵션 B: 미러 레지스트리가 연결이 끊긴 호스트에 있는 경우 다음 작업을 수행합니다.

     1. 무제한 네트워크 액세스 권한이 있는 워크스테이션에서 다음 명령을 실행하여 콘텐츠를 로컬 파일에 미러링합니다.

        $ oc adm catalog mirror \
            <index_image> \1
            file:///local/index \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        미러링할 카탈로그의 인덱스 이미지를 지정합니다. 예를 들어 이전에 생성한 정리된 인덱스 이미지 또는 registry.redhat.io/redhat/redhat-operator-index:v4.6 과 같은 기본 카탈로그의 소스 인덱스 이미지 중 하나일 수 있습니다.

        2

        현재 디렉터리의 로컬 파일에 콘텐츠를 미러링합니다.

        출력 예

        ...
        info: Mirroring completed in 5.93s (5.915MB/s)
        wrote mirroring manifests to manifests-my-index-1614985528 1
        
        To upload local images to a registry, run:
        
        	oc adm catalog mirror file://local/index/myrepo/my-index:v1 REGISTRY/REPOSITORY 2

        1

        생성된 매니페스트 디렉터리 이름을 기록합니다. 이 디렉터리 이름은 이후 단계에서 사용됩니다.

        2

        제공된 인덱스 이미지를 기반으로 확장된 file:// 경로를 기록합니다. 이 경로는 이후 단계에서 사용됩니다.

     2. 현재 디렉터리에 생성된 v2/ 디렉터리를 이동식 미디어로 복사합니다.
     3. 물리적으로 미디어를 제거하고 연결이 끊긴 환경의 호스트에 연결하여 미러 레지스트리에 액세스할 수 있습니다.

     4. 미러 레지스트리에 인증이 필요한 경우 연결이 끊긴 환경의 호스트에서 다음 명령을 실행하여 레지스트리에 로그인합니다.

        $ podman login <mirror_registry>

     5. v2/ 디렉터리가 포함된 상위 디렉터리에서 다음 명령을 실행하여 로컬 파일에서 미러 레지스트리로 이미지를 업로드합니다.

        $ oc adm catalog mirror \
            file://local/index/<repo>/<index_image>:<tag> \1
            <mirror_registry>:<port>/<namespace> \2
            [-a ${REG_CREDS}] \
            [--insecure]

        1

        이전 명령 출력의 file:// 경로를 지정합니다.

        2

        Operator 콘텐츠를 미러링할 대상 레지스트리 및 네임스페이스의 정규화된 도메인 이름(FQDN)을 지정합니다. 여기서 <namespace> 는 레지스트리의 기존 네임스페이스입니다. 예를 들어 미러링된 콘텐츠를 모두 내보내기 위해 olm-mirror 네임스페이스를 생성할 수 있습니다.

        참고

        Red Hat Quay는 중첩 리포지토리를 지원하지 않습니다. 결과적으로 oc adm catalog mirror 명령을 실행하면 401 무단 오류와 함께 실패합니다. 이 문제를 해결하려면 oc adm catalog mirror 명령을 실행할 때 --max-components=2 옵션을 사용하여 중첩된 리포지토리 생성을 비활성화할 수 있습니다. 이 해결 방법에 대한 자세한 내용은 Quay 레지스트리 Knowledgebase 솔루션과 함께 catalog mirror 명령을 사용하는 동안 인가되지 않은 오류가 발생한 것을 참조하십시오.

3. 콘텐츠를 레지스트리에 미러링한 후 현재 디렉터리에 생성된 매니페스트 디렉터리를 검사합니다.

   참고

   매니페스트 디렉터리 이름은 이후 단계에서 사용됩니다.

   이전 단계에서 동일한 네트워크의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

   manifests-<index_image_name>-<random_number>

   이전 단계에서 연결이 끊긴 호스트의 레지스트리에 콘텐츠를 미러링한 경우 디렉터리 이름은 다음 형식을 취합니다.

   manifests-index/<namespace>/<index_image_name>-<random_number>

   매니페스트 디렉터리에는 다음 파일이 포함되어 있으며, 이 중 일부는 추가 수정이 필요할 수 있습니다.

   • catalogSource.yaml 파일은 인덱스 이미지 태그 및 기타 관련 메타데이터로 미리 채워진 CatalogSource 오브젝트에 대한 기본 정의입니다. 이 파일은 있는 그대로 사용하거나 카탈로그 소스를 클러스터에 추가하도록 수정할 수 있습니다.

     중요

     콘텐츠를 로컬 파일에 미러링한 경우 metadata.name 필드에서 .name 필드에서 백슬래시(/) 문자를 제거하려면 catalogSource.yaml 파일을 수정해야 합니다. 그러지 않으면 오브젝트 생성을 시도할 때 "잘못된 리소스 이름" 오류로 인해 실패합니다.

   • imageContentSourcePolicy.yaml 파일은 Operator 매니페스트에 저장된 이미지 참조와 미러링된 레지스트리 간에 변환하도록 노드를 구성할 수 있는 ImageContentSourcePolicy 오브젝트를 정의합니다.

     참고

     클러스터에서 ImageContentSourcePolicy 오브젝트를 사용하여 저장소 미러링을 구성하는 경우 미러링된 레지스트리에 대한 글로벌 풀 시크릿만 사용할 수 있습니다. 프로젝트에 풀 시크릿을 추가할 수 없습니다.

   • mapping.txt 파일에는 모든 소스 이미지와 대상 레지스트리에서 매핑할 위치가 포함되어 있습니다. 이 파일은 oc image mirror 명령과 호환되며 미러링 구성을 추가로 사용자 정의하는 데 사용할 수 있습니다.

     중요

     미러링 프로세스 중 --manifests-only 플래그를 사용한 후 미러링할 패키지의 서브 세트를 추가로 트리밍하려면 mapping.txt 파일을 수정하고 oc image mirror 명령으로 파일을 사용하는 데 대한 “패키지 매니페스트 형식 카탈로그 이미지 미러링” 절차의 단계를 참조하십시오. 추가 조치를 수행한 후 이 프로세스를 계속할 수 있습니다.

4. 연결 해제된 클러스터에 액세스할 수 있는 호스트에서 매니페스트 디렉터리에 imageContentSourcePolicy.yaml 파일을 지정하도록 다음 명령을 실행하여 ImageContentSourcePolicy 오브젝트를 생성합니다.

   $ oc create -f <path/to/manifests/dir>/imageContentSourcePolicy.yaml

   여기서 <path/to/manifests/dir>은 미러링된 콘텐츠의 매니페스트 디렉터리 경로입니다.

프로세스

1. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다. oc adm catalog mirror 명령을 사용하여 카탈로그를 대상 레지스트리에 미러링하는 경우 생성된 catalogSource.yaml 파일을 시작점으로 사용할 수 있습니다.

   1. 다음을 사양에 맞게 수정하고 catalogsource.yaml 파일로 저장합니다.

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog 1
        namespace: openshift-marketplace 2
      spec:
        sourceType: grpc
        image: <registry>:<port>/<namespace>/redhat-operator-index:v4.6 3
        displayName: My Operator Catalog
        publisher: <publisher_name> 4
        updateStrategy:
          registryPoll: 5
            interval: 30m

      1

      레지스트리에 업로드하기 전에 콘텐츠를 로컬 파일에 미러링한 경우 오브젝트를 생성할 때 "잘못된 리소스 이름" 오류가 발생하지 않도록 metadata.name 필드에서 백슬래시(/) 문자를 제거합니다.

      2

      카탈로그 소스를 모든 네임스페이스의 사용자가 전역적으로 사용할 수 있도록 하려면 openshift-marketplace 네임스페이스를 지정합니다. 그러지 않으면 카탈로그의 범위가 지정되고 해당 네임스페이스에 대해서만 사용할 수 있도록 다른 네임스페이스를 지정할 수 있습니다.

      3

      인덱스 이미지를 지정합니다.

      4

      카탈로그를 게시하는 이름 또는 조직 이름을 지정합니다.

      5

      카탈로그 소스는 새 버전을 자동으로 확인하여 최신 상태를 유지할 수 있습니다.

   2. 파일을 사용하여 CatalogSource 오브젝트를 생성합니다.

      $ oc apply -f catalogSource.yaml

2. 다음 리소스가 성공적으로 생성되었는지 확인합니다.

   1. Pod를 확인합니다.

      $ oc get pods -n openshift-marketplace

      출력 예

      NAME                                    READY   STATUS    RESTARTS  AGE
      my-operator-catalog-6njx6               1/1     Running   0         28s
      marketplace-operator-d9f549946-96sgr    1/1     Running   0         26h

   2. 카탈로그 소스를 확인합니다.

      $ oc get catalogsource -n openshift-marketplace

      출력 예

      NAME                  DISPLAY               TYPE PUBLISHER  AGE
      my-operator-catalog   My Operator Catalog   grpc            5s

   3. 패키지 매니페스트 확인합니다.

      $ oc get packagemanifest -n openshift-marketplace

      출력 예

      NAME                          CATALOG               AGE
      jaeger-product                My Operator Catalog   93s

프로세스

1. 번들 이미지를 추가하여 기존 인덱스를 업데이트합니다.

   $ opm index add \
       --bundles <registry>/<namespace>/<new_bundle_image>@sha256:<digest> \1
       --from-index <registry>/<namespace>/<existing_index_image>:<existing_tag> \2
       --tag <registry>/<namespace>/<existing_index_image>:<updated_tag> \3
       --pull-tool podman 4

   1

   --bundles 플래그는 인덱스에 추가할 추가 번들 이미지의 쉼표로 구분된 목록을 지정합니다.

   2

   --from-index 플래그는 이전에 내보낸 인덱스를 지정합니다.

   3

   --tag 플래그는 업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다.

   4

   pull-tool 플래그는 컨테이너 이미지를 가져오는 데 사용하는 툴을 지정합니다.

   다음과 같습니다.

   <registry>

   quay.io 또는 mirror.example. com 과 같은 레지스트리의 호스트 이름을 지정합니다.

   <namespace>

   ocs-dev 또는 abc 와 같은 레지스트리의 네임스페이스를 지정합니다.

   <new_bundle_image>

   ocs-operator 와 같이 레지스트리에 추가할 새 번들 이미지를 지정합니다.

   <digest>

   번들 이미지의 SHA 이미지 ID 또는 다이제스트를 지정합니다(예: c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41).

   <existing_index_image>

   이전에 내보낸 이미지를 지정합니다(예: abc-redhat-operator-index ).

   <existing_tag>

   4.6 과 같이 이전에 푸시된 이미지 태그를 지정합니다.

   <updated_tag>

   4.6.1 과 같이 업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다.

   명령 예

   $ opm index add \
       --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
       --from-index mirror.example.com/abc/abc-redhat-operator-index:4.6 \
       --tag mirror.example.com/abc/abc-redhat-operator-index:4.6.1 \
       --pull-tool podman

2. 업데이트된 인덱스 이미지를 내보냅니다.

   $ podman push <registry>/<namespace>/<existing_index_image>:<updated_tag>

3. Operator 카탈로그 미러링 절차에 있는 단계를 다시 수행하여 업데이트된 콘텐츠를 미러링합니다. 그러나 ICSP(ImageContentSourcePolicy) 오브젝트 생성에 대한 단계에 도달하면 oc create 명령 대신 oc replace 명령을 사용합니다. 예를 들면 다음과 같습니다.

   $ oc replace -f ./manifests-redhat-operator-index-<random_number>/imageContentSourcePolicy.yaml

   이 변경 사항은 오브젝트가 이미 존재하고 업데이트해야 하므로 필요합니다.

   참고

   일반적으로 oc apply 명령을 사용하여 이전에 oc apply를 사용하여 생성한 기존 오브젝트를 업데이트할 수 있습니다. 그러나 ICSP 오브젝트의 metadata.annotations 필드 크기와 관련하여 알려진 문제로 인해 현재 이 단계에 oc replace 명령을 사용해야 합니다.

4. OLM(Operator Lifecycle Manager)이 정기적으로 카탈로그 소스에서 참조하는 인덱스 이미지를 자동으로 폴링하면 새 패키지가 성공적으로 추가되었는지 확인합니다.

   $ oc get packagemanifests -n openshift-marketplace

1. Operator SDK CLI(명령줄 인터페이스)를 사용하여 Operator 프로젝트를 생성합니다.
2. CRD(사용자 정의 리소스 정의)를 추가하여 새 리소스 API를 정의합니다.
3. Operator SDK API를 사용하여 조사할 리소스를 지정합니다.
4. 지정된 핸들러에서 Operator 조정 논리를 정의하고 Operator SDK API를 사용하여 리소스와 상호 작용합니다.
5. Operator SDK CLI를 사용하여 Operator 배포 매니페스트를 빌드하고 생성합니다.

프로세스

1. 릴리스 버전 변수를 설정합니다.

   $ RELEASE_VERSION=v0.19.4

2. 릴리스 바이너리를 다운로드합니다.

   • Linux의 경우:

     $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu

   • macOS의 경우:

     $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin

3. 다운로드한 릴리스 바이너리를 확인합니다.

   1. 제공된 .asc 파일을 다운로드합니다.

      • Linux의 경우:

        $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu.asc

      • macOS의 경우:

        $ curl -OJL https://github.com/operator-framework/operator-sdk/releases/download/${RELEASE_VERSION}/operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin.asc

   2. 바이너리 및 해당 .asc 파일을 동일한 디렉터리에 배치하고 다음 명령을 실행하여 바이너리를 확인합니다.

      • Linux의 경우:

        $ gpg --verify operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu.asc

      • macOS의 경우:

        $ gpg --verify operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin.asc

      워크스테이션에 관리자의 공개 키가 없는 경우 다음과 같은 오류가 발생합니다.

      오류가 있는 출력 예

      $ gpg: assuming signed data in 'operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin'
      $ gpg: Signature made Fri Apr  5 20:03:22 2019 CEST
      $ gpg:                using RSA key <key_id> 1
      $ gpg: Can't check signature: No public key

      1

      RSA 키 문자열.

      키를 다운로드하려면 다음 명령을 실행하여 <key_id> 를 이전 명령의 출력에 제공된 RSA 키 문자열로 바꿉니다.

      $ gpg [--keyserver keys.gnupg.net] --recv-key "<key_id>" 1

      1

      키 서버가 구성되지 않은 경우 --keyserver 옵션을 사용하여 하나를 지정합니다.

4. PATH 에 릴리스 바이너리를 설치합니다.

   • Linux의 경우:

     $ chmod +x operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu

     $ sudo cp operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu /usr/local/bin/operator-sdk

     $ rm operator-sdk-${RELEASE_VERSION}-x86_64-linux-gnu

   • macOS의 경우:

     $ chmod +x operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin

     $ sudo cp operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin /usr/local/bin/operator-sdk

     $ rm operator-sdk-${RELEASE_VERSION}-x86_64-apple-darwin

5. CLI 도구가 올바르게 설치되었는지 확인합니다.

   $ operator-sdk version

프로세스

1. tag 명령을 사용하여 SDK CLI 를 설치합니다.

   $ brew install operator-sdk

2. CLI 도구가 올바르게 설치되었는지 확인합니다.

   $ operator-sdk version

프로세스

1. operator-sdk 리포지토리를 복제합니다.

   $ git clone https://github.com/operator-framework/operator-sdk

2. 복제된 리포지토리의 디렉터리로 변경합니다.

   $ cd operator-sdk

3. v0.19.4 릴리스를 확인합니다.

   $ git checkout tags/v0.19.4 -b v0.19.4

4. 종속성을 업데이트합니다.

   $ make tidy

5. SDK CLI를 컴파일하고 설치합니다.

   $ make install

   그러면 $GOPATH/bin/ 디렉터리에 CLI 바이너리 operator-sdk 가 설치됩니다.

6. CLI 도구가 올바르게 설치되었는지 확인합니다.

   $ operator-sdk version

절차

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

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

      $ mkdir -p $HOME/projects/memcached-operator

   2. 디렉터리로 변경합니다.

      $ cd $HOME/projects/memcached-operator

   3. Go 모듈에 대한 지원을 활성화합니다.

      $ export GO111MODULE=on

   4. operator-sdk init 명령을 실행하여 프로젝트를 초기화합니다.

      $ operator-sdk init \
          --domain=example.com \
          --repo=github.com/example-inc/memcached-operator

      참고

      operator-sdk init 명령은 기본적으로 go.kubebuilder.io/v2 플러그인을 사용합니다.

2. 지원되는 이미지를 사용하도록 Operator를 업데이트합니다.

   1. 프로젝트 루트 수준 Dockerfile에서 기본 러너 이미지 참조를 에서 변경합니다.

      FROM gcr.io/distroless/static:nonroot

      다음으로 변경합니다.

      FROM registry.access.redhat.com/ubi8/ubi-minimal:latest

   2. Go 프로젝트 버전에 따라 Dockerfile에 USER 65532:65532 또는 USER nonroot:nonroot 지시문이 포함될 수 있습니다. 두 경우 모두 지원되는 실행기 이미지에 행이 필요하지 않으므로 행을 제거합니다.

   3. config/default/manager_auth_proxy_patch.yaml 파일에서 image 값을 변경합니다.

      gcr.io/kubebuilder/kube-rbac-proxy:<tag>

      지원되는 이미지를 사용하려면 다음을 실행합니다.

      registry.redhat.io/openshift4/ose-kube-rbac-proxy:v4.6

3. 다음 행을 대체하여 이후 빌드 중에 필요한 종속성을 설치하도록 Makefile에서 테스트 대상을 업데이트합니다.

   예 5.1. 기존 테스트 대상

   test: generate fmt vet manifests
           go test ./... -coverprofile cover.out

   다음 행을 사용하여 다음을 수행합니다.

   예 5.2. 업데이트된 테스트 대상

   ENVTEST_ASSETS_DIR=$(shell pwd)/testbin
   test: manifests generate fmt vet ## Run tests.
   	mkdir -p ${ENVTEST_ASSETS_DIR}
   	test -f ${ENVTEST_ASSETS_DIR}/setup-envtest.sh || curl -sSLo ${ENVTEST_ASSETS_DIR}/setup-envtest.sh https://raw.githubusercontent.com/kubernetes-sigs/controller-runtime/v0.7.2/hack/setup-envtest.sh
   	source ${ENVTEST_ASSETS_DIR}/setup-envtest.sh; fetch_envtest_tools $(ENVTEST_ASSETS_DIR); setup_envtest_env $(ENVTEST_ASSETS_DIR); go test ./... -coverprofile cover.out

4. CRD(사용자 정의 리소스 정의) API 및 컨트롤러를 생성합니다.

   1. 다음 명령을 실행하여 캐시 버전 v1 및 종류의 Memcached 그룹이 있는 API를 생성합니다.

      $ operator-sdk create api \
          --group=cache \
          --version=v1 \
          --kind=Memcached

   2. 메시지가 표시되면 리소스 및 컨트롤러 모두 생성하도록 y를 입력합니다.

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

      출력 예

      Writing scaffold for you to edit...
      api/v1/memcached_types.go
      controllers/memcached_controller.go
      ...

      이 프로세스는 api/v1/memcached_types.go 에 Memcached 리소스 API를 생성하고 controllers/memcached_controller.go 에 컨트롤러를 생성합니다.

   3. spec 및 status가 다음과 같도록 api/v1/memcached_types.go에서 Go 유형 정의를 수정합니다.

      // MemcachedSpec defines the desired state of Memcached
      type MemcachedSpec struct {
      	// +kubebuilder:validation:Minimum=0
      	// Size is the size of the memcached deployment
      	Size int32 `json:"size"`
      }
      
      // MemcachedStatus defines the observed state of Memcached
      type MemcachedStatus struct {
      	// Nodes are the names of the memcached pods
      	Nodes []string `json:"nodes"`
      }

   4. +kubebuilder:subresource:status 마커를 추가하여 CRD 매니페스트에 status 하위 리소스를 추가합니다.

      // Memcached is the Schema for the memcacheds API
      // +kubebuilder:subresource:status 1
      type Memcached struct {
      	metav1.TypeMeta   `json:",inline"`
      	metav1.ObjectMeta `json:"metadata,omitempty"`
      
      	Spec   MemcachedSpec   `json:"spec,omitempty"`
      	Status MemcachedStatus `json:"status,omitempty"`
      }

      1

      이 행을 추가합니다.

      그러면 컨트롤러에서 CR 오브젝트의 나머지 부분을 변경하지 않고도 CR 상태를 업데이트할 수 있습니다.

   5. 리소스 유형에 대해 생성된 코드를 업데이트합니다.

      $ make generate

      작은 정보

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

      위의 Makefile 대상은 controller-gen 유틸리티를 호출하여 api/v1/zz_generated.deepcopy.go 파일을 업데이트합니다. 이렇게 하면 API Go 유형 정의에서 모든 종류의 유형에서 구현해야 하는 runtime.Object 인터페이스를 구현할 수 있습니다.

5. CRD 매니페스트를 생성하고 업데이트합니다.

   $ make manifests

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

   1. 선택 사항: CRD에 사용자 지정 검증을 추가합니다.

      매니페스트가 생성될 때 spec.validation 블록의 CRD 매니페스트에 OpenAPI v3.0 스키마가 추가됩니다. 이 검증 블록을 사용하면 Kubernetes가 생성 또는 업데이트될 때 Memcached CR(사용자 정의 리소스)의 속성을 검증할 수 있습니다.

      Operator 작성자는 Kubebuilder 마커 라는 주석과 같은 단일 줄 주석을 사용하여 API에 대한 사용자 정의 검증을 구성할 수 있습니다. 이러한 마커에는 항상 +kubebuilder:validation 접두사가 있어야 합니다. 예를 들어 열거형 사양을 추가하는 작업은 다음 마커를 추가하여 수행할 수 있습니다.

      // +kubebuilder:validation:Enum=Lion;Wolf;Dragon
      type Alias string

      API 코드의 마커 사용은 Kubebuilder Generating CRD 및 Markers for Config/Code Generation 설명서에서 설명합니다. 전체 OpenAPIv3 검증 마커 목록은 Kubebuilder CRD 검증 설명서에서도 사용할 수 있습니다.

      사용자 정의 검증을 추가하는 경우 다음 명령을 실행하여 CRD에 대한 OpenAPI 검증 섹션을 업데이트합니다.

      $ make manifests

6. 새 API 및 컨트롤러를 생성하면 컨트롤러 논리를 구현할 수 있습니다. 이 예제에서는 생성된 컨트롤러 파일 controllers/memcached_controller.go를 다음 예제 구현으로 교체합니다.

   예 5.3. memcached_controller.go의 예

   /*
   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at
   
       http://www.apache.org/licenses/LICENSE-2.0
   
   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.
   */
   
   package controllers
   
   import (
   	"context"
   	"reflect"
   
   	"github.com/go-logr/logr"
   	appsv1 "k8s.io/api/apps/v1"
   	corev1 "k8s.io/api/core/v1"
   	"k8s.io/apimachinery/pkg/api/errors"
   	metav1 "k8s.io/apimachinery/pkg/apis/meta/v1"
   	"k8s.io/apimachinery/pkg/runtime"
   	"k8s.io/apimachinery/pkg/types"
   	ctrl "sigs.k8s.io/controller-runtime"
   	"sigs.k8s.io/controller-runtime/pkg/client"
   
   	cachev1 "github.com/example-inc/memcached-operator/api/v1"
   )
   
   // MemcachedReconciler reconciles a Memcached object
   type MemcachedReconciler struct {
   	client.Client
   	Log    logr.Logger
   	Scheme *runtime.Scheme
   }
   
   // +kubebuilder:rbac:groups=cache.example.com,resources=memcacheds,verbs=get;list;watch;create;update;patch;delete
   // +kubebuilder:rbac:groups=cache.example.com,resources=memcacheds/status,verbs=get;update;patch
   // +kubebuilder:rbac:groups=apps,resources=deployments,verbs=get;list;watch;create;update;patch;delete
   // +kubebuilder:rbac:groups=core,resources=pods,verbs=get;list;
   
   func (r *MemcachedReconciler) Reconcile(req ctrl.Request) (ctrl.Result, error) {
   	ctx := context.Background()
   	log := r.Log.WithValues("memcached", req.NamespacedName)
   
   	// Fetch the Memcached instance
   	memcached := &cachev1.Memcached{}
   	err := r.Get(ctx, req.NamespacedName, memcached)
   	if err != nil {
   		if errors.IsNotFound(err) {
   			// Request object not found, could have been deleted after reconcile request.
   			// Owned objects are automatically garbage collected. For additional cleanup logic use finalizers.
   			// Return and don't requeue
   			log.Info("Memcached resource not found. Ignoring since object must be deleted")
   			return ctrl.Result{}, nil
   		}
   		// Error reading the object - requeue the request.
   		log.Error(err, "Failed to get Memcached")
   		return ctrl.Result{}, err
   	}
   
   	// Check if the deployment already exists, if not create a new one
   	found := &appsv1.Deployment{}
   	err = r.Get(ctx, types.NamespacedName{Name: memcached.Name, Namespace: memcached.Namespace}, found)
   	if err != nil && errors.IsNotFound(err) {
   		// Define a new deployment
   		dep := r.deploymentForMemcached(memcached)
   		log.Info("Creating a new Deployment", "Deployment.Namespace", dep.Namespace, "Deployment.Name", dep.Name)
   		err = r.Create(ctx, dep)
   		if err != nil {
   			log.Error(err, "Failed to create new Deployment", "Deployment.Namespace", dep.Namespace, "Deployment.Name", dep.Name)
   			return ctrl.Result{}, err
   		}
   		// Deployment created successfully - return and requeue
   		return ctrl.Result{Requeue: true}, nil
   	} else if err != nil {
   		log.Error(err, "Failed to get Deployment")
   		return ctrl.Result{}, err
   	}
   
   	// Ensure the deployment size is the same as the spec
   	size := memcached.Spec.Size
   	if *found.Spec.Replicas != size {
   		found.Spec.Replicas = &size
   		err = r.Update(ctx, found)
   		if err != nil {
   			log.Error(err, "Failed to update Deployment", "Deployment.Namespace", found.Namespace, "Deployment.Name", found.Name)
   			return ctrl.Result{}, err
   		}
   		// Spec updated - return and requeue
   		return ctrl.Result{Requeue: true}, nil
   	}
   
   	// Update the Memcached status with the pod names
   	// List the pods for this memcached's deployment
   	podList := &corev1.PodList{}
   	listOpts := []client.ListOption{
   		client.InNamespace(memcached.Namespace),
   		client.MatchingLabels(labelsForMemcached(memcached.Name)),
   	}
   	if err = r.List(ctx, podList, listOpts...); err != nil {
   		log.Error(err, "Failed to list pods", "Memcached.Namespace", memcached.Namespace, "Memcached.Name", memcached.Name)
   		return ctrl.Result{}, err
   	}
   	podNames := getPodNames(podList.Items)
   
   	// Update status.Nodes if needed
   	if !reflect.DeepEqual(podNames, memcached.Status.Nodes) {
   		memcached.Status.Nodes = podNames
   		err := r.Status().Update(ctx, memcached)
   		if err != nil {
   			log.Error(err, "Failed to update Memcached status")
   			return ctrl.Result{}, err
   		}
   	}
   
   	return ctrl.Result{}, nil
   }
   
   // deploymentForMemcached returns a memcached Deployment object
   func (r *MemcachedReconciler) deploymentForMemcached(m *cachev1.Memcached) *appsv1.Deployment {
   	ls := labelsForMemcached(m.Name)
   	replicas := m.Spec.Size
   
   	dep := &appsv1.Deployment{
   		ObjectMeta: metav1.ObjectMeta{
   			Name:      m.Name,
   			Namespace: m.Namespace,
   		},
   		Spec: appsv1.DeploymentSpec{
   			Replicas: &replicas,
   			Selector: &metav1.LabelSelector{
   				MatchLabels: ls,
   			},
   			Template: corev1.PodTemplateSpec{
   				ObjectMeta: metav1.ObjectMeta{
   					Labels: ls,
   				},
   				Spec: corev1.PodSpec{
   					Containers: []corev1.Container{{
   						Image:   "memcached:1.4.36-alpine",
   						Name:    "memcached",
   						Command: []string{"memcached", "-m=64", "-o", "modern", "-v"},
   						Ports: []corev1.ContainerPort{{
   							ContainerPort: 11211,
   							Name:          "memcached",
   						}},
   					}},
   				},
   			},
   		},
   	}
   	// Set Memcached instance as the owner and controller
   	ctrl.SetControllerReference(m, dep, r.Scheme)
   	return dep
   }
   
   // labelsForMemcached returns the labels for selecting the resources
   // belonging to the given memcached CR name.
   func labelsForMemcached(name string) map[string]string {
   	return map[string]string{"app": "memcached", "memcached_cr": name}
   }
   
   // getPodNames returns the pod names of the array of pods passed in
   func getPodNames(pods []corev1.Pod) []string {
   	var podNames []string
   	for _, pod := range pods {
   		podNames = append(podNames, pod.Name)
   	}
   	return podNames
   }
   
   func (r *MemcachedReconciler) SetupWithManager(mgr ctrl.Manager) error {
   	return ctrl.NewControllerManagedBy(mgr).
   		For(&cachev1.Memcached{}).
   		Owns(&appsv1.Deployment{}).
   		Complete(r)
   }

   예제 컨트롤러는 각 Memcached CR에 대해 다음 조정 논리를 실행합니다.

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

   다음 두 하위 단계에서는 컨트롤러에서 리소스를 감시하는 방법과 조정 반복문이 트리거되는 방법을 검사합니다. 이러한 단계를 건너뛰어 Operator를 직접 빌드하고 실행할 수 있습니다.

   1. controllers/memcached_controller.go 파일에서 컨트롤러 구현을 검사하여 컨트롤러에서 리소스를 감시하는 방법을 확인합니다.

      SetupWithManager() 함수는 해당 컨트롤러가 소유하고 관리하는 CR 및 기타 리소스를 조사하기 위해 컨트롤러가 빌드되는 방법을 지정합니다.

      예 5.4. SetupWithManager() 함수

      import (
      	...
      	appsv1 "k8s.io/api/apps/v1"
      	...
      )
      
      func (r *MemcachedReconciler) SetupWithManager(mgr ctrl.Manager) error {
      	return ctrl.NewControllerManagedBy(mgr).
      		For(&cachev1.Memcached{}).
      		Owns(&appsv1.Deployment{}).
      		Complete(r)
      }

      NewControllerManagedBy()에서는 다양한 컨트롤러 구성을 허용하는 컨트롤러 빌더를 제공합니다.

      For(&cachev1.Memcached{})는 조사할 기본 리소스로 Memcached 유형을 지정합니다. Memcached 유형에 대한 각 추가, 업데이트 또는 삭제 이벤트의 경우 조정 반복문은 해당 Memcached 오브젝트의 조정 Request 인수(네임스페이스 및 이름 키로 구성됨)로 전송됩니다.

      Owns(&appsv1.Deployment{})는 조사할 보조 리소스로 Deployment 유형을 지정합니다. 이벤트 핸들러는 Deployment 유형, 즉 추가, 업데이트 또는 삭제 이벤트가 발생할 때마다 각 이벤트를 배포 소유자의 조정 요청에 매핑합니다. 이 경우 소유자는 배포가 생성된 Memcached 오브젝트입니다.

   2. 모든 컨트롤러에는 조정 반복문을 구현하는 Reconcile() 메서드가 포함된 조정기 오브젝트가 있습니다. 조정 반복문에는 캐시에서 기본 리소스 오브젝트인 Memcached를 찾는 데 사용되는 네임스페이스 및 이름 키인 Request 인수가 전달됩니다.

      예 5.5. 조정 반복문

      import (
      	ctrl "sigs.k8s.io/controller-runtime"
      
      	cachev1 "github.com/example-inc/memcached-operator/api/v1"
      	...
      )
      
      func (r *MemcachedReconciler) Reconcile(ctx context.Context, req ctrl.Request) (ctrl.Result, error) {
        // Lookup the Memcached instance for this reconcile request
        memcached := &cachev1.Memcached{}
        err := r.Get(ctx, req.NamespacedName, memcached)
        ...
      }

      Reconcile() 함수의 반환 값에 따라 조정 요청이 다시 큐에 추가될 수 있으며 루프가 다시 트리거될 수 있습니다.

      예 5.6. 대기열 논리 재지정

      // Reconcile successful - don't requeue
      return reconcile.Result{}, nil
      // Reconcile failed due to error - requeue
      return reconcile.Result{}, err
      // Requeue for any reason other than error
      return reconcile.Result{Requeue: true}, nil

      유예 기간 후 요청을 다시 큐에 추가하도록 Result.RequeueAfter 를 설정할 수 있습니다.

      예 5.7. 유예 기간 후 다시 큐에 추가

      import "time"
      
      // Reconcile for any reason other than an error after 5 seconds
      return ctrl.Result{RequeueAfter: time.Second*5}, nil

      참고

      주기적으로 CR을 조정하도록 RequeueAfter를 설정하여 Result를 반환할 수 있습니다.

      조정기, 클라이언트, 리소스 이벤트와의 상호 작용에 대한 자세한 내용은 Controller Runtime Client API 설명서를 참조하십시오.

프로세스

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

   $ oc project memcached-operator-system

2. 다음 사양을 포함하도록 config/samples/cache_v1_memcached.yaml의 샘플 Memcached CR 매니페스트를 편집합니다.

   apiVersion: cache.example.com/v1
   kind: Memcached
   metadata:
     name: memcached-sample
   ...
   spec:
   ...
     size: 3

3. CR을 생성합니다.

   $ oc apply -f config/samples/cache_v1_memcached.yaml

4. Memcached Operator에서 샘플 CR에 대한 배포를 올바른 크기로 생성하는지 확인합니다.

   $ oc get deployments

   출력 예

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

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

   1. Pod를 확인합니다.

      $ oc get pods

      출력 예

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

   2. CR 상태 확인:

      $ oc get memcached/memcached-sample -o yaml

      출력 예

      apiVersion: cache.example.com/v1
      kind: Memcached
      metadata:
      ...
        name: memcached-sample
      ...
      spec:
        size: 3
      status:
        nodes:
        - memcached-sample-6fd7c98d8-7dqdr
        - memcached-sample-6fd7c98d8-g5k7v
        - memcached-sample-6fd7c98d8-m7vn7

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

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

      $ oc patch memcached memcached-sample \
          -p '{"spec":{"size": 5}}' \
          --type=merge

   2. Operator에서 배포 크기를 변경하는지 확인합니다.

      $ oc get deployments

      출력 예

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

프로세스

1. 새 Operator 프로젝트를 생성합니다. 네임스페이스 범위의 Operator는 단일 네임스페이스에서 리소스를 감시하고 관리합니다. 유연성으로 인해 네임스페이스 범위의 Operator가 선호됩니다. 이를 통해 분리된 업그레이드, 장애 및 모니터링을 위한 네임스페이스 격리, 다양한 API 정의를 사용할 수 있습니다.

   새 Ansible 기반 네임스페이스 범위의 memcached-operator 프로젝트를 생성하고 새 디렉터리로 변경하려면 다음 명령을 사용합니다.

   $ operator-sdk new memcached-operator \
       --api-version=cache.example.com/v1alpha1 \
       --kind=Memcached \
       --type=ansible

   $ cd memcached-operator

   이렇게 하면 API 버전 example.com/v1apha1 및 종류 Memcached가 있는 Memcached 리소스를 조사하기 위해 memcached-operator 프로젝트가 생성됩니다 .

2. Operator 논리를 사용자 지정합니다.

   이 예에서는 memcached-operator 에서 각 Memcached CR(사용자 정의 리소스)에 대해 다음 조정 논리를 실행합니다.

   • memcached 배포가 없는 경우 해당 배포를 생성합니다.
   • 배포 크기가 Memcached CR에서 지정한 것과 같은지 확인합니다.

   기본적으로 memcached-operator 는 watches.yaml 파일에 표시된 대로 Memcached 리소스 이벤트를 감시하고 Ansible 역할 Memcached 를 실행합니다.

   - version: v1alpha1
     group: cache.example.com
     kind: Memcached

   선택적으로 watches.yaml 파일에서 다음 논리를 사용자 지정할 수 있습니다.

   1. 역할 옵션을 지정하면 Ansible 역할로 ansible-runner 를 시작할 때 이 지정된 경로를 사용하도록 Operator가 구성됩니다. 기본적으로 operator-sdk new 명령은 역할이 이동해야 하는 절대 경로를 채웁니다.

      - version: v1alpha1
        group: cache.example.com
        kind: Memcached
        role: /opt/ansible/roles/memcached

   2. watches.yaml 파일에서 플레이북 옵션을 지정하면 Ansible 플레이북으로 ansible-runner 를 시작할 때 이 지정된 경로를 사용하도록 Operator가 구성됩니다.

      - version: v1alpha1
        group: cache.example.com
        kind: Memcached
        playbook: /opt/ansible/playbook.yaml

3. Memcached Ansible 역할을 빌드합니다.

   roles/memcached/ 디렉터리에서 생성된 Ansible 역할을 수정합니다. 이 Ansible 역할은 리소스를 수정할 때 실행되는 논리를 제어합니다.

   1. Memcached 사양을 정의합니다.

      Ansible 기반 Operator에 대한 사양 정의는 Ansible에서 완전히 수행할 수 있습니다. Ansible Operator는 CR 사양 필드에 나열된 모든 키-값 쌍을 Ansible에 변수로 전달합니다. spec 필드에 있는 모든 변수의 이름은 Ansible을 실행하기 전에 Operator에서 snake 케이스(하위 코어의 소문자)로 변환됩니다. 예를 들어 사양의 serviceAccount는 Ansible에서 service_account로 변환됩니다.

      작은 정보

      애플리케이션에 예상되는 입력을 수신하려면 변수에 대해 Ansible에서 일부 유형 검증을 수행해야 합니다.

      사용자가 spec 필드를 설정하지 않는 경우 roles/memcached/defaults/main.yml 파일을 수정하여 기본값을 설정합니다.

      size: 1

   2. Memcached 배포를 정의합니다.

      Memcached 사양을 정의하면 리소스 변경 시 Ansible이 실제로 실행되는 것을 정의할 수 있습니다. Ansible 역할이므로 기본 동작은 roles/memcached/tasks/main.yml 파일의 작업을 실행합니다.

      목표는 memcached:1.4.36-alpine 이미지를 실행하는 경우 Ansible에서 배포를 생성하는 것입니다. Ansible 2.7+는 배포 정의를 제어하는 데 이 예제를 활용하는 k8s Ansible 모듈을 지원합니다.

      roles/memcached/tasks/main.yml 을 다음과 일치하도록 수정합니다.

      - name: start memcached
        k8s:
          definition:
            kind: Deployment
            apiVersion: apps/v1
            metadata:
              name: '{{ meta.name }}-memcached'
              namespace: '{{ meta.namespace }}'
            spec:
              replicas: "{{size}}"
              selector:
                matchLabels:
                  app: memcached
              template:
                metadata:
                  labels:
                    app: memcached
                spec:
                  containers:
                  - name: memcached
                    command:
                    - memcached
                    - -m=64
                    - -o
                    - modern
                    - -v
                    image: "docker.io/memcached:1.4.36-alpine"
                    ports:
                      - containerPort: 11211

      참고

      이 예제에서는 size 변수를 사용하여 Memcached 배포의 복제본 수를 제어합니다. 이 예제에서는 기본값을 1 로 설정하지만 모든 사용자는 기본값을 덮어쓰는 CR을 생성할 수 있습니다.

4. CRD를 배포합니다.

   Operator를 실행하기 전에 Kubernetes는 Operator가 모니터링할 새 CRD(사용자 정의 리소스 정의)를 알아야 합니다. Memcached CRD를 배포합니다.

   $ oc create -f deploy/crds/cache.example.com_memcacheds_crd.yaml

5. Operator를 빌드하고 실행합니다.

   Operator를 빌드하고 실행하는 방법은 다음 두 가지가 있습니다.

   • Kubernetes 클러스터 내부의 포드로 사용됩니다.
   • operator-sdk up 명령을 사용하여 클러스터 외부의 Go 프로그램으로.

   다음 방법 중 하나를 선택합니다.

   1. Kubernetes 클러스터 내에서 포드로 실행합니다. 이 방법이 프로덕션에 사용하는 데 선호되는 방법입니다.

      1. memcached-operator 이미지를 빌드하여 레지스트리로 내보냅니다.

         $ operator-sdk build quay.io/example/memcached-operator:v0.0.1

         $ podman push quay.io/example/memcached-operator:v0.0.1

      2. 배포 매니페스트는 deploy/operator.yaml 파일에 생성됩니다. 이 파일의 배포 이미지는 플레이스 홀더 REPLACE_IMAGE 에서 이전 빌드 이미지로 수정해야 합니다. 이를 수행하려면 다음을 실행합니다.

         $ sed -i 's|REPLACE_IMAGE|quay.io/example/memcached-operator:v0.0.1|g' deploy/operator.yaml

      3. memcached-operator 매니페스트를 배포합니다.

         $ oc create -f deploy/service_account.yaml

         $ oc create -f deploy/role.yaml

         $ oc create -f deploy/role_binding.yaml

         $ oc create -f deploy/operator.yaml

      4. memcached-operator 배포가 시작되어 실행 중인지 확인합니다.

         $ oc get deployment

         NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
         memcached-operator       1         1         1            1           1m

   2. 클러스터 외부에서 실행합니다. 이 방법은 배포 및 테스트 속도를 높이기 위해 개발 주기 동안 선호됩니다.

      Ansible Runner 및 Ansible Runner HTTP 플러그인이 설치되어 있는지 확인합니다. 그렇지 않으면 CR이 생성될 때 Ansible Runner에서 예기치 않은 오류가 발생합니다.

      또한 watches.yaml 파일에서 참조되는 역할 경로가 시스템에 있어야 합니다. 일반적으로 컨테이너가 디스크에 배치되는 위치이므로 이 역할을 구성된 Ansible 역할 경로(예: /etc/ansible/roles)에 수동으로 복사해야 합니다.

      1. $HOME/.kube/config에 있는 기본 Kubernetes 구성 파일을 사용하여 Operator를 로컬로 실행하려면 다음을 수행합니다.

         $ operator-sdk run --local

         제공된 Kubernetes 구성 파일을 사용하여 Operator를 로컬로 실행하려면 다음을 수행합니다.

         $ operator-sdk run --local --kubeconfig=config

6. Memcached CR을 생성합니다.

   1. 표시된 대로 deploy/crds/cache_v1alpha1_memcached_cr.yaml 파일을 수정하고 Memcached CR을 생성합니다.

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      출력 예

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 3

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. memcached-operator 가 CR에 대한 배포를 생성하는지 확인합니다.

      $ oc get deployment

      출력 예

      NAME                     DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      memcached-operator       1         1         1            1           2m
      example-memcached        3         3         3            3           1m

   3. Pod에서 세 개의 복제본이 생성되었는지 확인합니다.

      $ oc get pods

      NAME                                  READY     STATUS    RESTARTS   AGE
      example-memcached-6fd7c98d8-7dqdr     1/1       Running   0          1m
      example-memcached-6fd7c98d8-g5k7v     1/1       Running   0          1m
      example-memcached-6fd7c98d8-m7vn7     1/1       Running   0          1m
      memcached-operator-7cc7cfdf86-vvjqk   1/1       Running   0          2m

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

   1. memcached CR의 spec.size 필드를 3 에서 4 로 변경하고 변경 사항을 적용합니다.

      $ cat deploy/crds/cache_v1alpha1_memcached_cr.yaml

      출력 예

      apiVersion: "cache.example.com/v1alpha1"
      kind: "Memcached"
      metadata:
        name: "example-memcached"
      spec:
        size: 4

      $ oc apply -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   2. Operator에서 배포 크기를 변경하는지 확인합니다.

      $ oc get deployment

      출력 예

      NAME                 DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
      example-memcached    4         4         4            4           5m

8. 리소스를 정리합니다.

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_cr.yaml

   $ oc delete -f deploy/operator.yaml

   $ oc delete -f deploy/role_binding.yaml

   $ oc delete -f deploy/role.yaml

   $ oc delete -f deploy/service_account.yaml

   $ oc delete -f deploy/crds/cache_v1alpha1_memcached_crd.yaml