第13章 カスタムリソース API のリファレンス

replicas プロパティーを使用してレプリカを設定します。

レプリケーションのタイプはリソースによって異なります。

bootstrapServers プロパティーを使用してブートストラップサーバーのリストを設定します。

ブートストラップサーバーリストは、同じ OpenShift クラスターにデプロイされていない Kafka クラスターを参照できます。AMQ Streams によってデプロイされた Kafka クラスターを参照することもできます。

同じ OpenShift クラスターである場合、各リストに CLUSTER-NAME-kafka-bootstrap という名前の Kafka クラスターブートストラップサービスとポート番号が含まれる必要があります。AMQ Streams によって異なる OpenShift クラスターにデプロイされた場合、リストの内容はクラスターを公開するために使用された方法によって異なります (route、ingress、nodeport、または loadbalancer)。

AMQ Streams によって管理されない Kafka クラスターで Kafka を使用する場合は、指定のクラスターの設定に応じてブートストラップサーバーのリストを指定できます。

TLSバージョンの特定のcipher suiteを使用するクライアント接続には、3つの許可されたssl設定オプションを使用します。暗号スイートは、セキュアな接続とデータ転送のためのアルゴリズムを組み合わせます。

ssl.endpoint.identification.algorithm プロパティーを設定して、ホスト名の検証を有効または無効にすることもできます。

# ...
spec:
  config:
    ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 
    ssl.enabled.protocols: "TLSv1.2" 
    ssl.protocol: "TLSv1.2" 
    ssl.endpoint.identification.algorithm: HTTPS 
# ...

# ...
spec:
  config:
    ssl.cipher.suites: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384" 

    ssl.enabled.protocols: "TLSv1.2" 

    ssl.protocol: "TLSv1.2" 

    ssl.endpoint.identification.algorithm: HTTPS 

# ...

tls を設定して TLS 暗号化を設定する場合は、trustedCertificates プロパティーを使用して、証明書が X.509 形式で保存されるキー名にシークレットの一覧を提供します。

Kafka クラスターの Cluster Operator によって作成されるシークレットを使用するか、独自の TLS 証明書ファイルを作成してから、ファイルから Secret を作成できます。

oc create secret generic MY-SECRET \
--from-file=MY-TLS-CERTIFICATE-FILE.crt

oc create secret generic MY-SECRET \
--from-file=MY-TLS-CERTIFICATE-FILE.crt

tls:
  trustedCertificates:
    - secretName: my-cluster-cluster-cert
      certificate: ca.crt
    - secretName: my-cluster-cluster-cert
      certificate: ca2.crt

tls:
  trustedCertificates:
    - secretName: my-cluster-cluster-cert
      certificate: ca.crt
    - secretName: my-cluster-cluster-cert
      certificate: ca2.crt

複数の証明書が同じシークレットに保存されている場合は、複数回リストできます。

TLS を有効にし、Java に同梱されるデフォルトの公開認証局のセットを使用する場合は、trustedCertificates を空の配列として指定できます。

tls:
  trustedCertificates: []

tls:
  trustedCertificates: []

TLS クライアント認証の設定に関する詳細は、KafkaClientAuthenticationTls schema reference を参照してください。

AMQ Streams コンテナーのリソースを制御するために、リソース 要求 および 制限 を設定します。メモリーおよび cpu リソースの要求および制限を指定できます。要求には、Kafka の安定したパフォーマンスを確保できる十分な値が必要です。

実稼働環境でリソースを設定する方法は、さまざまな要因によって異なります。たとえば、アプリケーションは OpenShift クラスターでリソースを共有する可能性があります。

Kafka では、デプロイメントの以下の要素が、必要なリソースに影響を与える可能性があります。

リソース要求に指定の値は予約され、常にコンテナーで利用可能になります。リソース制限によって、指定のコンテナーが消費可能な最大リソースが指定されます。要求数から制限数の間は予約されず、常に利用できるとは限りません。コンテナーは、リソースが利用できる場合のみ、制限以下のリソースを使用できます。リソースの制限は一時的で、再割り当てが可能です。

