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. 워크로드 → Pod 페이지의 openshift-operators 프로젝트(또는 특정 네임스페이스…​설치 모드가 선택된 경우 기타 관련 네임스페이스)에서 문제를 보고하는 모든 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. 워크로드 → Pod 페이지의 openshift-operators 프로젝트(또는 특정 네임스페이스…​설치 모드가 선택된 경우 기타 관련 네임스페이스)에서 문제를 보고하는 모든 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. 요구 사항에 따라 Pod를 대상으로 할 노드 또는 노드 집합을 결정합니다. 사용 가능한 경우 노드 또는 노드를 식별하는 node-role.kubernetes.io/app과 같은 기존 레이블을 확인합니다. 그렇지 않으면 머신 세트를 사용하거나 노드를 직접 편집하여 myoperator와 같은 레이블을 추가합니다. 이후 단계에서 이 레이블을 프로젝트의 노드 선택기로 사용합니다.
2. 특정 레이블이 있는 Pod만 노드에서 실행되도록 허용하지만 관련이 없는 워크로드를 다른 노드에 추가하려면 머신 세트를 사용하거나 노드를 직접 편집하여 노드 또는 노드에 테인트를 추가합니다. 테인트와 일치하지 않는 새 Pod를 노드에서 예약할 수 없도록 하는 효과를 사용합니다. 예를 들어 myoperator:NoSchedule 테인트를 사용하면 테인트와 일치하지 않는 새 Pod가 해당 노드에 예약되지 않지만 노드의 기존 Pod는 그대로 유지됩니다.
3. 기본 노드 선택기와 테인트를 추가한 경우 일치하는 허용 오차로 구성된 프로젝트를 만듭니다.

절차

1. 웹 콘솔의 Administrator 모드에서 Operator → Installed Operators로 이동합니다.
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 페이지로 이동합니다.
2. 제거하려는 Operator를 찾으려면 이름으로 필터링 필드에 키워드를 스크롤하거나 입력합니다. 그런 다음 해당 Operator를 클릭합니다.

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

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

4. 설치 제거를 선택하여 Operator, Operator 배포 및 Pod를 제거합니다. 이 작업 후에 Operator는 실행을 중지하고 더 이상 업데이트가 수신되지 않습니다.

   참고

   이 작업은 CRD(사용자 정의 리소스 정의) 및 CR(사용자 정의 리소스)을 포함하여 Operator에서 관리하는 리소스를 제거하지 않습니다. 웹 콘솔에서 활성화된 대시보드 및 탐색 항목과 계속 실행되는 클러스터 외부 리소스는 수동 정리가 필요할 수 있습니다. Operator를 설치 제거한 후 해당 항목을 제거하려면 Operator CRD를 수동으로 삭제해야 할 수 있습니다.

프로세스

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 볼륨 마운트를 생성합니다.

   참고

   Operator 배포는 기관을 검증하지 못하고 알 수 없는 기관 오류로 서명된 x509 인증서를 표시할 수 있습니다. 이 오류는 Operator 서브스크립션을 사용할 때 사용자 정의 CA를 삽입한 후에도 발생할 수 있습니다. 이 경우 Operator 서브스크립션을 사용하여 mountPath 를 trusted-ca의 /etc/ssl/certs 로 설정할 수 있습니다.

절차

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. Operator의 OperatorCondition 오브젝트를 편집합니다.

   $ oc edit operatorcondition <name>

2. 오브젝트에 Spec.Overrides 어레이를 추가합니다.

   Operator 조건 덮어쓰기 예제

   apiVersion: operators.coreos.com/v1
   kind: OperatorCondition
   metadata:
     name: my-operator
     namespace: operators
   spec:
     overrides:
     - type: Upgradeable 1
       status: "True"
       reason: "upgradeIsSafe"
       message: "This is a known issue with the Operator where it always reports that it cannot be upgraded."
     conditions:
     - type: Upgradeable
       status: "False"
       reason: "migration"
       message: "The operator is performing a migration."
       lastTransitionTime: "2020-08-24T23:15:55Z"

   1

   클러스터 관리자는 업그레이드 준비 상태를 True로 변경할 수 있습니다.

