第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
MacOS の場合は、以下を使用します。
sed -i '' 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yaml
手順
Cluster Operator をデプロイします。
oc apply -f install/cluster-operator -n my-namespace
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
MacOS の場合は、以下を使用します。
sed -i '' 's/namespace: .*/namespace: my-namespace/' install/cluster-operator/*RoleBinding*.yaml
手順
install/cluster-operator/050-Deployment-strimzi-cluster-operator.yaml
ファイルを編集し、環境変数STRIMZI_NAMESPACE
で、Cluster Operator がリソースを監視するすべての 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.4.0 imagePullPolicy: IfNotPresent env: - name: STRIMZI_NAMESPACE value: watched-namespace-1,watched-namespace-2,watched-namespace-3
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
Cluster Operator をデプロイします。
oc apply
を使用してこれを行うことができます。oc apply -f install/cluster-operator -n my-namespace
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
環境変数の値を*
に設定します。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.4.0 imagePullPolicy: IfNotPresent env: - name: STRIMZI_NAMESPACE value: "*" # ...
-
クラスター全体ですべての 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
my-namespace
は、Cluster Operator をインストールする namespace に置き換えます。Cluster Operator を OpenShift クラスターにデプロイします。
oc apply
コマンドを使用します。oc apply -f install/cluster-operator -n my-namespace
4.1.6. 調整
Operator は OpenShift クラスターから受信する必要なクラスターリソースに関するすべての通知に対応しますが、Operator が実行されていない場合や、何らかの理由で通知が受信されない場合、必要なリソースは実行中の OpenShift クラスターの状態と同期しなくなります。
フェイルオーバーを適切に処理するために、Cluster Operator によって定期的な調整プロセスが実行され、必要なリソースすべてで一貫した状態になるように、必要なリソースの状態を現在のクラスターデプロイメントと比較できます。[STRIMZI_FULL_RECONCILIATION_INTERVAL_MS] 変数を使用して、定期的な調整の期間を設定できます。
4.1.7. Cluster Operator の設定
Cluster Operator は、以下のサポートされる環境変数を使用して設定できます。
STRIMZI_NAMESPACE
Operator が操作する namespace のカンマ区切りのリスト。設定されていない場合や、空の文字列や
*
に設定された場合は、Cluster Operator はすべての namespace で操作します。Cluster Operator デプロイメントでは OpenShift Downward API を使用して、これを Cluster Operator がデプロイされる namespace に自動設定することがあります。以下に例を示します。env: - name: STRIMZI_NAMESPACE valueFrom: fieldRef: fieldPath: metadata.namespace
-
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 バージョン情報をオーバーライドします。以下に例を示します。
env: - name: STRIMZI_KUBERNETES_VERSION value: | major=1 minor=16 gitVersion=v1.16.2 gitCommit=c97fe5036ef3df2967d086711e6c0c405941e14b gitTreeState=clean buildDate=2019-10-15T19:09:08Z goVersion=go1.12.10 compiler=gc platform=linux/amd64
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-init
ClusterRoleBinding
は、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-operator
RoleBinding
経由で付与します。
-
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
の例
apiVersion: v1 kind: ServiceAccount metadata: name: strimzi-cluster-operator labels: app: strimzi
その後、Cluster Operator の Deployment
で、これを spec.template.spec.serviceAccountName
に指定する必要があります。
Cluster Operator の Deployment
の部分的な例
apiVersion: apps/v1 kind: Deployment metadata: name: strimzi-cluster-operator labels: app: strimzi spec: replicas: 1 selector: matchLabels: name: strimzi-cluster-operator strimzi.io/kind: cluster-operator template: # ...
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
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-namespaced labels: app: strimzi rules: - apiGroups: - "" resources: - serviceaccounts verbs: - get - create - delete - patch - update - apiGroups: - rbac.authorization.k8s.io resources: - rolebindings verbs: - get - create - delete - patch - update - apiGroups: - "" resources: - configmaps verbs: - get - list - watch - create - delete - patch - update - apiGroups: - kafka.strimzi.io resources: - kafkas - kafkas/status - kafkaconnects - kafkaconnects/status - kafkaconnects2is - kafkaconnects2is/status - kafkaconnectors - kafkaconnectors/status - kafkamirrormakers - kafkamirrormakers/status - kafkabridges - kafkabridges/status - kafkamirrormaker2s - kafkamirrormaker2s/status verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: - pods verbs: - get - list - watch - delete - apiGroups: - "" resources: - services verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: - endpoints verbs: - get - list - watch - apiGroups: - extensions resources: - deployments - deployments/scale - replicasets verbs: - get - list - watch - create - delete - patch - update - apiGroups: - apps resources: - deployments - deployments/scale - deployments/status - statefulsets - replicasets verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: - events verbs: - create - apiGroups: - extensions resources: - replicationcontrollers verbs: - get - list - watch - create - delete - patch - update - apiGroups: - apps.openshift.io resources: - deploymentconfigs - deploymentconfigs/scale - deploymentconfigs/status - deploymentconfigs/finalizers verbs: - get - list - watch - create - delete - patch - update - apiGroups: - build.openshift.io resources: - buildconfigs - builds verbs: - create - delete - get - list - patch - watch - update - apiGroups: - image.openshift.io resources: - imagestreams - imagestreams/status verbs: - create - delete - get - list - watch - patch - update - apiGroups: - "" resources: - replicationcontrollers verbs: - get - list - watch - create - delete - patch - update - apiGroups: - "" resources: - secrets verbs: - get - list - create - delete - patch - update - apiGroups: - extensions resources: - networkpolicies verbs: - get - list - watch - create - delete - patch - update - apiGroups: - networking.k8s.io resources: - networkpolicies verbs: - get - list - watch - create - delete - patch - update - apiGroups: - route.openshift.io resources: - routes - routes/custom-host verbs: - get - list - create - delete - patch - update - apiGroups: - "" resources: - persistentvolumeclaims verbs: - get - list - create - delete - patch - update - apiGroups: - policy resources: - poddisruptionbudgets verbs: - get - list - watch - create - delete - patch - update - apiGroups: - extensions resources: - ingresses verbs: - get - list - watch - create - delete - patch - update
2 番目の一連の権限には、クラスタースコープリソースに必要な権限が含まれます。
Cluster Operator のクラスタースコープリソースのある ClusterRole
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-cluster-operator-global labels: app: strimzi rules: - apiGroups: - rbac.authorization.k8s.io resources: - clusterrolebindings verbs: - get - create - delete - patch - update - watch - apiGroups: - storage.k8s.io resources: - storageclasses verbs: - get - apiGroups: - "" resources: - nodes verbs: - list
strimzi-kafka-broker
ClusterRole
は、ラック機能に使用される Kafka Pod の init コンテナーが必要とするアクセス権限を表します。「委譲された権限」で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole
により、OpenShift ノードへのアクセスを Kafka ブローカー Pod に委譲できます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-kafka-broker labels: app: strimzi rules: - apiGroups: - "" resources: - nodes verbs: - get
strimzi-topic-operator
の ClusterRole
は、Topic Operator が必要とするアクセスを表します。「委譲された権限」で説明したように、このアクセスを委譲できるようにするには、このロールも Cluster Operator に必要です。
Cluster Operator の ClusterRole
により、イベントへのアクセスを Topic Operator に委譲できます。
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: strimzi-entity-operator labels: app: strimzi rules: - apiGroups: - kafka.strimzi.io resources: - kafkatopics - kafkatopics/status verbs: - get - list - watch - create - patch - update - delete - apiGroups: - "" resources: - events verbs: - create - apiGroups: - kafka.strimzi.io resources: - kafkausers - kafkausers/status verbs: - get - list - watch - create - patch - update - delete - apiGroups: - "" resources: - secrets verbs: - get - list - create - patch - update - delete
4.1.8.5. ClusterRoleBindings
Operator には ClusterRoleBindings
と、ClusterRole
をServiceAccount
に関連付ける RoleBindings
が必要です。ClusterRoleBindings
は、クラスタースコープリロースが含まれる ClusterRoles
に必要です。
Cluster Operator の ClusterRoleBinding
の例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-global apiGroup: rbac.authorization.k8s.io
ClusterRoleBindings
は、委譲に必要な ClusterRoles
にも必要です。
Cluster Operator の RoleBinding
の例
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: strimzi-cluster-operator-kafka-broker-delegation labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-kafka-broker apiGroup: rbac.authorization.k8s.io
namespaced リソースのみが含まれる ClusterRoles
は、RoleBindings
のみを使用してバインドされます。
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-cluster-operator-namespaced apiGroup: rbac.authorization.k8s.io
apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: strimzi-cluster-operator-entity-operator-delegation labels: app: strimzi subjects: - kind: ServiceAccount name: strimzi-cluster-operator namespace: myproject roleRef: kind: ClusterRole name: strimzi-entity-operator apiGroup: rbac.authorization.k8s.io
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
リソースの名前から派生) を定義するラベルが含まれています。
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaTopic metadata: name: my-topic labels: strimzi.io/cluster: my-cluster
ラベルは、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 が設定されます。apiVersion: kafka.strimzi.io/v1beta1 kind: Kafka metadata: name: my-cluster spec: #... entityOperator: topicOperator: {} userOperator: {}
-
「
EntityTopicOperatorSpec
スキーマ参照」 で説明されたプロパティーを使用して、Topic Operator を設定します。 OpenShift で Kafka リソースを作成または更新します。
oc apply
を使用します。oc apply -f your-file
その他のリソース
- 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
Kafka
リソースのspec.entityOperator.topicOperator.resources
プロパティーで、Topic Operator のリソース要求および制限を設定します。apiVersion: kafka.strimzi.io/v1beta1 kind: Kafka spec: # kafka and zookeeper sections... entityOperator: topicOperator: resources: request: cpu: "1" memory: 500Mi limit: cpu: "1" memory: 500Mi
新しい設定を適用してリソースを作成または更新します。
oc apply
を使用します。oc apply -f kafka.yaml
その他のリソース
-
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
Topic Operator が正常にデプロイされていることを確認します。
oc describe
を使用してこれを行うことができます。oc describe deployment strimzi-topic-operator
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
リソースの名前から派生) を定義するラベルが含まれています。
apiVersion: kafka.strimzi.io/v1beta1 kind: KafkaUser metadata: name: my-user labels: strimzi.io/cluster: my-cluster
このラベルは、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
その他のリソース
- 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
Kafka
リソースのspec.entityOperator.userOperator.resources
プロパティーで、User Operator のリソース要求および制限を設定します。apiVersion: kafka.strimzi.io/v1beta1 kind: Kafka spec: # kafka and zookeeper sections... entityOperator: userOperator: resources: request: cpu: "1" memory: 500Mi limit: cpu: "1" memory: 500Mi
ファイルを保存し、エディターを終了します。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
User Operator が正常にデプロイされていることを確認します。
oc describe
を使用してこれを行うことができます。oc describe deployment strimzi-user-operator
Replicas:
エントリーに1 available
が表示されれば、User Operator はデプロイされています。注記OpenShift への接続が低速な場合やイメージが事前にダウンロードされていない場合は、表示に時間がかかることがあります。
その他のリソース
- Cluster Operator を使用して User Operator をデプロイする方法についての詳細は、「Cluster Operator を使用した User Operator のデプロイ」 を参照してください。