手順

1. Cluster Operator がインストールされる namespace を使用するように、AMQ Streams のインストールファイルを編集します。

   たとえば、この手順では Cluster Operator は my-cluster-operator-namespace という namespace にインストールされます。

   Linux の場合は、以下を使用します。

   sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   MacOS の場合は、以下を使用します。

   sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

2. Cluster Operator をデプロイします。

   oc apply -f install/cluster-operator -n my-cluster-operator-namespace

3. Cluster Operator が正常にデプロイされたことを確認します。

   oc get deployments

手順

1. Cluster Operator がインストールされる namespace を使用するように、AMQ Streams のインストールファイルを編集します。

   たとえば、この手順では Cluster Operator は my-cluster-operator-namespace という namespace にインストールされます。

   Linux の場合は、以下を使用します。

   sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   MacOS の場合は、以下を使用します。

   sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

2. install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml ファイルを編集し、Cluster Operator によって監視されるすべての namespace のリストを STRIMZI_NAMESPACE 環境変数に追加します。

   たとえば、この手順では Cluster Operator は watched-namespace-1、watched-namespace-2、および watched-namespace-3 という namespace を監視します。

   apiVersion: apps/v1
   kind: Deployment
   spec:
     # ...
     template:
       spec:
         serviceAccountName: strimzi-cluster-operator
         containers:
         - name: strimzi-cluster-operator
           image: registry.redhat.io/amq7/amq-streams-rhel7-operator:1.5.0
           imagePullPolicy: IfNotPresent
           env:
           - name: STRIMZI_NAMESPACE
             value: watched-namespace-1,watched-namespace-2,watched-namespace-3

3. リストした各 namespace に RoleBindings をインストールします。

   この例では、コマンドの watched-namespace を前述のステップでリストした namespace に置き換えます。watched-namespace-1、watched-namespace-2、および watched-namespace-3 に対してこれを行います。

   oc apply -f install/cluster-operator/020-RoleBinding-strimzi-cluster-operator.yaml -n watched-namespace
   oc apply -f install/cluster-operator/031-RoleBinding-strimzi-cluster-operator-entity-operator-delegation.yaml -n watched-namespace
   oc apply -f install/cluster-operator/032-RoleBinding-strimzi-cluster-operator-topic-operator-delegation.yaml -n watched-namespace

4. Cluster Operator をデプロイします。

   oc apply -f install/cluster-operator -n my-cluster-operator-namespace

5. Cluster Operator が正常にデプロイされたことを確認します。

   oc get deployments

手順

1. Cluster Operator がインストールされる namespace を使用するように、AMQ Streams のインストールファイルを編集します。

   たとえば、この手順では Cluster Operator は my-cluster-operator-namespace という namespace にインストールされます。

   Linux の場合は、以下を使用します。

   sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   MacOS の場合は、以下を使用します。

   sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

2. install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml ファイルを編集し、STRIMZI_NAMESPACE 環境変数の値を * に設定します。

   apiVersion: apps/v1
   kind: Deployment
   spec:
     # ...
     template:
       spec:
         # ...
         serviceAccountName: strimzi-cluster-operator
         containers:
         - name: strimzi-cluster-operator
           image: registry.redhat.io/amq7/amq-streams-rhel7-operator:1.5.0
           imagePullPolicy: IfNotPresent
           env:
           - name: STRIMZI_NAMESPACE
             value: "*"
           # ...

3. クラスター全体ですべての namespace にアクセスできる権限を Cluster Operator に付与する ClusterRoleBindings を作成します。

   oc create clusterrolebinding strimzi-cluster-operator-namespaced --clusterrole=strimzi-cluster-operator-namespaced --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
   oc create clusterrolebinding strimzi-cluster-operator-entity-operator-delegation --clusterrole=strimzi-entity-operator --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
   oc create clusterrolebinding strimzi-cluster-operator-topic-operator-delegation --clusterrole=strimzi-topic-operator --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator

   my-cluster-operator-namespace は、Cluster Operator をインストールする namespace に置き換えます。

4. Cluster Operator を OpenShift クラスターにデプロイします。

   oc apply -f install/cluster-operator -n my-cluster-operator-namespace

