手順

1. oc create -f <file-name>.yaml コマンドで、メータリング Operator の namespace オブジェクト YAML ファイルを作成します。CLI を使用して namespace を作成する必要があります。たとえば、metering-namespace.yaml のようになります。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-metering 1
     annotations:
       openshift.io/node-selector: "" 2
     labels:
       openshift.io/cluster-monitoring: "true"

   1

   メータリングを openshift-metering namespace にデプロイすることを強く推奨します。

   2

   オペランド Pod の特定のノードセレクターを設定する前に、このアノテーションを追加します。

2. OpenShift Container Platform Web コンソールで、Operators → OperatorHub をクリックします。metering のフィルターで、メータリング Operator を検索します。
3. Metering カードをクリックして、パッケージの説明を確認してから Install をクリックします。
4. Update Channel、Installation Mode、および Approval Strategy を選択します。
5. Install をクリックします。

6. Operators → Installed Operators ページに切り替えて、メータリング Operator がインストールされていることを確認します。メータリング Operator では、インストールの完了時に Status が Succeeded になります。

   注記

   メータリング Operator が表示されるまでに数分の時間がかかる場合があります。

7. Installed Operators ページで Metering をクリックし、Operator Details を確認します。Details ページから、メータリングに関連する異なるリソースを作成できます。

手順

1. メータリング Operator の Namespace オブジェクト YAML ファイルを作成します。CLI を使用して namespace を作成する必要があります。たとえば、metering-namespace.yaml のようになります。

   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-metering 1
     annotations:
       openshift.io/node-selector: "" 2
     labels:
       openshift.io/cluster-monitoring: "true"

   1

   メータリングを openshift-metering namespace にデプロイすることを強く推奨します。

   2

   オペランド Pod の特定のノードセレクターを設定する前に、このアノテーションを追加します。

2. Namespace オブジェクトを作成します。

   $ oc create -f <file-name>.yaml

   以下は例になります。

   $ oc create -f openshift-metering.yaml

3. OperatorGroup オブジェクト YAML ファイルを作成します。たとえば、metering-og のようになります。

   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: openshift-metering 1
     namespace: openshift-metering 2
   spec:
     targetNamespaces:
     - openshift-metering

   1

   名前は任意です。

   2

   openshift-metering namespace を指定します。

4. Subscription オブジェクトの YAML ファイルを作成し、namespace をメータリング Operator にサブスクライブします。このオブジェクトは、redhat-operators カタログソースの最近リリースされたバージョンをターゲットにします。たとえば、metering-sub.yaml のようになります。

   apiVersion: operators.coreos.com/v1alpha1
   kind: Subscription
   metadata:
     name: metering-ocp 1
     namespace: openshift-metering 2
   spec:
     channel: "4.6" 3
     source: "redhat-operators" 4
     sourceNamespace: "openshift-marketplace"
     name: "metering-ocp"
     installPlanApproval: "Automatic" 5

   1

   名前は任意です。

   2

   openshift-logging namespace を指定する必要があります。

   3

   4.6 をチャネルとして指定します。

   4

   metering-ocp パッケージマニフェストが含まれる、redhat-operators カタログソースを指定します。OpenShift Container Platform が、非接続クラスターとも呼ばれる制限されたネットワークにインストールされている場合、Operator LifeCycle Manager (OLM) の設定時に作成した CatalogSource オブジェクトの名前を指定します。

   5

   自動インストール計画の承認を指定します。

手順

1. s3-storage.yaml ファイルの spec.storage セクションを編集します。

   例: s3-storage.yaml ファイル

   apiVersion: metering.openshift.io/v1
   kind: MeteringConfig
   metadata:
     name: "operator-metering"
   spec:
     storage:
       type: "hive"
       hive:
         type: "s3"
         s3:
           bucket: "bucketname/path/" 1
           region: "us-west-1" 2
           secretName: "my-aws-secret" 3
           # Set to false if you want to provide an existing bucket, instead of
           # having metering create the bucket on your behalf.
           createBucket: true 4

   1

   データを格納するバケットの名前を指定します。オプション: バケット内でパスを指定します。

   2

   バケットのリージョンを指定します。

   3

   data.aws-access-key-id および data.aws-secret-access-key フィールドに AWS 認証情報を含むメータリング namespace のシークレットの名前。詳細は、以下の Secret オブジェクトのサンプルを参照してください。

   4

   既存の S3 バケットを指定する必要がある場合や、CreateBucket パーミッションを持つ IAM 認証情報を指定する必要がない場合は、このフィールドを false に設定します。