프로세스

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. 모든 기본 글로벌 카탈로그를 비활성화합니다.
2. 관련 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. 인덱스 이미지를 참조하는 CatalogSource 오브젝트를 생성합니다.

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

      apiVersion: operators.coreos.com/v1alpha1
      kind: CatalogSource
      metadata:
        name: my-operator-catalog
        namespace: openshift-marketplace 1
        annotations:
          olm.catalogImageTemplate: 2
            "<registry>/<namespace>/<index_image_name>:v{kube_major_version}.{kube_minor_version}.{kube_patch_version}"
      spec:
        sourceType: grpc
        image: <registry>/<namespace>/<index_image_name>:<tag> 3
        displayName: My Operator Catalog
        publisher: <publisher_name> 4
        updateStrategy:
          registryPoll: 5
            interval: 30m

      1

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

      2

      선택 사항: olm.catalogImageTemplate 주석을 인덱스 이미지 이름으로 설정하고 이미지 태그의 템플릿을 구성할 때 표시된 대로 하나 이상의 Kubernetes 클러스터 버전 변수를 사용합니다.

      3

      인덱스 이미지를 지정합니다. 이미지 이름(예: :v4.10 ) 뒤에 태그를 지정하면 카탈로그 소스 Pod는 Always 라는 이미지 가져오기 정책을 사용합니다. 즉, Pod는 컨테이너를 시작하기 전에 항상 이미지를 가져옵니다. 다이제스트(예: @sha256:<id >)를 지정하는 경우 이미지 가져오기 정책은 IfNotPresent 입니다. 즉, 노드에 아직 존재하지 않는 경우에만 Pod에서 이미지를 가져옵니다.

      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. 필요한 각 프라이빗 레지스트리에 대해 보안을 생성합니다.

   1. 프라이빗 레지스트리에 로그인하여 레지스트리 자격 증명 파일을 생성하거나 업데이트합니다.

      $ podman login <registry>:<port>

      참고

      레지스트리 자격 증명의 파일 경로는 레지스트리에 로그인하는 데 사용하는 컨테이너 툴에 따라 다를 수 있습니다. podman CLI의 경우 기본 위치는 ${XDG_RUNTIME_DIR}/containers/auth.json입니다. docker CLI의 경우 기본 위치는 /root/.docker/config.json입니다.

   2. 보안당 하나의 레지스트리에 대한 자격 증명만 포함하고 여러 레지스트리의 자격 증명은 별도의 보안에서 관리하는 것이 좋습니다. 이후 단계에서 CatalogSource 오브젝트에 여러 보안을 포함할 수 있으며 OpenShift Container Platform은 이미지를 가져오는 동안 사용할 수 있도록 보안을 단일 가상 자격 증명 파일에 병합합니다.

      기본적으로 레지스트리 자격 증명 파일은 둘 이상의 레지스트리 또는 하나의 레지스트리에 있는 여러 리포지토리의 세부 정보를 저장할 수 있습니다. 파일의 현재 콘텐츠를 확인합니다. 예를 들면 다음과 같습니다.

      여러 레지스트리에 대한 자격 증명을 저장하는 파일

      {
          "auths": {
              "registry.redhat.io": {
                  "auth": "FrNHNydQXdzclNqdg=="
              },
              "quay.io": {
                  "auth": "fegdsRib21iMQ=="
              },
              "https://quay.io/my-namespace/my-user/my-image": {
                  "auth": "eWfjwsDdfsa221=="
              },
              "https://quay.io/my-namespace/my-user": {
                  "auth": "feFweDdscw34rR=="
              },
              "https://quay.io/my-namespace": {
                  "auth": "frwEews4fescyq=="
              }
          }
      }

      이 파일은 이후 단계에서 보안을 생성하는 데 사용되므로 파일마다 하나의 레지스트리에만 세부 정보를 저장해야 합니다. 이 작업은 다음 방법 중 하나를 사용하여 수행할 수 있습니다.

      • podman logout <registry> 명령을 사용하여 원하는 레지스트리 하나만 남을 때까지 추가 레지스트리의 자격 증명을 제거합니다.

      • 레지스트리 자격 증명 파일을 편집하고 레지스트리 세부 정보를 분리하여 여러 파일에 저장합니다. 예를 들면 다음과 같습니다.

        하나의 레지스트리에 대한 자격 증명을 저장하는 파일

        {
                "auths": {
                        "registry.redhat.io": {
                                "auth": "FrNHNydQXdzclNqdg=="
                        }
                }
        }

        또 다른 레지스트리에 대한 자격 증명을 저장하는 파일

        {
                "auths": {
                        "quay.io": {
                                "auth": "Xd2lhdsbnRib21iMQ=="
                        }
                }
        }

   3. 프라이빗 레지스트리의 인증 자격 증명 정보가 포함된 openshift-marketplace 네임스페이스에 보안을 생성합니다.

      $ oc create secret generic <secret_name> \
          -n openshift-marketplace \
          --from-file=.dockerconfigjson=<path/to/registry/credentials> \
          --type=kubernetes.io/dockerconfigjson

      이 단계를 반복하여 다른 필수 프라이빗 레지스트리에 대한 추가 보안을 생성하고 --from-file 플래그를 업데이트하여 다른 레지스트리 자격 증명 파일 경로를 지정합니다.