5. Cluster Operator が正常にデプロイされたことを確認します。

   oc get deployments

手順

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

2. Streaming & Messaging カテゴリーの AMQ Streams Operator を検索または閲覧します。

   
3. AMQ Streams タイルをクリックし、右側のサイドバーで Install をクリックします。

4. Create Operator Subscription 画面で、以下のインストールおよび更新オプションから選択します。

   • Installation Mode: AMQ Streams Operator をクラスターのすべての (プロジェクト) namespace にインストール (デフォルト) するか、特定の (プロジェクト) namespace インストールするかを選択します。namespace を使用して関数を分離することが推奨されます。特定の namespace を Kafka クラスターおよびその他の AMQ Streams コンポーネントの専用とすることが推奨されます。
   • Approval Strategy: デフォルトでは、OLM (Operator Lifecycle Manager) によって、AMQ Streams Operator が自動的に最新の AMQ Streams バージョンにアップグレードされます。今後のアップグレードを手動で承認する場合は、Manual を選択します。詳細は、OpenShift ドキュメントのOperatorを参照してください。

5. Subscribe をクリックすると、AMQ Streams Operator が OpenShift クラスターにインストールされます。

   AMQ Streams Operator によって、Cluster Operator、CRD、およびロールベースアクセス制御 (RBAC) リソースは選択された namespace またはすべての namespace にデプロイされます。

6. Installed Operators 画面で、インストールの進捗を確認します。AMQ Streams Operator は、ステータスが InstallSucceeded に変更されると使用できます。

   

手順

1. 一時 または 永続 クラスターを作成およびデプロイします。

   開発またはテストでは、一時クラスターの使用が適している可能性があります。永続クラスターはどのような状況でも使用することができます。

   • 一時 クラスターを作成およびデプロイするには、以下を実行します。

     oc apply -f examples/kafka/kafka-ephemeral.yaml

   • 永続 クラスターを作成およびデプロイするには、以下を実行します。

     oc apply -f examples/kafka/kafka-persistent.yaml

2. Kafka クラスターが正常にデプロイされたことを確認します。

   oc get deployments

手順

1. Kafka リソースの entityOperator プロパティーを編集し、topicOperator が含まれるようにします。

   apiVersion: kafka.strimzi.io/v1beta1
   kind: Kafka
   metadata:
     name: my-cluster
   spec:
     #...
     entityOperator:
       topicOperator: {}
       userOperator: {}

2. EntityTopicOperatorSpec スキーマ参照に記載されているプロパティーを使用して、Topic Operator の spec を設定します。

   すべてのプロパティーにデフォルト値を使用する場合は、空のオブジェクト ({}) を使用します。

3. リソースを作成または更新します。

   次のように oc apply を使用します。

   oc apply -f <your-file>

手順

1. Kafka リソースの entityOperator プロパティーを編集し、userOperator が含まれるようにします。

   apiVersion: kafka.strimzi.io/v1beta1
   kind: Kafka
   metadata:
     name: my-cluster
   spec:
     #...
     entityOperator:
       topicOperator: {}
       userOperator: {}

2. EntityUserOperatorSpec スキーマ参照 に記載されているプロパティーを使用して、User Operator の spec を設定します。

   すべてのプロパティーにデフォルト値を使用する場合は、空のオブジェクト ({}) を使用します。

3. リソースを作成または更新します。

   oc apply -f <your-file>

手順