要求なしに制限を設定する場合や、その逆の場合、OpenShift は両方に同じ値を使用します。OpenShift は制限を超えない限りコンテナーを強制終了しないので、リソースに対して、要求と制限を同じ数に設定すると、QoS (Quality of Service)が保証されます。

サポート対象のリソース1つまたは複数に対して、リソース要求および制限を設定できます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
    resources:
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
  entityOperator:
    #...
    topicOperator:
      #...
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    #...
    resources:
      requests:
        memory: 64Gi
        cpu: "8"
      limits:
        memory: 64Gi
        cpu: "12"
  entityOperator:
    #...
    topicOperator:
      #...
      resources:
        requests:
          memory: 512Mi
          cpu: "1"
        limits:
          memory: 512Mi
          cpu: "1"

Topic Operator および User Operator のリソース要求および制限は Kafka リソースに設定されます。

リソース要求が OpenShift クラスターで利用可能な空きリソースを超える場合、Pod はスケジュールされません。

image プロパティーを使用して、コンポーネントによって使用されるコンテナーイメージを設定します。

コンテナーイメージのオーバーライドは、別のコンテナーレジストリーやカスタマイズされたイメージを使用する必要がある特別な状況でのみ推奨されます。

たとえば、ネットワークで AMQ Streams によって使用されるコンテナーリポジトリーへのアクセスが許可されない場合、AMQ Streams イメージのコピーまたはソースからのビルドを行うことができます。しかし、設定したイメージが AMQ Streams イメージと互換性のない場合は、適切に機能しない可能性があります。

コンテナーイメージのコピーはカスタマイズでき、デバッグに使用されることもあります。

以下のリソースの image プロパティーを使用すると、コンポーネントに使用するコンテナーイメージを指定できます。

Kafka、Kafka Connect、および Kafka MirrorMaker の image プロパティーの設定

Kafka、Kafka Connect、および Kafka MirrorMaker では、複数の Kafka バージョンがサポートされます。各コンポーネントには独自のイメージが必要です。異なる Kafka バージョンのデフォルトイメージは、以下の環境変数で設定されます。

これらの環境変数には、Kafka バージョンと対応するイメージ間のマッピングが含まれます。マッピングは、image および version プロパティーとともに使用されます。

異なるコンポーネントの image および version は、以下のプロパティーで設定できます。

他のリソースでの image プロパティーの設定

他のカスタムリソースの image プロパティーでは、デプロイメント中に指定の値が使用されます。image プロパティーがない場合、Cluster Operator 設定に指定された image が使用されます。image 名が Cluster Operator 設定に定義されていない場合、デフォルト値が使用されます。

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    image: my-org/my-image:latest
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    image: my-org/my-image:latest
    # ...
  zookeeper:
    # ...

livenessProbe および readinessProbe プロパティーを使用して、AMQ Streams でサポートされる healthcheck プローブを設定します。

Healthcheck は、アプリケーションの健全性を検証する定期的なテストです。ヘルスチェックプローブが失敗すると、OpenShift によってアプリケーションが正常でないと見なされ、その修正が試行されます。

プローブの詳細は、「Configure Liveness and Readiness Probes」を参照してください。

livenessProbe および readinessProbe の両方で以下のオプションがサポートされます。

# ...
readinessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
livenessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
# ...

# ...
readinessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
livenessProbe:
  initialDelaySeconds: 15
  timeoutSeconds: 5
# ...

livenessProbe および readinessProbe のオプションに関する詳細は、「Probe スキーマ参照」を参照してください。

metricsConfig プロパティーを使用して、Prometheus メトリクスを有効化および設定します。

metricsConfig プロパティーには、Prometheus JMX Exporter の追加設定が含まれる ConfigMap への参照が含まれます。AMQ Streams では、Apache Kafka および ZooKeeper によってサポートされる JMX メトリクスを Prometheus メトリクスに変換するために、Prometheus JMX エクスポーターを使用した Prometheus メトリクスがサポートされます。