2. 以下の Secret オブジェクトをテンプレートとして使用します。

   AWS Secret オブジェクトの例

   apiVersion: v1
   kind: Secret
   metadata:
     name: my-aws-secret
   data:
     aws-access-key-id: "dGVzdAo="
     aws-secret-access-key: "c2VjcmV0Cg=="

   注記

   aws-access-key-id および aws-secret-access-key の値は base64 でエンコードされる必要があります。

3. シークレットを作成します。

   $ oc create secret -n openshift-metering generic my-aws-secret \
     --from-literal=aws-access-key-id=my-access-key \
     --from-literal=aws-secret-access-key=my-secret-key

   注記

   このコマンドは、aws-access-key-id と aws-secret-access-key の値を自動的に base64 でエンコードします。

手順

1. s3-compatible-storage.yaml ファイルで spec.storage セクションを編集します。

   例: s3-compatible-storage.yaml ファイル

   apiVersion: metering.openshift.io/v1
   kind: MeteringConfig
   metadata:
     name: "operator-metering"
   spec:
     storage:
       type: "hive"
       hive:
         type: "s3Compatible"
         s3Compatible:
           bucket: "bucketname" 1
           endpoint: "http://example:port-number" 2
           secretName: "my-aws-secret" 3

   1

   S3 互換バケットの名前を指定します。

   2

   ストレージのエンドポイントを指定します。

   3

   data.aws-access-key-id および data.aws-secret-access-key フィールドに AWS 認証情報を含むメータリング namespace のシークレットの名前。詳細は、以下の Secret オブジェクトのサンプルを参照してください。

2. 以下の Secret オブジェクトをテンプレートとして使用します。

   S3 と互換性のある Secret オブジェクトの例

   apiVersion: v1
   kind: Secret
   metadata:
     name: my-aws-secret
   data:
     aws-access-key-id: "dGVzdAo="
     aws-secret-access-key: "c2VjcmV0Cg=="

手順

1. azure-blob-storage.yaml ファイルで spec.storage セクションを編集します。

   azure-blob-storage.yaml ファイルの例

   apiVersion: metering.openshift.io/v1
   kind: MeteringConfig
   metadata:
     name: "operator-metering"
   spec:
     storage:
       type: "hive"
       hive:
         type: "azure"
         azure:
           container: "bucket1" 1
           secretName: "my-azure-secret" 2
           rootDirectory: "/testDir" 3

   1

   コンテナー名を指定します。

   2

   シークレットをメータリング namespace に指定します。詳細は、以下の Secret オブジェクトのサンプルを参照してください。

   3

   オプション: データを格納するディレクトリーを指定します。

2. 以下の Secret オブジェクトをテンプレートとして使用します。

   Azure Secret オブジェクトの例

   apiVersion: v1
   kind: Secret
   metadata:
     name: my-azure-secret
   data:
     azure-storage-account-name: "dGVzdAo="
     azure-secret-access-key: "c2VjcmV0Cg=="

3. シークレットを作成します。

   $ oc create secret -n openshift-metering generic my-azure-secret \
     --from-literal=azure-storage-account-name=my-storage-account-name \
     --from-literal=azure-secret-access-key=my-secret-key

手順

1. gcs-storage.yaml ファイルで spec.storage セクションを編集します。

   gcs-storage.yaml ファイルの例

   apiVersion: metering.openshift.io/v1
   kind: MeteringConfig
   metadata:
     name: "operator-metering"
   spec:
     storage:
       type: "hive"
       hive:
         type: "gcs"
         gcs:
           bucket: "metering-gcs/test1" 1
           secretName: "my-gcs-secret" 2

   1

   バケットの名前を指定します。オプションで、データを保存するバケット内でディレクトリーを指定することができます。

   2

   シークレットをメータリング namespace に指定します。詳細は、以下の Secret オブジェクトのサンプルを参照してください。