1. 以下を設定し、install/topic-operator/05-Deployment-strimzi-topic-operator.yaml ファイルの Deployment.spec.template.spec.containers[0].env プロパティーを編集します。

   1. STRIMZI_KAFKA_BOOTSTRAP_SERVERS。 hostname:‍port ペアのコンマ区切りリストで Kafka クラスターのブートストラップブローカーを指定します。
   2. STRIMZI_ZOOKEEPER_CONNECT。hostname:‍port ペアのコンマ区切りリストで ZooKeeper ノードを指定します。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。
   3. STRIMZI_NAMESPACE。Operator が KafkaTopic リソースを監視する OpenShift namespace。
   4. STRIMZI_RESOURCE_LABELS。Operator によって管理される KafkaTopic リソースを識別するために使用されるラベルセレクター。
   5. STRIMZI_FULL_RECONCILIATION_INTERVAL_MS。定期的な調整の間隔 (秒単位) を指定します。
   6. STRIMZI_TOPIC_METADATA_MAX_ATTEMPTS。Kafka からトピックメタデータを取得するための試行回数を指定します。各試行の間隔は、指数バックオフとして定義されます。パーティションまたはレプリカの数によって、トピックの作成に時間がかかる可能性がある場合は、この値を増やすことを検討してください。デフォルトは 6 です。
   7. STRIMZI_ZOOKEEPER_SESSION_TIMEOUT_MS。ZooKeeper セッションのタイムアウト (ミリ秒単位)。例: 10000。デフォルトは 20000 (20 秒) です。
   8. STRIMZI_TOPICS_PATH。Topic Operator がそのメタデータを保存する Zookeeper ノードパス。デフォルトは /strimzi/topics です。
   9. STRIMZI_TLS_ENABLED。Kafka ブローカーとの通信を暗号化するために、TLS サポートを有効にします。デフォルトは true です。
   10. STRIMZI_TRUSTSTORE_LOCATION。TLS ベースの通信を有効にするための証明書が含まれるトラストストアへのパス。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
   11. STRIMZI_TRUSTSTORE_PASSWORD。STRIMZI_TRUSTSTORE_LOCATION で定義されるトラストストアにアクセスするためのパスワード。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
   12. STRIMZI_KEYSTORE_LOCATION。TLS ベースの通信を有効にするための秘密鍵が含まれるキーストアへのパス。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
   13. STRIMZI_KEYSTORE_PASSWORD。STRIMZI_KEYSTORE_LOCATION で定義されるキーストアにアクセスするためのパスワード。TLS が STRIMZI_TLS_ENABLED によって有効化された場合のみ必須です。
   14. STRIMZI_LOG_LEVEL。ロギングメッセージの出力レベル。値は、ERROR、WARNING、INFO、DEBUG、および TRACE に設定できます。デフォルトは INFO です。
   15. STRIMZI_JAVA_OPTS (任意)。Topic Operator を実行する JVM に使用される Java オプション。例: -Xmx=512M -Xms=256M
   16. STRIMZI_JAVA_SYSTEM_PROPERTIES (任意)。Topic Operator に設定される -D オプションをリストします。例: -Djavax.net.debug=verbose -DpropertyName=value.

2. Topic Operator をデプロイします。

   oc apply -f install/topic-operator

3. Topic Operator が正常にデプロイされていることを確認します。

   oc describe deployment strimzi-topic-operator

   Replicas: エントリーに 1 available が表示されれば、Topic Operator はデプロイされています。

   注記

   OpenShift への接続が低速な場合やイメージがこれまでダウンロードされたことがない場合は、デプロイメントに遅延が発生することがあります。

手順