2. 기존 CatalogSource 오브젝트를 생성하거나 업데이트하여 하나 이상의 보안을 참조합니다.

   apiVersion: operators.coreos.com/v1alpha1
   kind: CatalogSource
   metadata:
     name: my-operator-catalog
     namespace: openshift-marketplace
   spec:
     sourceType: grpc
     secrets: 1
     - "<secret_name_1>"
     - "<secret_name_2>"
     image: <registry>:<port>/<namespace>/<image>:<tag>
     displayName: My Operator Catalog
     publisher: <publisher_name>
     updateStrategy:
       registryPoll:
         interval: 30m

   1

   spec.secrets 섹션을 추가하고 필요한 보안을 지정합니다.

3. 구독한 Operator에서 참조하는 Operator 또는 Operand 이미지에 프라이빗 레지스트리에 대한 액세스 권한이 필요한 경우 클러스터의 모든 네임스페이스 또는 개별 대상 테넌트 네임스페이스에 액세스 권한을 제공하면 됩니다.

   • 클러스터의 모든 네임스페이스에 액세스 권한을 제공하려면 openshift-config 네임스페이스의 글로벌 클러스터 가져오기 보안에 인증 세부 정보를 추가합니다.

     주의

     클러스터 리소스는 클러스터의 사용성을 일시적으로 제한할 수 있는 새 글로벌 가져오기 보안에 맞게 조정해야 합니다.

     1. 글로벌 가져오기 보안에서 .dockerconfigjson 파일을 추출합니다.

        $ oc extract secret/pull-secret -n openshift-config --confirm

     2. 필요한 프라이빗 레지스트리 또는 레지스트리에 대한 인증 자격 증명을 사용하여 .dockerconfigjson 파일을 업데이트한 후 새 파일로 저장합니다.

        $ cat .dockerconfigjson | \
            jq --compact-output '.auths["<registry>:<port>/<namespace>/"] |= . + {"auth":"<token>"}' \1
            > new_dockerconfigjson

        1

        <registry>:<port>/<namespace>를 프라이빗 레지스트리 세부 정보로 교체하고 <token>을 인증 자격 증명으로 교체합니다.

     3. 새 파일을 사용하여 글로벌 가져오기 보안을 업데이트합니다.

        $ oc set data secret/pull-secret -n openshift-config \
            --from-file=.dockerconfigjson=new_dockerconfigjson

   • 개별 네임스페이스를 업데이트하려면 대상 테넌트 네임스페이스에 액세스해야 하는 Operator의 서비스 계정에 가져오기 보안을 추가합니다.

     1. 테넌트 네임스페이스에서 openshift-marketplace용으로 생성한 보안을 다시 생성합니다.

        $ oc create secret generic <secret_name> \
            -n <tenant_namespace> \
            --from-file=.dockerconfigjson=<path/to/registry/credentials> \
            --type=kubernetes.io/dockerconfigjson

     2. 테넌트 네임스페이스를 검색하여 Operator의 서비스 계정 이름을 확인합니다.

        $ oc get sa -n <tenant_namespace> 1

        1

        Operator가 개별 네임스페이스에 설치된 경우 해당 네임스페이스를 검색합니다. Operator가 모든 네임스페이스에 설치된 경우 openshift-operators 네임스페이스를 검색합니다.

        출력 예

        NAME            SECRETS   AGE
        builder         2         6m1s
        default         2         6m1s
        deployer        2         6m1s
        etcd-operator   2         5m18s 1

        1

        설치된 etcd Operator의 서비스 계정입니다.

     3. Operator의 서비스 계정에 보안을 연결합니다.

        $ oc secrets link <operator_sa> \
            -n <tenant_namespace> \
             <secret_name> \
            --for=pull