追加設定なしで Prometheus メトリクスのエクスポートを有効にするには、metricsConfig.valueFrom.configMapKeyRef.key 配下に空のファイルが含まれる ConfigMap を参照します。空のファイルを参照する場合、名前が変更されていない限り、すべてのメトリクスが公開されます。

kind: ConfigMap
apiVersion: v1
metadata:
  name: my-configmap
data:
  my-key: |
    lowercaseOutputName: true
    rules:
    # Special cases and very specific rules
    - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
      name: kafka_server_$1_$2
      type: GAUGE
      labels:
       clientId: "$3"
       topic: "$4"
       partition: "$5"
    # further configuration

kind: ConfigMap
apiVersion: v1
metadata:
  name: my-configmap
data:
  my-key: |
    lowercaseOutputName: true
    rules:
    # Special cases and very specific rules
    - pattern: kafka.server<type=(.+), name=(.+), clientId=(.+), topic=(.+), partition=(.*)><>Value
      name: kafka_server_$1_$2
      type: GAUGE
      labels:
       clientId: "$3"
       topic: "$4"
       partition: "$5"
    # further configuration

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: my-config-map
          key: my-key
    # ...
  zookeeper:
    # ...

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-cluster
spec:
  kafka:
    # ...
    metricsConfig:
      type: jmxPrometheusExporter
      valueFrom:
        configMapKeyRef:
          name: my-config-map
          key: my-key
    # ...
  zookeeper:
    # ...

有効になったメトリクスは、9404 番ポートで公開されます。

metricsConfig （または非推奨の metrics）プロパティーがリソースに定義されていない場合、Prometheus メトリクスは無効になります。

Prometheus および Grafana の設定およびデプロイに関する詳細は、『OpenShift での AMQ Streams のデプロイおよびアップグレード』の「Kafka へのメトリクスの導入」を参照してください。

以下の AMQ Streams コンポーネントは、Java 仮想マシン (JVM) 内で実行されます。

異なるプラットフォームやアーキテクチャーでパフォーマンスを最適化するには、以下のリソースに jvmOptions プロパティーを設定します。

設定では、以下のオプションを指定できます。

jvmOptions の完全なスキーマは、JvmOptions schema referenceに記載されています。

-Xmx を明示的に設定する前に、以下を考慮してください。

この例では、JVM のヒープに 2 GiB (2,147,483,648 バイト) が使用されます。メモリー使用量の合計は約 8GiB です。

# ...
jvmOptions:
  "-Xmx": "2g"
  "-Xms": "2g"
# ...

# ...
jvmOptions:
  "-Xmx": "2g"
  "-Xms": "2g"
# ...

最初のヒープサイズ (-Xms) および最大ヒープサイズ (-Xmx) に同じ値を設定すると、JVM が必要以上のヒープを割り当てて起動後にメモリーを割り当てないようにすることができます。

jvmOptions:
  "-XX":
    "UseG1GC": true
    "MaxGCPauseMillis": 20
    "InitiatingHeapOccupancyPercent": 35
    "ExplicitGCInvokesConcurrent": true

jvmOptions:
  "-XX":
    "UseG1GC": true
    "MaxGCPauseMillis": 20
    "InitiatingHeapOccupancyPercent": 35
    "ExplicitGCInvokesConcurrent": true

-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -XX:-UseParNewGC

-XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -XX:-UseParNewGC

jvmOptions:
  javaSystemProperties:
    - name: javax.net.debug
      value: ssl

jvmOptions:
  javaSystemProperties:
    - name: javax.net.debug
      value: ssl

jvmOptions プロパティーでは、ガベージコレクター(GC)のロギングを有効または無効にすることもできます。GC ロギングはデフォルトで無効になっています。これを有効にするには、以下のように gcLoggingEnabled プロパティーを設定します。

# ...
jvmOptions:
  gcLoggingEnabled: true
# ...

# ...
jvmOptions:
  gcLoggingEnabled: true
# ...