2. 以下の Secret オブジェクトをテンプレートとして使用します。

   Google Cloud Storage Secret オブジェクトの例

   apiVersion: v1
   kind: Secret
   metadata:
     name: my-gcs-secret
   data:
     gcs-service-account.json: "c2VjcmV0Cg=="

3. シークレットを作成します。

   $ oc create secret -n openshift-metering generic my-gcs-secret \
     --from-file gcs-service-account.json=/path/to/my/service-account-key.json

手順

1. ストレージに ReadWriteMany 永続ボリュームを使用するには、shared-storage.yaml ファイルを変更します。

   shared-storage.yaml ファイルの例

   apiVersion: metering.openshift.io/v1
   kind: MeteringConfig
   metadata:
     name: "operator-metering"
   spec:
     storage:
       type: "hive"
       hive:
         type: "sharedPVC"
         sharedPVC:
           claimName: "metering-nfs" 1
           # Uncomment the lines below to provision a new PVC using the specified storageClass. 2
           # createPVC: true
           # storageClass: "my-nfs-storage-class"
           # size: 5Gi

   以下のいずれかの設定オプションを選択します。

   1

   storage.hive.sharedPVC.claimName を既存の ReadWriteMany 永続ボリューム要求 (PVC) の名前に設定します。この設定は、動的ボリュームプロビジョニングがない場合や、永続ボリュームの作成方法をより詳細に制御する必要がある場合に必要です。

   2

   storage.hive.sharedPVC.createPVC を true に設定し、storage.hive.sharedPVC.storageClass を ReadWriteMany アクセスモードのストレージクラスの名前に設定します。この設定は、動的ボリュームプロビジョニングを使用して、ボリュームを自動的に作成します。

2. メータリング用に NFS サーバーをデプロイするために必要な以下のリソースオブジェクトを作成します。oc create -f <file-name>.yaml コマンドを使用してオブジェクト YAML ファイルを作成します。

   1. PersistentVolume リソースオブジェクトを設定します。

      nfs_persistentvolume.yaml ファイルの例

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: nfs
        labels:
          role: nfs-server
      spec:
        capacity:
          storage: 5Gi
        accessModes:
        - ReadWriteMany
        storageClassName: nfs-server 1
        nfs:
          path: "/"
          server: REPLACEME
        persistentVolumeReclaimPolicy: Delete

      1

      [kind: StorageClass].metadata.name フィールドの値に一致する必要があります。

   2. Pod リソースオブジェクトを nfs-server ロールで設定します。

      nfs_server.yaml ファイルの例

      apiVersion: v1
      kind: Pod
      metadata:
        name: nfs-server
        labels:
          role: nfs-server
      spec:
        containers:
          - name: nfs-server
            image: <image_name> 1
            imagePullPolicy: IfNotPresent
            ports:
              - name: nfs
                containerPort: 2049
            securityContext:
              privileged: true
            volumeMounts:
            - mountPath: "/mnt/data"
              name: local
        volumes:
          - name: local
            emptyDir: {}

      1

      NFS サーバーイメージをインストールします。

   3. Service リソースオブジェクトを nfs-server ロールで設定します。

      nfs_service.yaml ファイルの例:

      apiVersion: v1
      kind: Service
      metadata:
        name: nfs-service
        labels:
          role: nfs-server
      spec:
        ports:
        - name: 2049-tcp
          port: 2049
          protocol: TCP
          targetPort: 2049
        selector:
          role: nfs-server
        sessionAffinity: None
        type: ClusterIP

   4. StorageClass リソースオブジェクトを設定します。

      nfs_storageclass.yaml ファイルの例

      apiVersion: storage.k8s.io/v1
      kind: StorageClass
      metadata:
        name: nfs-server 1
      provisioner: example.com/nfs
      parameters:
        archiveOnDelete: "false"
      reclaimPolicy: Delete
      volumeBindingMode: Immediate

      1

      [kind: PersistentVolume].spec.storageClassName フィールドの値に一致する必要があります。

手順

1. 完了しなかったメータリング Report リソースの有無を確認し、ReportingPeriodUnmetDependencies のステータスを表示します。

   $ oc get reports

   出力例

   NAME                                  QUERY                          SCHEDULE   RUNNING                            FAILED   LAST REPORT TIME       AGE
   namespace-cpu-utilization-adhoc-10    namespace-cpu-utilization                 Finished                                    2020-10-31T00:00:00Z   2m38s
   namespace-cpu-utilization-adhoc-11    namespace-cpu-utilization                 ReportingPeriodUnmetDependencies                                   2m23s
   namespace-memory-utilization-202010   namespace-memory-utilization              ReportingPeriodUnmetDependencies                                   26s
   namespace-memory-utilization-202011   namespace-memory-utilization              ReportingPeriodUnmetDependencies                                   14s