절차

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.10

      출력 예

      Trying to pull registry.redhat.io/redhat/redhat-operator-index:v4.10...
      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.10 \1
       -p advanced-cluster-management,jaeger-product,quay-operator \2
       [-i registry.redhat.io/openshift4/ose-operator-registry:v4.9] \3
       -t <target_registry>:<port>/<namespace>/redhat-operator-index:v4.10 4

   1

   정리할 인덱스입니다.

   2

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

   3

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

   4

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

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

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

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

프로세스

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>/<namespace>/redhat-operator-index:v4.10 3
        displayName: My Operator Catalog
        publisher: <publisher_name> 4
        updateStrategy:
          registryPoll: 5
            interval: 30m

      1

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

      2

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

      3

      인덱스 이미지를 지정합니다. 이미지 이름(예: :v4.10 ) 뒤에 태그를 지정하면 카탈로그 소스 Pod는 Always 라는 이미지 가져오기 정책을 사용합니다. 즉, Pod는 컨테이너를 시작하기 전에 항상 이미지를 가져옵니다. 다이제스트(예: @sha256:<id >)를 지정하는 경우 이미지 가져오기 정책은 IfNotPresent 입니다. 즉, 노드에 아직 존재하지 않는 경우에만 Pod에서 이미지를 가져옵니다.

      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>

   c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 과 같은 번들 이미지의 SHA 이미지 ID 또는 다이제스트를 지정합니다.

   <existing_index_image>

   bc -redhat-operator-index와 같이 이전에 내보낸 이미지를 지정합니다.

   <existing_tag>

   이전에 내보낸 이미지 태그(예: 4.10) 를 지정합니다.

   <updated_tag>

   업데이트된 인덱스 이미지에 적용할 이미지 태그를 지정합니다(예: 4.10.1 ).

   명령 예

   $ opm index add \
       --bundles quay.io/ocs-dev/ocs-operator@sha256:c7f11097a628f092d8bad148406aa0e0951094a03445fd4bc0775431ef683a41 \
       --from-index mirror.example.com/abc/abc-redhat-operator-index:4.10 \
       --tag mirror.example.com/abc/abc-redhat-operator-index:4.10.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. OpenShift 미러 사이트로 이동합니다.
2. 최신 4.10 디렉터리에서 최신 버전의 Linux용 tarball을 다운로드합니다.

3. 아카이브의 압축을 풉니다.

   $ tar xvf operator-sdk-v1.16.0-ocp-linux-x86_64.tar.gz

4. 파일을 실행 가능으로 설정합니다.

   $ chmod +x operator-sdk

5. 추출된 operator-sdk 바이너리를 PATH에 있는 디렉터리로 이동합니다.

   작은 정보

   PATH를 확인하려면 다음을 실행합니다.

   $ echo $PATH

   $ sudo mv ./operator-sdk /usr/local/bin/operator-sdk

프로세스

1. config/default/manager_auth_proxy_patch.yaml 및 config/rbac/auth_proxy_service.yaml 파일에 protocol 필드를 추가합니다.

   ...
    ports:
    - containerPort: 8443
   +  protocol: TCP
      name: https

