3.4. ロギングデプロイメントの管理

1. Red Hat OpenShift Logging Operator をインストールします。

   1. OpenShift Container Platform Web コンソールで、Operators OperatorHub をクリックします。
   2. Filter by keyword フィールドに Logging と入力します。
   3. 利用可能な Operator のリストから Red Hat OpenShift Logging を選択し、Install をクリックします。

   4. Update Channel として stable または stable-5.y を選択します。

      注記

      stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

   5. Installation Mode で A specific namespace on the cluster が選択されていることを確認します。
   6. Operator recommended namespace が Installed Namespace で openshift-logging になっていることを確認します。
   7. Enable Operator recommended cluster monitoring on this Namespace を選択します。

   8. Update approval のオプションを選択します。

      • Automatic オプションを使用すると、Operator Lifecycle Manager (OLM) は、新しいバージョンが利用可能になった際、Operator を自動的に更新できます。
      • Manual オプションでは、適切な認証情報を持つユーザーが Operator の更新を承認する必要があります。
   9. Console プラグインの Enable または Disable を選択します。
   10. Install をクリックします。

2. Operators Installed Operators ページに切り替えて、Red Hat OpenShift Logging Operator がインストールされていることを確認します。

   1. Red Hat OpenShift Logging が Status が Succeeded の状態で openshift-logging プロジェクトにリスト表示されていることを確認します。

3. ClusterLogging インスタンスを作成します。

   注記

   Web コンソールのフォームビューには、使用可能なすべてのオプションが含まれているわけではありません。セットアップを完了するには、YAML ビュー を推奨します。

   1. collection セクションで、コレクターの実装を選択します。

      注記

      Logging バージョン 5.6 の時点で、Fluentd は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Fluentd の代わりに、Vector を使用できます。

   2. logStore セクションで、タイプを選択します。

      注記

      Logging バージョン 5.4.3 の時点で、Elasticsearch Operator は非推奨であり、今後のリリースで削除される予定です。Red Hat は、この機能に対して現在のリリースライフサイクル中にバグ修正とサポートを提供しますが、拡張機能の提供はなく、この機能は今後削除される予定です。Elasticsearch Operator を使用してデフォルトのログストレージを管理する代わりに、Loki Operator を使用できます。

   3. Create をクリックします。

1. OpenShift Container Platform Web コンソールで、Operators OperatorHub をクリックします。

2. Filter by keyword フィールドに Loki と入力します。

   1. 使用可能な Operator のリストから Loki Operator を選択し、Install をクリックします。

3. Update Channel として stable または stable-5.y を選択します。

   注記

   stable チャネルは、Logging の最新リリースを対象とする更新のみを提供します。以前のリリースの更新を引き続き受信するには、サブスクリプションチャネルを stable-X (X はインストールしたログのバージョン) に変更する必要があります。

4. Installation Mode で All namespaces on the cluster が選択されていることを確認します。
5. openshift-operators-redhat が Installed Namespace で選択されていることを確認します。

6. Enable Operator recommended cluster monitoring on this Namespace を選択します。

   このオプションは、namespace オブジェクトに openshift.io/cluster-monitoring: "true" ラベルを設定します。クラスターモニタリングが openshift-operators-redhat namespace を収集できるように、このオプションを選択する必要があります。

7. Update approval のオプションを選択します。

   • Automatic オプションを使用すると、Operator Lifecycle Manager (OLM) は、新しいバージョンが利用可能になった際、Operator を自動的に更新できます。
   • Manual オプションでは、適切な認証情報を持つユーザーが Operator の更新を承認する必要があります。
8. Install をクリックします。

9. Operators Installed Operators ページに切り替えて、LokiOperator がインストールされていることを確認します。

   1. LokiOperator の全プロジェクトの Status が Succeeded として表示されているようにします。

10. access_key_id および access_key_secret フィールドを使用して、認証情報を指定し、bucketnames、endpoint、および region を指定して、オブジェクトストレージの場所を定義する Secret YAML ファイルを作成します。次の例では、AWS が使用されています。

    apiVersion: v1
    kind: Secret
    metadata:
      name: logging-loki-s3
      namespace: openshift-logging
    stringData:
      access_key_id: AKIAIOSFODNN7EXAMPLE
      access_key_secret: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
      bucketnames: s3-bucket-name
      endpoint: https://s3.eu-central-1.amazonaws.com
      region: eu-central-1