2. NEWEST METRIC の値がレポートの終了日よりも小さい ReportDataSource リソースを確認します。

   $ oc get reportdatasource

   出力例

   NAME                                         EARLIEST METRIC        NEWEST METRIC          IMPORT START           IMPORT END             LAST IMPORT TIME       AGE
   ...
   node-allocatable-cpu-cores                   2020-04-23T09:14:00Z   2020-08-31T10:07:00Z   2020-04-23T09:14:00Z   2020-10-15T17:13:00Z   2020-12-09T12:45:10Z   230d
   node-allocatable-memory-bytes                2020-04-23T09:14:00Z   2020-08-30T05:19:00Z   2020-04-23T09:14:00Z   2020-10-14T08:01:00Z   2020-12-09T12:45:12Z   230d
   ...
   pod-usage-memory-bytes                       2020-04-23T09:14:00Z   2020-08-24T20:25:00Z   2020-04-23T09:14:00Z   2020-10-09T23:31:00Z   2020-12-09T12:45:12Z   230d

3. 多数の Pod の再起動のについて、reporting-operator Pod リソースの正常性を確認します。

   $ oc get pods -l app=reporting-operator

   出力例

   NAME                                  READY   STATUS    RESTARTS   AGE
   reporting-operator-84f7c9b7b6-fr697   2/2     Running   542        8d 1

   1

   レポート Operator Pod は高い率で再起動します。

4. reporting-operator Pod リソースで OOMKilled の終了について確認します。

   $ oc describe pod/reporting-operator-84f7c9b7b6-fr697

   出力例

   Name:         reporting-operator-84f7c9b7b6-fr697
   Namespace:    openshift-metering
   Priority:     0
   Node:         ip-10-xx-xx-xx.ap-southeast-1.compute.internal/10.xx.xx.xx
   ...
      Ports:          8080/TCP, 6060/TCP, 8082/TCP
      Host Ports:     0/TCP, 0/TCP, 0/TCP
      State:          Running
        Started:      Thu, 03 Dec 2020 20:59:45 +1000
      Last State:     Terminated
        Reason:       OOMKilled 1
        Exit Code:    137
        Started:      Thu, 03 Dec 2020 20:38:05 +1000
        Finished:     Thu, 03 Dec 2020 20:59:43 +1000

   1

   レポート Operator Pod は OOM による強制終了により終了しています。

手順

1. reporting-operator Pod リソースの現在のメモリー制限を確認します。

   $ oc describe pod reporting-operator-67d6f57c56-79mrt

   出力例

   Name:         reporting-operator-67d6f57c56-79mrt
   Namespace:    openshift-metering
   Priority:     0
   ...
      Ports:          8080/TCP, 6060/TCP, 8082/TCP
      Host Ports:     0/TCP, 0/TCP, 0/TCP
      State:          Running
        Started:      Tue, 08 Dec 2020 14:26:21 +1000
      Ready:          True
      Restart Count:  0
      Limits:
        cpu:     1
        memory:  500Mi 1
      Requests:
        cpu:     500m
        memory:  250Mi
      Environment:
   ...

   1

   レポート Operator Pod の現在のメモリー制限。

2. MeteringConfig リソースを編集してメモリー制限を更新します。

   $ oc edit meteringconfig/operator-metering

   MeteringConfig リソース例

   kind: MeteringConfig
   metadata:
     name: operator-metering
     namespace: openshift-metering
   spec:
     reporting-operator:
     spec:
       resources: 1
         limits:
           cpu: 1
           memory: 750Mi
         requests:
           cpu: 500m
           memory: 500Mi
   ...

   1

   MeteringConfig リソースの resources フィールド内でメモリー制限を追加または引き上げます。

   注記

   メモリー制限が引き上げられた後でも引き続き OOM で強制終了された多数のイベントがある場合は、別の問題がレポートを保留状態にしていることを示唆している可能性があります。