2. config/manager/manager.yaml 파일을 다음과 같이 변경합니다.

   1. CPU 및 메모리 리소스 제한을 늘립니다.

      resources:
        limits:
      -     cpu: 100m
      -     memory: 30Mi
      +     cpu: 200m
      +     memory: 100Mi

   2. 주석을 추가하여 기본 컨테이너 관리자를 지정합니다.

      ...
      template:
        metadata:
          annotations:
            kubectl.kubernetes.io/default-container: manager
      ...

3. Makefile 파일에 있는 모든 타겟에 tekton ONY 대상을 추가합니다.

4. Go 기반 Operator 프로젝트의 경우 다음과 같이 변경합니다.

   1. setup-envtest 바이너리를 설치합니다.

   2. go.mod 파일을 변경하여 종속성을 업데이트합니다.

      k8s.io/api v0.22.1
      k8s.io/apimachinery v0.22.1
      k8s.io/client-go v0.22.1
      sigs.k8s.io/controller-runtime v0.10.0

   3. go mod tidy 명령을 실행하여 종속성을 다운로드합니다.

      $ go mod tidy

   4. Makefile 파일을 다음과 같이 변경합니다.

      ...
      
      + ENVTEST_K8S_VERSION = 1.22
      
        test: manifests generate fmt vet envtest ## Run tests.
      -   go test ./... -coverprofile cover.out
      +   KUBEBUILDER_ASSETS="$(shell $(ENVTEST) use $(ENVTEST_K8S_VERSION) -p path)" go test ./... -coverprofile cover.out
      ...
      
      - $(CONTROLLER_GEN) $(CRD_OPTIONS) rbac:roleName=manager-role webhook paths="./..." output:crd:artifacts:config=config/crd/bases
      + $(CONTROLLER_GEN) rbac:roleName=manager-role crd webhook paths="./..." output:crd:artifacts:config=config/crd/bases
      ...
      
      # Produce CRDs that work back to Kubernetes 1.11 (no version conversion)
      - CRD_OPTIONS ?= "crd:trivialVersions=true,preserveUnknownFields=false"
      ...
      - admissionReviewVersions={v1,v1beta1}
      + admissionReviewVersions=v1
      ...
      
      + ifndef ignore-not-found
      +   ignore-not-found = false
      + endif
      
      ##@ Deployment
      ...
      - sh kubectl delete -f -
      + sh kubectl delete --ignore-not-found=$(ignore-not-found) -f -

   5. make manifest 명령을 실행하여 업데이트된 Kubernetes 버전으로 매니페스트를 생성합니다.

      $ make manifest

5. Ansible 기반 Operator 프로젝트의 경우 다음과 같이 변경합니다.

   1. 다음을 포함하도록 requirements.yml 파일을 변경합니다.

      1. community.kubernetes 컬렉션을 kubernetes.core 컬렉션으로 교체합니다.

         ...
         - name: kubernetes.core
           version: "2.2.0"
         ...

      2. operator_sdk.util 유틸리티를 0.2.0 에서 0.3.1 로 업데이트합니다.

         ...
         - name: operator_sdk.util
           version: "0.3.1"

   2. config/manager/manager.yaml 파일에서 기본 리소스 제한을 확인합니다.

      ...
       # TODO(user): Configure the resources accordingly based on the project requirements.
       # More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
      
      resources:
        limits:
          cpu: 500m
          memory: 768Mi
        requests:
          cpu: 10m
          memory: 256Mi

      중요

      Operator SDK는 이러한 값을 적절한 기본 설정으로 스캐폴드합니다. Operator 작성자는 프로젝트의 요구 사항에 따라 리소스 제한을 설정하고 최적화해야 합니다.

   3. 선택 사항: make run 명령을 사용하여 Ansible 기반 Operator를 로컬에서 실행하려는 경우 다음과 같이 변경합니다.

      1. Makefile 파일에서 run 대상을 변경합니다.

         ANSIBLE_ROLES_PATH="$(ANSIBLE_ROLES_PATH):$(shell pwd)/roles" $(ANSIBLE_OPERATOR) run

      2. ansible-runner 의 로컬 버전을 2.0.2 이상으로 업데이트합니다.

         중요

         버전 2.0에서 ansible-runner 툴에는 이전 버전과 호환되지 않는 명령 서명의 변경 사항이 포함되어 있습니다.