11. Details タブの LokiStack の下にある Create instance を選択します。次に、YAML view を選択します。次のテンプレートに貼り付け、必要に応じて値を置き換えます。

      apiVersion: loki.grafana.com/v1
      kind: LokiStack
      metadata:
        name: logging-loki 1
        namespace: openshift-logging
      spec:
        size: 1x.small 2
        storage:
          schemas:
          - version: v12
            effectiveDate: '2022-06-01'
          secret:
            name: logging-loki-s3 3
            type: s3 4
        storageClassName: <storage_class_name> 5
        tenants:
          mode: openshift-logging

    1

    名前は、logging-loki にする必要があります。

    2

    Loki のデプロイメントサイズを選択します。

    3

    ログストレージに使用するシークレットを定義します。

    4

    対応するストレージタイプを定義します。

    5

    一時ストレージ用の既存のストレージクラスの名前を入力します。最適なパフォーマンスを得るには、ブロックストレージを割り当てるストレージクラスを指定します。クラスターで使用可能なストレージクラスは、oc get storageclasses で一覧表示できます。

    1. 設定を適用します。

       oc apply -f logging-loki.yaml

12. ClusterLogging CR を作成または編集します。

      apiVersion: logging.openshift.io/v1
      kind: ClusterLogging
      metadata:
        name: instance
        namespace: openshift-logging
      spec:
        managementState: Managed
        logStore:
          type: lokistack
          lokistack:
            name: logging-loki
          collection:
            type: vector

    1. 設定を適用します。

       oc apply -f cr-lokistack.yaml

手順

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 グループは、Operator グループと同じ namespace 内のすべての Operator に必要な RBAC アクセスを生成するターゲット namespace を選択します。

   Operator をサブスクライブする namespace には、Operator のインストールモードに一致する Operator グループが必要になります (AllNamespaces または SingleNamespace モードのいずれか)。インストールする Operator が AllNamespaces を使用する場合、 openshift-operators namespace には適切な Operator グループがすでに配置されます。

   ただし、Operator が SingleNamespace モードを使用し、適切な Operator グループがない場合、それらを作成する必要があります。

   注記

   この手順の Web コンソールバージョンでは、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 ファイルを作成し、namespace を 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 namespace を指定します。それ以外の場合は、SingleNamespace インストールモードの使用について関連する単一の namespace を指定します。

   2

   サブスクライブするチャネルの名前。

   3

   サブスクライブする Operator の名前。

   4

   Operator を提供するカタログソースの名前。

   5

   カタログソースの namespace。デフォルトの OperatorHub カタログソースには openshift-marketplace を使用します。

   6

   env パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要がある環境変数の一覧を定義します。

   7

   envFrom パラメーターは、コンテナーの環境変数に反映するためのソースの一覧を定義します。

   8

   volumes パラメーターは、OLM によって作成される Pod に存在する必要があるボリュームの一覧を定義します。

   9

   volumeMounts パラメーターは、OLM によって作成される Pod のすべてのコンテナーに存在する必要があるボリュームマウントの一覧を定義します。volumeMount が存在しない ボリューム を参照する場合、OLM は Operator のデプロイに失敗します。

   10

   tolerations パラメーターは、OLM によって作成される Pod の容認の一覧を定義します。

   11

   resources パラメーターは、OLM によって作成される Pod のすべてのコンテナーのリソース制約を定義します。

   12

   nodeSelector パラメーターは、OLM によって作成される Pod の ノードセレクター を定義します。

5. Subscription オブジェクトを作成します。

   $ oc apply -f sub.yaml

   この時点で、OLM は選択した Operator を認識します。Operator のクラスターサービスバージョン (CSV) はターゲット namespace に表示され、Operator で指定される API は作成用に利用可能になります。

手順

1. Operators Installed Operators ページに移動します。
2. スクロールするか、キーワードを Filter by name フィールドに入力して、削除する Operator を見つけます。次に、それをクリックします。

3. Operator Details ページの右側で、Actions 一覧から Uninstall Operator を選択します。

   Uninstall Operator? ダイアログボックスが表示されます。

4. Uninstall を選択し、Operator、Operator デプロイメント、および Pod を削除します。このアクションの後には、Operator は実行を停止し、更新を受信しなくなります。

   注記

   このアクションは、カスタムリソース定義 (CRD) およびカスタムリソース (CR) など、Operator が管理するリソースは削除されません。Web コンソールおよび継続して実行されるクラスター外のリソースによって有効にされるダッシュボードおよびナビゲーションアイテムには、手動でのクリーンアップが必要になる場合があります。Operator のアンインストール後にこれらを削除するには、Operator CRD を手動で削除する必要があります。

手順

1. サブスクライブされた Operator (例: jaeger) の現行バージョンを currentCSV フィールドで確認します。

   $ 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 値を使用し、ターゲット namespace の Operator の CSV を削除します。

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

   出力例

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