第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 のアーキテクチャー例

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 のデプロイメント

前提条件

  • この手順では、CustomResourceDefinitionsClusterRoles、および 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 のデプロイメント

前提条件

  • この手順では、CustomResourceDefinitionsClusterRoles、および 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

手順

  1. 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
  2. Cluster Operator によって監視されるすべての namespace (上記の例では watched-namespace-1watched-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
  3. 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 でクラスターが自動的に管理されます。

前提条件

  • この手順では、CustomResourceDefinitionsClusterRoles、および ClusterRoleBindings を作成できる OpenShift ユーザーアカウントを使用する必要があります。通常、OpenShift クラスターでロールベースアクセス制御 (RBAC) を使用する場合、これらのリソースを作成、編集、および削除する権限を持つユーザーは system:admin などの OpenShift クラスター管理者に限定されます。
  • OpenShift クラスターが稼働している必要があります。

手順

  1. すべての namespace を監視するように Cluster Operator を設定します。

    1. 050-Deployment-strimzi-cluster-operator.yaml ファイルを編集します。
    2. 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: "*"
              # ...
  2. クラスター全体ですべての 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 に置き換えます。

  3. 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 です。ロギングメッセージの出力レベル。設定可能な値: ERRORWARNINGINFODEBUG、および 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。有効な値は、AlwaysIfNotPresent、および Never です。指定のない場合、OpenShift のデフォルトが使用されます。ポリシーを変更すると、すべての Kafka、Kafka Connect、および Kafka MirrorMaker クラスターのローリングアップデートが実行されます。
STRIMZI_IMAGE_PULL_SECRETS
任意設定。Secret 名のカンマ区切りのリスト。ここで参照されるシークレットには、コンテナーイメージがプルされるコンテナーレジストリーへのクレデンシャルが含まれます。シークレットは、Cluster Operator によって作成されるすべての PodsimagePullSecrets フィールドで使用されます。このリストを変更すると、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 が機能するには、KafkaKafkaConnect などのリソースや ConfigMapsPodsDeploymentsStatefulSetsServices などの管理リソースと対話するために 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 リソースのリソースをデプロイする場合、以下のように ServiceAccountsRoleBindings、および 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 イベントを生成し、ServiceAccountstrimzi-entity-operator という ClusterRole にバインドされるようにします。strimzi-entity-operator はこのアクセス権限を strimzi-entity-operator RoleBinding 経由で付与します。
  • 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 ServiceAccountserviceAccountName として指定されている 12 行目に注目してください。

4.1.8.4. ClusterRoles

Cluster Operator は、必要なリソースへのアクセス権限を付与する ClusterRoles を使用して操作する必要があります。OpenShift クラスターの設定によっては、クラスター管理者が ClusterRoles を作成する必要があることがあります。

注記

クラスター管理者の権限は ClusterRoles の作成にのみ必要です。Cluster Operator はクラスター管理者アカウントで実行されません。

ClusterRoles は、 最小権限の原則に従い、Kafka、Kafka Connect、および ZooKeeper クラスターを操作するために Cluster Operator が必要とする権限のみが含まれます。最初に割り当てられた一連の権限により、Cluster Operator で StatefulSetsDeploymentsPods、および 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-operatorClusterRole は、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 と、ClusterRoleServiceAccount に関連付ける 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

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 が実行されていないときに KafkaTopicmy-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 リソースが必要です。

手順

  1. Kafka.spec.entityOperator オブジェクトが Kafka リソースに存在することを確認します。このオブジェクトによって Entity Operator が設定されます。

    apiVersion: kafka.strimzi.io/v1beta1
    kind: Kafka
    metadata:
      name: my-cluster
    spec:
      #...
      entityOperator:
        topicOperator: {}
        userOperator: {}
  2. EntityTopicOperatorSpec スキーマ参照」 で説明されたプロパティーを使用して、Topic Operator を設定します。
  3. 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 が稼働している必要があります。

手順

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

    oc edit を使用します。

    oc edit kafka my-cluster
  2. 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
  3. 新しい設定を適用してリソースを作成または更新します。

    oc apply を使用します。

    oc apply -f kafka.yaml

その他のリソース

4.2.6. スタンドアロン Topic Operator のデプロイ

Topic Operator をスタンドアロンコンポーネントとしてデプロイすることは、Cluster Operator を使用してインストールする場合よりも複雑ですが、柔軟性があります。たとえば、Cluster Operator によってデプロイされた Kafka クラスターに限らず、どの Kafka クラスターでも動作します。

前提条件

  • Topic Operator が接続する既存の Kafka クラスターが必要です。

手順

  1. install/topic-operator/05-Deployment-strimzi-topic-operator.yaml リソースを編集します。以下を変更する必要があります。

    1. Deployment.spec.template.spec.containers[0].envSTRIMZI_KAFKA_BOOTSTRAP_SERVERS 環境変数は、hostname:‍port ペアのカンマ区切りのリストとして、Kafka クラスターのブートストラップブローカーのリストに設定する必要があります。
    2. Deployment.spec.template.spec.containers[0].envSTRIMZI_ZOOKEEPER_CONNECT 環境変数は、hostname:‍port ペアのカンマ区切りのリストとして、ZooKeeper ノードのリストに設定する必要があります。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。
    3. Deployment.spec.template.spec.containers[0].envSTRIMZI_NAMESPACE 環境変数は、Operator によって KafkaTopic リソースが監視される OpenShift namespace に設定する必要があります。
  2. Topic Operator をデプロイします。

    oc apply を使用してこれを行うことができます。

    oc apply -f install/topic-operator
  3. Topic Operator が正常にデプロイされていることを確認します。oc describe を使用してこれを行うことができます。

    oc describe deployment strimzi-topic-operator

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

    注記

    OpenShift への接続が低速な場合やイメージが事前にダウンロードされていない場合は、表示に時間がかかることがあります。

その他のリソース

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
ロギングメッセージの出力レベル。設定可能な値: ERRORWARNINGINFODEBUG、および 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 リソースが必要です。

手順

  1. Kafka リソースを編集し、希望どおりに User Operator を設定する Kafka.spec.entityOperator.userOperator オブジェクトが含まれるようにします。
  2. 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 が稼働している必要があります。

手順

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

    oc edit kafka my-cluster
  2. 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 によって変更が自動的に適用されます。

その他のリソース

4.3.5. スタンドアロン User Operator のデプロイ

User Operator をスタンドアロンコンポーネントとしてデプロイすることは、Cluster Operator を使用してインストールする場合よりも複雑ですが、柔軟性があります。たとえば、Cluster Operator によってデプロイされた Kafka クラスターのみに限らず、どの Kafka クラスターでも動作します。

前提条件

  • User Operator が接続する既存の Kafka クラスターが必要です。

手順

  1. install/user-operator/05-Deployment-strimzi-user-operator.yaml リソースを編集します。以下を変更する必要があります。

    1. Deployment.spec.template.spec.containers[0].envSTRIMZI_CA_CERT_NAME 環境変数は、TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の公開鍵が含まれる OpenShift Secret を参照するように設定する必要があります。Secretca.crt キーには、認証局の公開鍵が含まれている必要があります。
    2. Deployment.spec.template.spec.containers[0].envSTRIMZI_CA_KEY_NAME 環境変数は、TLS クライアント認証に対して新しいユーザー証明書を署名するための認証局の秘密鍵が含まれる OpenShift Secret を参照するように設定する必要があります。Secretca.key キーに、認証局の秘密鍵が含まれている必要があります。
    3. Deployment.spec.template.spec.containers[0].envSTRIMZI_ZOOKEEPER_CONNECT 環境変数は、hostname:‍port ペアのカンマ区切りのリストとして、ZooKeeper ノードのリストに設定する必要があります。これは、Kafka クラスターが使用する ZooKeeper クラスターと同じである必要があります。
    4. Deployment.spec.template.spec.containers[0].envSTRIMZI_NAMESPACE 環境変数は、Operator によって KafkaUser リソースが監視される OpenShift namespace に設定する必要があります。
  2. User Operator をデプロイします。

    oc apply を使用してこれを行うことができます。

    oc apply -f install/user-operator
  3. User Operator が正常にデプロイされていることを確認します。oc describe を使用してこれを行うことができます。

    oc describe deployment strimzi-user-operator

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

    注記

    OpenShift への接続が低速な場合やイメージが事前にダウンロードされていない場合は、表示に時間がかかることがあります。

その他のリソース