第4章 Operator
4.1. Cluster Operator リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator を使用して Kafka クラスターや他の Kafka コンポーネントをデプロイします。
Kafka で利用可能なデプロイメントオプションの詳細は、「Kafka クラスターの設定」を参照してください。
OpenShift では、Kafka Connect デプロイメントに Source2Image 機能を組み込み、追加のコネクターを加えるための便利な方法として利用できます。
4.1.1. Cluster Operator リンクのコピーリンクがクリップボードにコピーされました!
AMQ Streams では、Cluster Operator を使用して以下のクラスターをデプロイおよび管理します。
- Kafka (ZooKeeper、Entity Operator、および Kafka Exporter を含む)
- Kafka Connect
- Kafka MirrorMaker
- Kafka Bridge
クラスターのデプロイメントにはカスタムリソースが使用されます。
たとえば、以下のように Kafka クラスターをデプロイします。
-
クラスター設定のある
Kafkaリソースが OpenShift クラスター内で作成されます。 -
Kafkaリソースに宣言された内容を基にして、該当する Kafka クラスターが Cluster Operator によってデプロイされます。
Cluster Operator で以下もデプロイできます (Kafka リソースの設定より)。
-
KafkaTopicカスタムリソースより Operator スタイルのトピック管理を提供する Topic Operator -
KafkaUserカスタムリソースより Operator スタイルのユーザー管理を提供する User Operator
デプロイメントの Entity Operator 内の Topic Operator および User Operator 関数。
Cluster Operator のアーキテクチャー例
4.1.2. Cluster Operator デプロイメントの監視オプション リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator の稼働中に、Kafka リソースの更新に対する監視が開始されます。
Cluster Operator はデプロイメントに応じて、以下から Kafka リソースを監視できます。
AMQ Streams では、デプロイメントの処理を簡単にするため、サンプル YAML ファイルが提供されます。
Cluster Operator では、以下のリソースの変更が監視されます。
-
Kafka クラスターの
Kafka。 -
KafkaConnectの Kafka Connect クラスター。 -
Source2Image がサポートされる Kafka Connect クラスターの
KafkaConnectS2I。 -
Kafka Connect クラスターでコネクターを作成および管理するための
KafkaConnector。 -
Kafka MirrorMaker インスタンスの
KafkaMirrorMaker。 -
Kafka Bridge インスタンスの
KafkaBridge。
OpenShift クラスターでこれらのリソースの 1 つが作成されると、Operator によってクラスターの詳細がリソースより取得されます。さらに、StatefulSet、Service、および ConfigMap などの必要な OpenShift リソースが作成され、リソースの新しいクラスターの作成が開始されます。
Kafka リソースが更新されるたびに、リソースのクラスターを構成する OpenShift リソースで該当する更新が Operator によって実行されます。
クラスターの望ましい状態がリソースのクラスターに反映されるようにするため、リソースへのパッチ適用後またはリソースの削除後にリソースが再作成されます。この操作は、サービスの中断を引き起こすローリングアップデートの原因となる可能性があります。
リソースが削除されると、Operator によってクラスターがアンデプロイされ、関連する OpenShift リソースがすべて削除されます。
4.1.3. 単一の namespace を監視対象とする Cluster Operator のデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
この手順では、
CustomResourceDefinitions、ClusterRoles、およびClusterRoleBindingsを作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーはsystem:adminなどの OpenShift クラスター管理者に限定されます。 Cluster Operator がインストールされる namespace に従い、インストールファイルを編集します。
Linux の場合は、以下を使用します。
sed -i 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yaml
sed -i 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow MacOS の場合は、以下を使用します。
sed -i '' 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yaml
sed -i '' 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
Cluster Operator をデプロイします。
oc apply -f install/cluster-operator -n my-namespace
oc apply -f install/cluster-operator -n my-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.4. 複数の namespace を監視対象とする Cluster Operator のデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
前提条件
-
この手順では、
CustomResourceDefinitions、ClusterRoles、およびClusterRoleBindingsを作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーはsystem:adminなどの OpenShift クラスター管理者に限定されます。 Cluster Operator がインストールされる namespace にしたがって、インストールファイルを編集します。
Linux の場合は、以下を使用します。
sed -i 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yaml
sed -i 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow MacOS の場合は、以下を使用します。
sed -i '' 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yaml
sed -i '' 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
手順
install/cluster-operator/050-Deployment-strimzi-cluster-operator.yamlファイルを編集し、環境変数STRIMZI_NAMESPACEで、Cluster Operator がリソースを監視するすべての namespace を一覧表示します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Operator によって監視されるすべての namespace (上記の例では
watched-namespace-1、watched-namespace-2、およびwatched-namespace-3) に対して、RoleBindingsをインストールします。watched-namespaceは、直前のステップで使用した namespace に置き換えます。oc applyを使用してこれを行うことができます。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
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-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow Cluster Operator をデプロイします。
oc applyを使用してこれを行うことができます。oc apply -f install/cluster-operator -n my-namespace
oc apply -f install/cluster-operator -n my-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.5. すべての namespace を対象とする Cluster Operator のデプロイメント リンクのコピーリンクがクリップボードにコピーされました!
OpenShift クラスターのすべての namespace で AMQ Streams リソースを監視するように Cluster Operator を設定できます。このモードで実行している場合、Cluster Operator によって、新規作成された namespace でクラスターが自動的に管理されます。
前提条件
-
この手順では、
CustomResourceDefinitions、ClusterRoles、およびClusterRoleBindingsを作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーはsystem:adminなどの OpenShift クラスター管理者に限定されます。 - OpenShift クラスターが稼働している必要があります。
手順
すべての namespace を監視するように Cluster Operator を設定します。
-
050-Deployment-strimzi-cluster-operator.yamlファイルを編集します。 STRIMZI_NAMESPACE環境変数の値を*に設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
-
クラスター全体ですべての namespace にアクセスできる権限を Cluster Operator に付与する
ClusterRoleBindingsを作成します。oc create clusterrolebindingコマンドを使用します。oc create clusterrolebinding strimzi-cluster-operator-namespaced --clusterrole=strimzi-cluster-operator-namespaced --serviceaccount my-namespace:strimzi-cluster-operator oc create clusterrolebinding strimzi-cluster-operator-entity-operator-delegation --clusterrole=strimzi-entity-operator --serviceaccount my-namespace:strimzi-cluster-operator oc create clusterrolebinding strimzi-cluster-operator-topic-operator-delegation --clusterrole=strimzi-topic-operator --serviceaccount my-namespace:strimzi-cluster-operator
oc create clusterrolebinding strimzi-cluster-operator-namespaced --clusterrole=strimzi-cluster-operator-namespaced --serviceaccount my-namespace:strimzi-cluster-operator oc create clusterrolebinding strimzi-cluster-operator-entity-operator-delegation --clusterrole=strimzi-entity-operator --serviceaccount my-namespace:strimzi-cluster-operator oc create clusterrolebinding strimzi-cluster-operator-topic-operator-delegation --clusterrole=strimzi-topic-operator --serviceaccount my-namespace:strimzi-cluster-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow my-namespaceは、Cluster Operator をインストールする namespace に置き換えます。Cluster Operator を OpenShift クラスターにデプロイします。
oc applyコマンドを使用します。oc apply -f install/cluster-operator -n my-namespace
oc apply -f install/cluster-operator -n my-namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.6. 調整 リンクのコピーリンクがクリップボードにコピーされました!
Operator は OpenShift クラスターから受信する必要なクラスターリソースに関するすべての通知に対応しますが、Operator が実行されていない場合や、何らかの理由で通知が受信されない場合、必要なリソースは実行中の OpenShift クラスターの状態と同期しなくなります。
フェイルオーバーを適切に処理するために、Cluster Operator によって定期的な調整プロセスが実行され、必要なリソースすべてで一貫した状態になるように、必要なリソースの状態を現在のクラスターデプロイメントと比較できます。[STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 変数を使用して、定期的な調整の期間を設定できます。
4.1.7. Cluster Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator は、以下のサポートされる環境変数を使用して設定できます。
STRIMZI_NAMESPACEOperator が操作する namespace のカンマ区切りのリスト。設定されていない場合や、空の文字列や
*に設定された場合は、Cluster Operator はすべての namespace で操作します。Cluster Operator デプロイメントでは OpenShift Downward API を使用して、これを Cluster Operator がデプロイされる namespace に自動設定することがあります。以下に例を示します。env: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespaceenv: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespaceCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
STRIMZI_FULL_RECONCILIATION_INTERVAL_MS - 任意設定、デフォルトは 120000 ミリ秒です。定期的な調整の間隔 (秒単位)。
STRIMZI_LOG_LEVEL-
任意設定、デフォルトは
INFOです。ロギングメッセージの出力レベル。設定可能な値:ERROR、WARNING、INFO、DEBUG、およびTRACE STRIMZI_OPERATION_TIMEOUT_MS- 任意設定、デフォルトは 300000 ミリ秒です。内部操作のタイムアウト (ミリ秒単位)。この値は、標準の OpenShift 操作の時間が通常よりも長いクラスターで (Docker イメージのダウンロードが遅い場合など) AMQ Streams を使用する場合に増やす必要があります。
STRIMZI_KAFKA_IMAGES-
必須。Kafka バージョンから、そのバージョンの Kafka ブローカーが含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>ペアです。例:2.3.0=registry.redhat.io/amq7/amq-streams-kafka-23-rhel7:1.4.0, 2.4.0=registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0これは、「コンテナーイメージ」に説明されているように、Kafka.spec.kafka.versionプロパティーは指定されていてもKafka.spec.kafka.imageプロパティーは指定されていない場合に使用されます。 STRIMZI_DEFAULT_KAFKA_INIT_IMAGE-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0です。「コンテナーイメージ」 でkafka-init-imageとして指定されたイメージがない場合に、初期設定作業 (ラックサポート) のブローカーの前に開始される init コンテナーのデフォルトとして使用するイメージ名。 STRIMZI_DEFAULT_TLS_SIDECAR_KAFKA_IMAGE-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0です。「コンテナーイメージ」 でKafka.spec.kafka.tlsSidecar.imageとして指定されたイメージがない場合に、Kafka の TLS サポートを提供するサイドカーコンテナーをデプロイする際にデフォルトとして使用するイメージ名。 STRIMZI_DEFAULT_TLS_SIDECAR_ZOOKEEPER_IMAGE-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0です。「コンテナーイメージ」 でKafka.spec.zookeeper.tlsSidecar.imageとして指定されたイメージがない場合に、ZooKeeper の TLS サポートを提供するサイドカーコンテナーをデプロイする際にデフォルトとして使用するイメージ名。 STRIMZI_KAFKA_CONNECT_IMAGES-
必須。Kafka バージョンから、そのバージョンの Kafka Connect が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>ペアです。例:2.3.0=registry.redhat.io/amq7/amq-streams-kafka-23-rhel7:1.4.0, 2.4.0=registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0これは、「コンテナーイメージ」に説明されているように、KafkaConnect.spec.versionプロパティーは指定されていてもKafkaConnect.spec.imageプロパティーは指定されていない場合に使用されます。 STRIMZI_KAFKA_CONNECT_S2I_IMAGES-
必須。Kafka バージョンから、そのバージョンの Kafka Connect が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>ペアです。例:2.3.0=registry.redhat.io/amq7/amq-streams-kafka-23-rhel7:1.4.0, 2.4.0=registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0これは、「コンテナーイメージ」に説明されているように、KafkaConnectS2I.spec.versionプロパティーは指定されていてもKafkaConnectS2I.spec.imageプロパティーは指定されていない場合に使用されます。 STRIMZI_KAFKA_MIRROR_MAKER_IMAGES-
必須。Kafka バージョンから、そのバージョンの Kafka Mirror Maker が含まれる該当の Docker イメージへのマッピングが提供されます。必要な構文は、空白またはカンマ区切りの
<version>=<image>ペアです。例:2.3.0=registry.redhat.io/amq7/amq-streams-kafka-23-rhel7:1.4.0, 2.4.0=registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0これは、「コンテナーイメージ」に説明されているように、KafkaMirrorMaker.spec.versionプロパティーは指定されていてもKafkaMirrorMaker.spec.imageプロパティーは指定されていない場合に使用されます。 STRIMZI_DEFAULT_TOPIC_OPERATOR_IMAGE-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0です。Kafkaリソースの 「コンテナーイメージ」 にKafka.spec.entityOperator.topicOperator.imageとして指定されたイメージがない場合に、Topic Operator のデプロイ時にデフォルトとして使用するイメージ名。 STRIMZI_DEFAULT_USER_OPERATOR_IMAGE-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-rhel7-operator:1.4.0です。Kafkaリソースの 「コンテナーイメージ」 にKafka.spec.entityOperator.userOperator.imageとして指定されたイメージがない場合に、User Operator のデプロイ時にデフォルトとして使用するイメージ名。 STRIMZI_DEFAULT_TLS_SIDECAR_ENTITY_OPERATOR_IMAGE-
任意設定で、デフォルトは
registry.redhat.io/amq7/amq-streams-kafka-24-rhel7:1.4.0です。「コンテナーイメージ」 でKafka.spec.entityOperator.tlsSidecar.imageとして指定されたイメージがない場合に、Entity Operator の TLS サポートを提供するサイドカーコンテナーをデプロイする際にデフォルトとして使用するイメージ名。 STRIMZI_IMAGE_PULL_POLICY-
任意設定。AMQ Streams の Cluster Operator によって管理されるすべての Pod のコンテナーに適用される
ImagePullPolicy。有効な値は、Always、IfNotPresent、およびNeverです。指定のない場合、OpenShift のデフォルトが使用されます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。 STRIMZI_IMAGE_PULL_SECRETS-
任意設定。
Secret名のカンマ区切りのリスト。ここで参照されるシークレットには、コンテナーイメージがプルされるコンテナーレジストリーへのクレデンシャルが含まれます。シークレットは、Cluster Operator によって作成されるすべてのPodsのimagePullSecretsフィールドで使用されます。このリストを変更すると、Kafka、Kafka Connect、および Kafka MirrorMaker のすべてのクラスターのローリングアップデートが実行されます。 STRIMZI_KUBERNETES_VERSION任意設定。API サーバーから検出された OpenShift バージョン情報をオーバーライドします。以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.1.8. ロールベースアクセス制御 (RBAC) リンクのコピーリンクがクリップボードにコピーされました!
4.1.8.1. Cluster Operator のロールベースアクセス制御 (RBAC) のプロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator が機能するには、Kafka、KafkaConnect などのリソースや ConfigMaps、Pods、Deployments、StatefulSets、Services などの管理リソースと対話するために OpenShift クラスター内でパーミッションが必要になり ます。このようなパーミッションは、OpenShift のロールベースアクセス制御 (RBAC) リソースに記述されます。
-
ServiceAccount -
RoleおよびClusterRole -
RoleBindingおよびClusterRoleBinding
Cluster Operator は、ClusterRoleBinding を使用して独自の ServiceAccount で実行される他に、OpenShift リソースへのアクセスを必要とするコンポーネントの RBAC リソースを管理します。
また OpenShift には、ServiceAccount で動作するコンポーネントが、その ServiceAccount にはない他の ServiceAccounts の権限を付与しないようにするための特権昇格の保護機能も含まれています。Cluster Operator は、ClusterRoleBindings と、それが管理するリソースで必要な RoleBindings を作成できる必要があるため、Cluster Operator にも同じ権限が必要です。
4.1.8.2. 委譲された権限 リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator が必要な Kafka リソースのリソースをデプロイする場合、以下のように ServiceAccounts、RoleBindings、および ClusterRoleBindings も作成します。
Kafka ブローカー Pod は
cluster-name-kafkaというServiceAccountを使用します。-
ラック機能が使用されると、
strimzi-cluster-name-kafka-initClusterRoleBindingは、strimzi-kafka-brokerと呼ばれるClusterRole経由で、クラスター内のノードへのServiceAccountアクセスを付与するために使用されます。 - ラック機能が使用されていない場合は、バインディングは作成されません。
-
ラック機能が使用されると、
-
ZooKeeper Pod は
cluster-name-zookeeperというServiceAccountを使用します。 Entity Operator は、
cluster-name-entity-operatorというServiceAccountを使用します。-
Topic Operator はステータス情報のある OpenShift イベントを生成し、
ServiceAccountがstrimzi-entity-operatorというClusterRoleにバインドされるようにします。strimzi-entity-operatorはこのアクセス権限をstrimzi-entity-operatorRoleBinding経由で付与します。
-
Topic Operator はステータス情報のある OpenShift イベントを生成し、
-
KafkaConnectおよびKafkaConnectS2Iリソースの Pod はcluster-name-cluster-connectというServiceAccountを使用します。 -
KafkaMirrorMakerの Pod はcluster-name-mirror-makerというServiceAccountを使用します。 -
KafkaBridgeの Pod はcluster-name-bridgeというServiceAccountを使用します。
4.1.8.3. ServiceAccount リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator は ServiceAccount を使用して最適に実行されます。
Cluster Operator の ServiceAccount の例
その後、Cluster Operator の Deployment で、これを spec.template.spec.serviceAccountName に指定する必要があります。
Cluster Operator の Deployment の部分的な例
strimzi-cluster-operator ServiceAccount が serviceAccountName として指定されている 12 行目に注目してください。
4.1.8.4. ClusterRoles リンクのコピーリンクがクリップボードにコピーされました!
Cluster Operator は、必要なリソースへのアクセス権限を付与する ClusterRoles を使用して操作する必要があります。OpenShift クラスターの設定によっては、クラスター管理者が ClusterRoles を作成する必要があることがあります。
クラスター管理者の権限は ClusterRoles の作成にのみ必要です。Cluster Operator はクラスター管理者アカウントで実行されません。
ClusterRoles は、 最小権限の原則に従い、Kafka、Kafka Connect、および ZooKeeper クラスターを操作するために Cluster Operator が必要とする権限のみが含まれます。最初に割り当てられた一連の権限により、Cluster Operator で StatefulSets、Deployments、Pods、および ConfigMaps などの OpenShift リソースを管理できます。
Cluster Operator は ClusterRoles を使用して、namespace スコープリソースのレベルおよびクラスタースコープリソースのレベルで権限を付与します。
Cluster Operator の namespaced リソースのある ClusterRole
2 番目の一連の権限には、クラスタースコープリソースに必要な権限が含まれます。
Cluster Operator のクラスタースコープリソースのある ClusterRole
strimzi-kafka-broker ClusterRole は、ラック機能に使用される Kafka Pod の init コンテナーが必要とするアクセス権限を表します。「委譲された権限」で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole により、OpenShift ノードへのアクセスを Kafka ブローカー Pod に委譲できます。
strimzi-topic-operator の ClusterRole は、Topic Operator が必要とするアクセスを表します。「委譲された権限」で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole により、イベントへのアクセスを Topic Operator に委譲できます。
4.1.8.5. ClusterRoleBindings リンクのコピーリンクがクリップボードにコピーされました!
Operator には ClusterRoleBindings と、ClusterRole をServiceAccount に関連付ける RoleBindings が必要です。ClusterRoleBindings は、クラスタースコープリロースが含まれる ClusterRoles に必要です。
Cluster Operator の ClusterRoleBinding の例
ClusterRoleBindings は、委譲に必要な ClusterRoles にも必要です。
Cluster Operator の RoleBinding の例
namespaced リソースのみが含まれる ClusterRoles は、RoleBindings のみを使用してバインドされます。
4.2. Topic Operator リンクのコピーリンクがクリップボードにコピーされました!
4.2.1. Topic Operator リンクのコピーリンクがクリップボードにコピーされました!
Topic Operator は、OpenShift リソースより Kafka クラスターのトピックを管理する方法を提供します。
Topic Operator のアーキテクチャー例
Topic Operator の役割は、対応する Kafka トピックと同期して Kafka トピックを記述する KafkaTopic OpenShift リソースのセットを保持することです。
KafkaTopic とトピックの関係は次のとおりです。
-
KafkaTopicが作成されると、Topic Operator によってトピックが作成されます。 -
KafkaTopicが削除されると、Topic Operator によってトピックが削除されます。 -
KafkaTopicが変更されると、Topick Operator によってトピックが更新されます。
上記と逆になるトピックと KafkaTopic の関係は次のとおりです。
-
トピックが Kafka クラスター内で作成されると、Operator によって
KafkaTopicが作成されます。 -
トピックが Kafka クラスターから削除されると、Operator によって
KafkaTopicが削除されます。 -
トピックが Kafka クラスターで変更されると、Operator によって
KafkaTopicが更新されます。
このため、KafkaTopic をアプリケーションのデプロイメントの一部として宣言でき、トピックの作成は Topic Operator によって行われます。アプリケーションは、必要なトピックからの作成または消費のみに対処する必要があります。
トピックが再設定された場合や、別の Kafka ノードに再割り当てされた場合、KafkaTopic は常に最新の状態になります。
4.2.2. トピック処理用の Kafka クラスターの特定 リンクのコピーリンクがクリップボードにコピーされました!
KafkaTopic リソースには、このリソースが属する Kafka クラスターに適した名前 (Kafka リソースの名前から派生) を定義するラベルが含まれています。
ラベルは、KafkaTopic リソースを特定し、新しいトピックを作成するために、Topic Operator によって使用されます。また、以降のトピックの処理でも使用されます。
ラベルが Kafka クラスターと一致しない場合、Topic Operator は KafkaTopic を識別できず、トピックは作成されません。
4.2.3. Topic Operator について リンクのコピーリンクがクリップボードにコピーされました!
Operator にとって解決しなければならない基本的な問題として、信頼できる唯一の情報源 (SSOT: single source of truth) がないことがあります。KafkaTopic リソースと Kafka 内のトピックの両方とも、Operator に関係なく変更される可能性があります面倒なことに、Topic Operator は KafkaTopic リソースと Kafka トピックで変更を常にリアルタイムで監視できるとは限りません (たとえば Operator が停止している場合もあります)。
これを解決するために、Operator は各トピックに関する情報の独自のプライベートコピーを維持します。Kafka クラスターまたは OpenShift で変更が生じると、他のシステムの状態とプライベートコピーの両方を確認し、すべての同期が保たれるように何を変更する必要があるかを判断します。同じことが Operator の起動時に必ず実行され、また Operator の稼働中にも定期的に行われます。
たとえば、Topic Operator が実行されていないときに KafkaTopic の my-topic が作成された場合を考えてみましょう。Operator は、起動時に「my-topic」のプライベートコピーを持たないので、Operator が前回稼働状態であった後に KafkaTopic が作成されたと推測できます。Operator によって「my-topic」に対応するトピックが作成され、さらに「my-topic」のメタデータのプライベートコピーが保存されます。
このプライベートコピーによって、Operator は、Kafka と OpenShift の両方でトピック設定が変更される場合に対処できますが、それができるのは変更に矛盾 (たとえば両方で同じトピックの config キーが異なる値に変更される場合など) がない場合に限ります。変更に矛盾がある場合、Kafka の設定が優先され、KafkaTopic はそれを反映する形で更新されます。
プライベートコピーは、Kafka が使用するのと同じ ZooKeeper アンサンブルに保持されます。これにより可用性の懸念が軽減されます。これは、ZooKeeper が実行中でなければ Kafka 自体を実行できないため、Operator がステートレスであっても可用性は下がらないからです。
4.2.4. Cluster Operator を使用した Topic Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
この手順では、Cluster Operator を使用して Topic Operator をデプロイする方法を説明します。AMQ Streams によって管理されない Kafka クラスターを Topic Operator と使用する場合は、Topic Operator をスタンドアロンコンポーネントとしてデプロイする必要があります。詳細は「スタンドアロン Topic Operator のデプロイ」を参照してください。
前提条件
- 稼働中の Cluster Operator が必要です。
-
作成または更新する
Kafkaリソースが必要です。
手順
Kafka.spec.entityOperatorオブジェクトがKafkaリソースに存在することを確認します。このオブジェクトによって Entity Operator が設定されます。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
「
EntityTopicOperatorSpecスキーマ参照」 で説明されたプロパティーを使用して、Topic Operator を設定します。 OpenShift で Kafka リソースを作成または更新します。
oc applyを使用します。oc apply -f your-file
oc apply -f your-fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
その他のリソース
- Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」 を参照してください。
- Entity Operator のデプロイメントに関する詳細は、「Entitiy Operator」 を参照してください。
-
Cluster Operator によってデプロイされた場合に Topic Operator の設定に使用される
Kafka.spec.entityOperatorオブジェクトに関する詳細は、「EntityOperatorSpecスキーマ参照」 を参照してください。
4.2.5. リソース要求および制限のある Topic Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
CPU やメモリーなどのリソースを Topic Operator に割り当て、Topic Operator が消費できるリソースの量に制限を設定できます。
前提条件
- Cluster Operator が稼働している必要があります。
手順
必要に応じてエディターで Kafka クラスター設定を更新します。
oc editを使用します。oc edit kafka my-cluster
oc edit kafka my-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kafkaリソースのspec.entityOperator.topicOperator.resourcesプロパティーで、Topic Operator のリソース要求および制限を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 新しい設定を適用してリソースを作成または更新します。
oc applyを使用します。oc apply -f kafka.yaml
oc apply -f kafka.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
その他のリソース
-
resourcesオブジェクトのスキーマの詳細は、「ResourceRequirementsスキーマ参照」 を参照してください。
4.2.6. スタンドアロン Topic Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
Topic Operator をスタンドアロンコンポーネントとしてデプロイすることは、Cluster Operator を使用してインストールする場合よりも複雑ですが、柔軟性があります。たとえば、Cluster Operator によってデプロイされた Kafka クラスターに限らず、どの Kafka クラスターでも動作します。
前提条件
- Topic Operator が接続する既存の Kafka クラスターが必要です。
手順
install/topic-operator/05-Deployment-strimzi-topic-operator.yamlリソースを編集します。以下を変更する必要があります。-
Deployment.spec.template.spec.containers[0].envのSTRIMZI_KAFKA_BOOTSTRAP_SERVERS環境変数は、hostname:portペアのカンマ区切りのリストとして、Kafka クラスターのブートストラップブローカーのリストに設定する必要があります。 -
Deployment.spec.template.spec.containers[0].envのSTRIMZI_ZOOKEEPER_CONNECT環境変数は、hostname:portペアのカンマ区切りのリストとして、ZooKeeper ノードのリストに設定する必要があります。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。 -
Deployment.spec.template.spec.containers[0].envのSTRIMZI_NAMESPACE環境変数は、Operator によってKafkaTopicリソースが監視される OpenShift namespace に設定する必要があります。
-
Topic Operator をデプロイします。
oc applyを使用してこれを行うことができます。oc apply -f install/topic-operator
oc apply -f install/topic-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Topic Operator が正常にデプロイされていることを確認します。
oc describeを使用してこれを行うことができます。oc describe deployment strimzi-topic-operator
oc describe deployment strimzi-topic-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Replicas:エントリーに1 availableが表示されれば、Topic Operator はデプロイされています。注記OpenShift への接続が低速な場合やイメージが事前にダウンロードされていない場合は、表示に時間がかかることがあります。
その他のリソース
- Topic Operator の設定に使用される環境変数の詳細は、「Topic Operator 環境」 を参照してください。
- Cluster Operator を使用して Topic Operator をデプロイする方法についての詳細は、「Cluster Operator を使用した Topic Operator のデプロイ」 を参照してください。
4.2.7. Topic Operator 環境 リンクのコピーリンクがクリップボードにコピーされました!
スタンドアロンでデプロイする場合、Topic Operator は環境変数を使用して設定できます。
Cluster Operator によってデプロイされる場合、Topic Operator は Kafka.spec.entityOperator.topicOperator プロパティーを使用して設定する必要があります。
STRIMZI_RESOURCE_LABELS-
ラベルセレクター。Operator によって管理される
KafkaTopicsの識別に使用します。 STRIMZI_ZOOKEEPER_SESSION_TIMEOUT_MS-
ZooKeeper セッションのタイムアウト (秒単位)。例:
10000デフォルトは20000(20 秒) です。 STRIMZI_KAFKA_BOOTSTRAP_SERVERS- Kafka ブートストラップサーバーのリスト。この変数は必須です。
STRIMZI_ZOOKEEPER_CONNECT- ZooKeeper 接続情報。この変数は必須です。
STRIMZI_FULL_RECONCILIATION_INTERVAL_MS- 定期的な調整の間隔 (秒単位)。
STRIMZI_TOPIC_METADATA_MAX_ATTEMPTS-
Kafka からトピックメタデータの取得を試行する回数。各試行の間隔は、指数バックオフとして定義されます。パーティションまたはレプリカの数によって、トピックの作成に時間がかかる可能性がある場合は、この値を増やすことを検討してください。デフォルトは
6です。 STRIMZI_TOPICS_PATH-
Zookeeper ノードパス。ここに Topic Operator がそのメタデータを保存します。デフォルトは
/strimzi/topicsです。 STRIMZI_LOG_LEVEL-
ロギングメッセージの出力レベル。設定可能な値:
ERROR、WARNING、INFO、DEBUG、およびTRACEデフォルトはINFOです。 STRIMZI_TLS_ENABLED-
Kafka ブローカーとの通信を暗号化するために、TLS サポートを有効にします。デフォルトは
trueです。 STRIMZI_TRUSTSTORE_LOCATION-
TLS ベースの通信を有効にするための証明書が含まれるトラストストアへのパス。この変数は、TLS が
STRIMZI_TLS_ENABLEDによって有効になっている場合のみ必須です。 STRIMZI_TRUSTSTORE_PASSWORD-
STRIMZI_TRUSTSTORE_LOCATIONで定義される、トラストストアにアクセスするためのパスワード。この変数は、TLS がSTRIMZI_TLS_ENABLEDによって有効になっている場合のみ必須です。 STRIMZI_KEYSTORE_LOCATION-
TLS ベースの通信を有効にするための秘密鍵が含まれるキーストアへのパス。この変数は、TLS が
STRIMZI_TLS_ENABLEDによって有効になっている場合のみ必須です。 STRIMZI_KEYSTORE_PASSWORD-
STRIMZI_KEYSTORE_LOCATIONで定義される、キーストアにアクセスするためのパスワード。この変数は、TLS がSTRIMZI_TLS_ENABLEDによって有効になっている場合のみ必須です。
4.3. User Operator リンクのコピーリンクがクリップボードにコピーされました!
User Operator はカスタムリソースを使用して Kafka ユーザーを管理します。
4.3.1. User Operator リンクのコピーリンクがクリップボードにコピーされました!
User Operator は、Kafka ユーザーが記述される KafkaUser リソースを監視して Kafka クラスターの Kafka ユーザーを管理し、Kafka ユーザーが Kafka クラスターで適切に設定されるようにします。
たとえば、KafkaUser とユーザーの関係は次のようになります。
-
KafkaUserが作成されると、User Operator によって記述されるユーザーが作成されます。 -
KafkaUserが削除されると、User Operator によって記述されるユーザーが削除されます。 -
KafkaUserが変更されると、User Operator によって記述されるユーザーが更新されます。
User Operator は Topic Operator とは異なり、Kafka クラスターからの変更は OpenShift リソースと同期されません。アプリケーションで直接 Kafka トピックを Kafka で作成することは可能ですが、ユーザーが User Operator と同時に直接 Kafka クラスターで管理されることは想定されません。
User Operator では、アプリケーションのデプロイメントの一部として KafkaUser リソースを宣言できます。ユーザーの認証および承認メカニズムを指定できます。たとえば、ユーザーがブローカーへのアクセスを独占しないようにするため、Kafka リソースの使用を制御する ユーザークォータ を設定することもできます。
ユーザーが作成されると、ユーザークレデンシャルが Secret に作成されます。アプリケーションはユーザーとそのクレデンシャルを使用して、認証やメッセージの生成または消費を行う必要があります。
User Operator は 認証のクレデンシャルを管理する他に、KafkaUser 宣言にユーザーのアクセス権限の記述を含めることで承認も管理します。
4.3.2. ユーザー処理用の Kafka クラスターの特定 リンクのコピーリンクがクリップボードにコピーされました!
KafkaUser リソースには、このリソースが属する Kafka クラスターに適した名前 (Kafka リソースの名前から派生) を定義するラベルが含まれています。
このラベルは、KafkaUser リソースを特定し、新しいユーザーを作成するために、User Operator によって使用されます。また、以降のユーザーの処理でも使用されます。
ラベルが Kafka クラスターと一致しない場合、User Operator は kafkaUser を識別できず、ユーザーは作成されません。
4.3.3. Cluster Operator を使用した User Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- 稼働中の Cluster Operator が必要です。
-
作成または更新する
Kafkaリソースが必要です。
手順
-
Kafkaリソースを編集し、希望どおりに User Operator を設定するKafka.spec.entityOperator.userOperatorオブジェクトが含まれるようにします。 OpenShift で Kafka リソースを作成または更新します。
oc applyを使用してこれを行うことができます。oc apply -f your-file
oc apply -f your-fileCopy to Clipboard Copied! Toggle word wrap Toggle overflow
その他のリソース
- Cluster Operator のデプロイメントに関する詳細は、「Cluster Operator」 を参照してください。
-
Cluster Operator によってデプロイされた場合に Topic Operator の設定に使用される
Kafka.spec.entityOperatorオブジェクトに関する詳細は「EntityOperatorSpecスキーマ参照」を参照してください。
4.3.4. リソース要求および制限のある User Operator の設定 リンクのコピーリンクがクリップボードにコピーされました!
CPU やメモリーなどのリソースを User Operator に割り当て、User Operator が消費できるリソースの量に制限を設定できます。
前提条件
- Cluster Operator が稼働している必要があります。
手順
必要に応じてエディターで Kafka クラスター設定を更新します。
oc edit kafka my-cluster
oc edit kafka my-clusterCopy to Clipboard Copied! Toggle word wrap Toggle overflow Kafkaリソースのspec.entityOperator.userOperator.resourcesプロパティーで、User Operator のリソース要求および制限を設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ファイルを保存し、エディターを終了します。Cluster Operator によって変更が自動的に適用されます。
その他のリソース
-
resourcesオブジェクトのスキーマの詳細は、「ResourceRequirementsスキーマ参照」 を参照してください。
4.3.5. スタンドアロン User Operator のデプロイ リンクのコピーリンクがクリップボードにコピーされました!
User Operator をスタンドアロンコンポーネントとしてデプロイすることは、Cluster Operator を使用してインストールする場合よりも複雑ですが、柔軟性があります。たとえば、Cluster Operator によってデプロイされた Kafka クラスターのみに限らず、どの Kafka クラスターでも動作します。
前提条件
- User Operator が接続する既存の Kafka クラスターが必要です。
手順
install/user-operator/05-Deployment-strimzi-user-operator.yamlリソースを編集します。以下を変更する必要があります。-
Deployment.spec.template.spec.containers[0].envのSTRIMZI_CA_CERT_NAME環境変数は、TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の公開鍵が含まれる OpenShiftSecretを参照するように設定する必要があります。Secretのca.crtキーには、認証局の公開鍵が含まれている必要があります。 -
Deployment.spec.template.spec.containers[0].envのSTRIMZI_CA_KEY_NAME環境変数は、TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の秘密鍵が含まれる OpenShiftSecretを参照するように設定する必要があります。Secretのca.keyキーに、認証局の秘密鍵が含まれている必要があります。 -
Deployment.spec.template.spec.containers[0].envのSTRIMZI_ZOOKEEPER_CONNECT環境変数は、hostname:portペアのカンマ区切りのリストとして、ZooKeeper ノードのリストに設定する必要があります。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。 -
Deployment.spec.template.spec.containers[0].envのSTRIMZI_NAMESPACE環境変数は、Operator によってKafkaUserリソースが監視される OpenShift namespace に設定する必要があります。
-
User Operator をデプロイします。
oc applyを使用してこれを行うことができます。oc apply -f install/user-operator
oc apply -f install/user-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow User Operator が正常にデプロイされていることを確認します。
oc describeを使用してこれを行うことができます。oc describe deployment strimzi-user-operator
oc describe deployment strimzi-user-operatorCopy to Clipboard Copied! Toggle word wrap Toggle overflow Replicas:エントリーに1 availableが表示されれば、User Operator はデプロイされています。注記OpenShift への接続が低速な場合やイメージが事前にダウンロードされていない場合は、表示に時間がかかることがあります。
その他のリソース
- Cluster Operator を使用して User Operator をデプロイする方法についての詳細は、「Cluster Operator を使用した User Operator のデプロイ」 を参照してください。