1. 以下を設定し、install/user-operator/05-Deployment-strimzi-user-operator.yaml ファイルの Deployment.spec.template.spec.containers[0].env プロパティーを編集します。

   1. STRIMZI_KAFKA_BOOTSTRAP_SERVERS。 hostname:‍port ペアのコンマ区切りリストで Kafka ブローカーを指定します。
   2. STRIMZI_ZOOKEEPER_CONNECT。hostname:‍port ペアのコンマ区切りリストで ZooKeeper ノードを指定します。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。TLS 暗号化で ZooKeeper ノードに接続することはサポートされません。
   3. STRIMZI_NAMESPACE。Operator が KafkaUser リソースを監視する OpenShift namespace。
   4. STRIMZI_LABELS。Operator によって管理される KafkaUser リソースを識別するために使用されるラベルセレクター。
   5. STRIMZI_FULL_RECONCILIATION_INTERVAL_MS。定期的な調整の間隔 (秒単位) を指定します。
   6. STRIMZI_ZOOKEEPER_SESSION_TIMEOUT_MS。ZooKeeper セッションのタイムアウト (ミリ秒単位)。例: 10000。デフォルトは 20000 (20 秒) です。
   7. STRIMZI_CA_CERT_NAME。TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の公開鍵が含まれる OpenShift Secret を示します。Secret の ca.crt キーに、認証局の公開鍵が含まれている必要があります。
   8. STRIMZI_CA_KEY_NAME。TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の秘密鍵が含まれる OpenShift Secret を示します。Secret の ca.crt キーに、認証局の秘密鍵が含まれている必要があります。
   9. STRIMZI_CLUSTER_CA_CERT_SECRET_NAME。TLS ベースの通信を有効にするために Kafka ブローカーの証明書の署名に使用される認証局の秘密鍵が含まれる OpenShift Secret を示します。Secret の ca.crt キーに、認証局の公開鍵が含まれている必要があります。この環境変数の設定は任意で、Kafka クラスターとの通信が TLS ベースである場合のみ設定する必要があります。
   10. STRIMZI_EO_KEY_SECRET_NAME。Kafka クラスターに対する TLS クライアント認証の秘密鍵と関連する証明書が含まれる OpenShift Secret を示します。Secret の entity-operator.p12 キーに、秘密鍵と証明書が含まれるキーストアが含まれ、 entity-operator.password キーに関連するパスワードが含まれる必要があります。この環境変数の設定は任意で、Kafka クラスターとの通信が TLS ベースで、TLS のクライアント認証が必要な場合のみ設定する必要があります。
   11. STRIMZI_CA_VALIDITY。認証局の有効期限。デフォルトは 365 日です。
   12. STRIMZI_CA_RENEWAL。認証局の更新期限。
   13. STRIMZI_LOG_LEVEL。ロギングメッセージの出力レベル。値は、ERROR、WARNING、INFO、DEBUG、および TRACE に設定できます。デフォルトは INFO です。
   14. STRIMZI_GC_LOG_ENABLED。ガベージコレクション (GC) ロギングを有効にします。デフォルトは true です。デフォルトでは、古い証明書が期限切れになる前の証明書の更新期間は 30 日です。
   15. STRIMZI_JAVA_OPTS (任意)。User Operator を実行する JVM に使用される Java オプション。例: -Xmx=512M -Xms=256M
   16. STRIMZI_JAVA_SYSTEM_PROPERTIES (任意)。User Operator に設定される -D オプションをリストします。例: -Djavax.net.debug=verbose -DpropertyName=value.

2. User Operator をデプロイします。

   oc apply -f install/user-operator

3. User Operator が正常にデプロイされていることを確認します。

   oc describe deployment strimzi-user-operator

   Replicas: エントリーに 1 available が表示されれば、User Operator はデプロイされています。

   注記

   OpenShift への接続が低速な場合やイメージがこれまでダウンロードされたことがない場合は、デプロイメントに遅延が発生することがあります。

手順

1. registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0 をベースイメージとして使用して、新規の Dockerfile を作成します。

   FROM registry.redhat.io/amq7/amq-streams-kafka-25-rhel7:1.5.0
   USER root:root
   COPY ./my-plugins/ /opt/kafka/plugins/
   USER 1001

   プラグインファイルの例

   $ tree ./my-plugins/
   ./my-plugins/
   ├── debezium-connector-mongodb
   │   ├── bson-3.4.2.jar
   │   ├── CHANGELOG.md
   │   ├── CONTRIBUTE.md
   │   ├── COPYRIGHT.txt
   │   ├── debezium-connector-mongodb-0.7.1.jar
   │   ├── debezium-core-0.7.1.jar
   │   ├── LICENSE.txt
   │   ├── mongodb-driver-3.4.2.jar
   │   ├── mongodb-driver-core-3.4.2.jar
   │   └── README.md
   ├── debezium-connector-mysql
   │   ├── CHANGELOG.md
   │   ├── CONTRIBUTE.md
   │   ├── COPYRIGHT.txt
   │   ├── debezium-connector-mysql-0.7.1.jar
   │   ├── debezium-core-0.7.1.jar
   │   ├── LICENSE.txt
   │   ├── mysql-binlog-connector-java-0.13.0.jar
   │   ├── mysql-connector-java-5.1.40.jar
   │   ├── README.md
   │   └── wkb-1.0.2.jar
   └── debezium-connector-postgres
       ├── CHANGELOG.md
       ├── CONTRIBUTE.md
       ├── COPYRIGHT.txt
       ├── debezium-connector-postgres-0.7.1.jar
       ├── debezium-core-0.7.1.jar
       ├── LICENSE.txt
       ├── postgresql-42.0.0.jar
       ├── protobuf-java-2.6.1.jar
       └── README.md

2. コンテナーイメージをビルドします。
3. カスタムイメージをコンテナーレジストリーにプッシュします。

4. 新しいコンテナーイメージを示します。

   以下のいずれかを行います。

   • KafkaConnect カスタムリソースの KafkaConnect.spec.image プロパティーを編集します。

     設定された場合、このプロパティーによって Cluster Operator の STRIMZI_KAFKA_CONNECT_IMAGES 変数がオーバーライドされます。

     apiVersion: kafka.strimzi.io/v1beta1
     kind: KafkaConnect
     metadata:
       name: my-connect-cluster
     spec: 1
       #...
       image: my-new-container-image 2
       config: 3
         #...

     1

     Kafka Connect クラスターの仕様。

     2

     Pod の Docker イメージ。

     3

     Kafka Connect ワーカー (コネクターではない) の設定。

     または

   • install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml ファイルの STRIMZI_KAFKA_CONNECT_IMAGES 変数を編集して新しいコンテナーイメージを示すようにした後、Cluster Operator を再インストールします。

手順

1. コマンドラインで oc apply コマンドを使用し、Kafka Connect の S2I クラスターを作成およびデプロイします。

   oc apply -f examples/connect/kafka-connect-s2i.yaml

2. Kafka Connect プラグインでディレクトリーを作成します。

   $ tree ./my-plugins/
   ./my-plugins/
   ├── debezium-connector-mongodb
   │   ├── bson-3.4.2.jar
   │   ├── CHANGELOG.md
   │   ├── CONTRIBUTE.md
   │   ├── COPYRIGHT.txt
   │   ├── debezium-connector-mongodb-0.7.1.jar
   │   ├── debezium-core-0.7.1.jar
   │   ├── LICENSE.txt
   │   ├── mongodb-driver-3.4.2.jar
   │   ├── mongodb-driver-core-3.4.2.jar
   │   └── README.md
   ├── debezium-connector-mysql
   │   ├── CHANGELOG.md
   │   ├── CONTRIBUTE.md
   │   ├── COPYRIGHT.txt
   │   ├── debezium-connector-mysql-0.7.1.jar
   │   ├── debezium-core-0.7.1.jar
   │   ├── LICENSE.txt
   │   ├── mysql-binlog-connector-java-0.13.0.jar
   │   ├── mysql-connector-java-5.1.40.jar
   │   ├── README.md
   │   └── wkb-1.0.2.jar
   └── debezium-connector-postgres
       ├── CHANGELOG.md
       ├── CONTRIBUTE.md
       ├── COPYRIGHT.txt
       ├── debezium-connector-postgres-0.7.1.jar
       ├── debezium-core-0.7.1.jar
       ├── LICENSE.txt
       ├── postgresql-42.0.0.jar
       ├── protobuf-java-2.6.1.jar
       └── README.md

3. oc start-build コマンドで、準備したディレクトリーを使用してイメージの新しいビルドを開始します。

   oc start-build my-connect-cluster-connect --from-dir ./my-plugins/

   注記

   ビルドの名前は、デプロイされた Kafka Connect クラスターと同じになります。

4. ビルドが完了したら、Kafka Connect のデプロイメントによって新しいイメージが自動的に使用されます。

1. エディターで Kafka リソースを更新します。

   oc edit kafka my-cluster

2. kafka-metrics.yaml の設定例 を、ユーザーの Kafka リソース定義にコピーします。
3. ファイルを保存し、エディターを終了して更新したリソースが調整されるのを待ちます。

手順

1. リポジトリーから bundle.yaml リソースファイルをダウンロードします。

   Linux の場合は、以下を使用します。

   curl -s https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml | sed -e 's/namespace: .*/namespace: my-namespace/' > prometheus-operator-deployment.yaml

   MacOS の場合は、以下を使用します。

   curl -s https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml | sed -e '' 's/namespace: .*/namespace: my-namespace/' > prometheus-operator-deployment.yaml

   • サンプル namespace は、独自の namespace に置き換えます。

     注記

     OpenShift を使用している場合は、Prometheus Operator リポジトリーの OpenShift フォーク のリリースを指定します。

2. (任意) これが必要ない場合は、spec.template.spec.securityContext プロパティーを prometheus-operator-deployment.yaml ファイルから手動で削除できます。

3. Prometheus Operator をデプロイします。

   oc apply -f prometheus-operator-deployment.yaml

手順

1. Prometheus のインストール先となる namespace に従い、Prometheus インストールファイル (prometheus.yaml) を変更します。

   Linux の場合は、以下を使用します。

   sed -i 's/namespace: .*/namespace: my-namespace/' prometheus.yaml

   MacOS の場合は、以下を使用します。

   sed -i '' 's/namespace: .*/namespace: my-namespace/' prometheus.yaml

2. ServiceMonitor リソースを strimzi-service-monitor.yaml で編集し、サービスからメトリクスデータをスクレープする Prometheus ジョブを定義します。ServiceMonitor はサービスからメトリクスをスクレープするために使用され、Apache Kafka や ZooKeeper に使用されます。
3. PodMonitor リソースを strimzi-service-monitor.yaml で編集し、Pod からメトリクスデータをスクレープする Prometheus ジョブを定義します。PodMonitor は、Pod から直接データをスクレープするために使用され、Operator に使用されます。

4. 別のロールを使用するには、以下を実行します。

   1. Secret リソースを作成します。

      oc create secret generic additional-scrape-configs --from-file=prometheus-additional.yaml

   2. prometheus.yaml ファイルで additionalScrapeConfigs プロパティーを編集し、Secret の名前と、追加の設定が含まれる YAML ファイル (prometheus-additional.yaml) を追加します。

5. Prometheus リソースをデプロイします。

   oc apply -f strimzi-service-monitor.yaml
   oc apply -f strimzi-pod-monitor.yaml
   oc apply -f prometheus-rules.yaml
   oc apply -f prometheus.yaml

手順

1. Alertmanager 設定ファイル (alert-manager-config.yaml) から Secret リソースを作成します。

   oc create secret generic alertmanager-alertmanager --from-file=alertmanager.yaml=alert-manager-config.yaml

2. 以下を行って、alert-manager-config.yaml ファイルを更新します。

   • slack_api_url プロパティーを、Slack ワークスペースのアプリケーションに関連する Slack API URL の実際の値に置き換えます。
   • channel プロパティーを、通知が送信される実際の Slack チャネルに置き換えます。

3. Alertmanager をデプロイします。

   oc apply -f alert-manager.yaml

手順

1. Grafana をデプロイします。

   oc apply -f grafana.yaml

2. Grafana ダッシュボードを有効にします。

1. oc port-forward svc/grafana 3000:3000 を実行します。
2. ブラウザーで http://localhost:3000 を指定します。

手順

1. admin/admin クレデンシャルを使用して、Grafana ユーザーインターフェイスにアクセスします。

   最初のビューで、パスワードのリセットを選択します。

   

2. Add data source ボタンをクリックします。

   

3. Prometheus をデータソースとして追加します。

   • 名前を指定します。
   • Prometheus をタイプとして追加します。
   • URL フィールドに、Prometheus サーバーへ接続する URL (http://prometheus-operated:9090) を指定します。

4. Add をクリックしてデータソースへの接続をテストします。

   

5. Dashboards、Import の順にクリックして、Import Dashboard ウィンドウを開き、ダッシュボードのサンプルをインポートします (または JSON を貼り付けます)。

   

手順

1. 既存の Cluster Operator リソース (/install/cluster-operator ディレクトリー内) に追加した設定変更を書留めておきます。すべての変更は、新しいバージョンの Cluster Operator によって上書きされます。

2. Cluster Operator を更新します。

   1. Cluster Operator を実行している namespace に従い、新しいバージョンのインストールファイルを編集します。

      Linux の場合は、以下を使用します。

      sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

      MacOS の場合は、以下を使用します。

      sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   2. 既存の Cluster Operator Deployment で 1 つ以上の環境変数を編集した場合、install/cluster-operator/050-Deployment-cluster-operator.yaml ファイルを編集し、これらの環境変数を使用します。

3. 設定を更新したら、残りのインストールリソースとともにデプロイします。

   oc apply -f install/cluster-operator

   ローリング更新が完了するのを待ちます。

4. Kafka Pod のイメージを取得して、アップグレードが正常に完了したことを確認します。

   oc get po my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'

   イメージタグには、新しい AMQ Streams バージョンと Kafka バージョンが順に示されます。例: <New AMQ Streams version>-kafka-<Current Kafka version>

5. 既存のリソースを更新して、非推奨になったカスタムリソースプロパティーを処理します。

   • AMQ Streams リソースのアップグレード

手順

1. 必要に応じてエディターで Kafka クラスター設定を更新します。

   oc edit kafka my-cluster

   1. 現行のバージョンの Kafka の log.message.format.version が新しい Kafka バージョンでも同じ場合は、次の手順に進みます。

      それ以外の場合、Kafka.spec.kafka.config の log.message.format.version が 現行 バージョンのデフォルトに設定されていることを確認してください。

      たとえば、Kafka 2.4.1 からのアップグレードでは以下のようになります。

      kind: Kafka
      spec:
        # ...
        kafka:
          version: 2.4.1
          config:
            log.message.format.version: "2.4"
            # ...

      log.message.format.version が設定されていない場合は、現行バージョンに設定します。

      注記

      log.message.format.version の値は、浮動小数点数として解釈されないように文字列である必要があります。

   2. Kafka.spec.kafka.version を変更し、新バージョンを指定します (log.message.format.version は現行バージョンのままにします)。

      たとえば、Kafka 2.4.1 から 2.5.0 へのアップグレードは以下のようになります。

      apiVersion: v1alpha1
      kind: Kafka
      spec:
        # ...
        kafka:
          version: 2.5.0 1
          config:
            log.message.format.version: "2.4" 2
            # ...

      1

      これは新バージョンに変更されます。

      2

      これは現行バージョンのままです。

   3. Kafka バージョンのイメージが Cluster Operator の STRIMZI_KAFKA_IMAGES に定義されているイメージとは異なる場合は、Kafka.spec.kafka.image を更新します。

      「Kafka バージョンおよびイメージマッピング」 を参照

2. エディターを保存して終了し、ローリング更新の完了を待ちます。

   注記

   新バージョンの Kafka に新しい ZooKeeper バージョンがある場合、追加のローリング更新が発生します。

   更新をログで確認するか、または Pod 状態の遷移を監視して確認します。

   oc logs -f <cluster-operator-pod-name> | grep -E "Kafka version upgrade from [0-9.]+ to [0-9.]+, phase ([0-9]+) of \1 completed"

   oc get po -w

   現行バージョンと新バージョンの Kafka で、Interbroker プロトコルのバージョンが異なる場合は、Cluster Operator ログで INFO レベルのメッセージを確認します。

   Reconciliation #<num>(watch) Kafka(<namespace>/<name>): Kafka version upgrade from <from-version> to <to-version>, phase 2 of 2 completed

   または、現行バージョンと新バージョンの Kafka で、Interbroker プロトコルのバージョンが同じ場合は、以下を確認します。

   Reconciliation #<num>(watch) Kafka(<namespace>/<name>): Kafka version upgrade from <from-version> to <to-version>, phase 1 of 1 completed

   ローリング更新では以下を行います。

   • 各 Pod が新バージョンの Kafka のブローカーバイナリーを使用していることを確認します。

   • 新バージョンの Kafka の Interbroker プロトコルを使用してメッセージを送信するように、ブローカーを設定します。

     注記

     クライアントは引き続き旧バージョンを使用するため、ブローカーはメッセージを旧バージョンに変換してからクライアントに送信します。この余分な負荷を最小化するには、できるだけ速やかにクライアントを更新します。

3. クライアントのアップグレードに選択したストラテジーに応じて、新バージョンのクライアントバイナリーを使用するようにすべてのクライアントアプリケーションをアップグレードします。

   「クライアントをアップグレードするストラテジー」 を参照

   警告

   この手順を完了すると、ダウングレードできません。この時点で更新を元に戻す必要がある場合は、「Kafka ブローカーおよびクライアントアプリケーションのダウングレード」 の手順に従います。

   必要に応じて、Kafka Connect および MirrorMaker のバージョンプロパティーを新バージョンの Kafka として設定します。

   1. Kafka Connect では、KafkaConnect.spec.version を更新します。
   2. MirrorMaker では、KafkaMirrorMaker.spec.version を更新します。

4. 1. で特定された log.message.format.version が、新しいバージョンと同じ場合は、次の手順に進みます。

   それ以外の場合は、Kafka.spec.kafka.config の log.message.format.version を、現在使用している新バージョンの Kafka のデフォルトバージョンに変更します。

   たとえば、2.5.0 へのアップグレードでは以下のようになります。

   apiVersion: v1alpha1
   kind: Kafka
   spec:
     # ...
     kafka:
       version: 2.5.0
       config:
         log.message.format.version: "2.5"
         # ...

5. Cluster Operator によってクラスターが更新されるまで待ちます。

   これで、Kafka クラスターおよびクライアントが新バージョンの Kafka を使用するようになります。

1. Kafka クライアント .jar ファイルを新バージョンに置き換える。
2. コンシューマー設定で、partition.assignment.strategy に cooperative-sticky を追加する。たとえば、range ストラテジーが設定されている場合は、設定を range, cooperative-sticky に変更する。
3. グループ内の各コンシューマーを順次再起動し、再起動後に各コンシューマーがグループに再度参加するまで待つ。
4. コンシューマー設定から前述の partition.assignment.strategy を削除して、グループの各コンシューマーを再設定し、cooperative-sticky ストラテジーのみを残す。
5. グループ内の各コンシューマーを順次再起動し、再起動後に各コンシューマーがグループに再度参加するまで待つ。

1. Kafka Streams の .jar ファイルを新バージョンに置き換えます。
2. Kafka Streams の設定で、upgrade.from 設定パラメーターをアップグレード前の Kafka バージョンに設定します (例: 2.3)。
3. 各ストリームプロセッサー (ノード) を順次再起動します。
4. upgrade.from 設定パラメーターを Kafka Streams 設定から削除します。
5. グループ内の各コンシューマーを順次再起動します。

手順

1. 必要に応じてエディターで Kafka クラスター設定を更新します。

   oc edit を使用します。

   oc edit kafka my-cluster

   1. Kafka.spec.kafka.version を変更して、以前のバージョンを指定します。

      たとえば、Kafka 2.5.0 から 2.4.1 へのダウングレードは以下のようになります。

      apiVersion: v1alpha1
      kind: Kafka
      spec:
        # ...
        kafka:
          version: 2.4.1 1
          config:
            log.message.format.version: "2.4" 2
            # ...

      1

      これは以前のバージョンに変更されます。

      2

      これは変更されません。

      注記

      log.message.format.version の値は、浮動小数点数として解釈されないように、文字列とする必要があります。

   2. Kafka バージョンのイメージが Cluster Operator の STRIMZI_KAFKA_IMAGES に定義されているイメージとは異なる場合は、Kafka.spec.kafka.image を更新します。

      「Kafka バージョンおよびイメージマッピング」 を参照

2. エディターを保存して終了し、ローリング更新の完了を待ちます。

   更新をログで確認するか、または Pod 状態の遷移を監視して確認します。

   oc logs -f <cluster-operator-pod-name> | grep -E "Kafka version downgrade from [0-9.]+ to [0-9.]+, phase ([0-9]+) of \1 completed"

   oc get po -w

   Kafka の前バージョンと現行バージョンで Interbroker プロトコルのバージョンが異なる場合、Cluster Operator ログで INFO レベルのメッセージを確認します。

   Reconciliation #<num>(watch) Kafka(<namespace>/<name>): Kafka version downgrade from <from-version> to <to-version>, phase 2 of 2 completed

   または、Kafka の前バージョンと現行バージョンで Interbroker プロトコルのバージョンが同じ場合は、以下を確認します。

   Reconciliation #<num>(watch) Kafka(<namespace>/<name>): Kafka version downgrade from <from-version> to <to-version>, phase 1 of 1 completed

3. すべてのクライアントアプリケーション (コンシューマー) をダウングレードして、以前のバージョンのクライアントバイナリーを使用します。

   これで、Kafka クラスターおよびクライアントは以前の Kafka バージョンを使用するようになります。