12장. 사용자 정의 리소스 API 참조

replicas 속성을 사용하여 복제본을 구성합니다.

복제 유형은 리소스에 따라 다릅니다.

bootstrapServers 속성을 사용하여 부트스트랩 서버 목록을 구성합니다.

부트스트랩 서버 목록은 동일한 OpenShift 클러스터에 배포되지 않은 Kafka 클러스터를 참조할 수 있습니다. AMQ Streams에 의해 배포되지 않은 Kafka 클러스터를 참조할 수도 있습니다.

동일한 OpenShift 클러스터에서 각 목록에는 CLUSTER-NAME-kafka-bootstrap이라는 Kafka 클러스터 부트스트랩 서비스와 포트 번호가 이상적이어야 합니다. AMQ Streams에서 배포하지만 다른 OpenShift 클러스터에 배포하는 경우 목록 콘텐츠는 클러스터를 노출하는 데 사용되는 접근 방식(라우팅, 수신, 노드 포트 또는 로드 밸런서)에 따라 달라집니다.

AMQ Streams에서 관리되지 않는 Kafka 클러스터가 있는 Kafka를 사용하는 경우 지정된 클러스터의 구성에 따라 부트스트랩 서버 목록을 지정할 수 있습니다.

TLS 버전에 특정 암호화 제품군 을 사용하여 클라이언트 연결에 허용되는 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 스키마 참조를 참조하십시오.

AMQ Streams 컨테이너의 리소스를 제어하도록 리소스 요청 및 제한을 구성합니다. 메모리 및 cpu 리소스에 대한 요청 및 제한을 지정할 수 있습니다. 요청은 Kafka의 안정적인 성능을 보장하기에 충분해야 합니다.

프로덕션 환경에서 리소스를 구성하는 방법은 여러 요인에 따라 다릅니다. 예를 들어 애플리케이션은 OpenShift 클러스터에서 리소스를 공유할 수 있습니다.

Kafka의 경우 배포의 다음 측면이 필요한 리소스에 영향을 미칠 수 있습니다.

리소스 요청에 지정된 값은 예약되어 있으며 컨테이너에서 항상 사용할 수 있습니다. 리소스 제한은 지정된 컨테이너에서 사용할 수 있는 최대 리소스를 지정합니다. 요청과 제한 사이의 양은 예약되지 않으며 항상 사용 가능하지 않을 수 있습니다. 컨테이너는 사용 가능한 경우에만 리소스를 제한까지 사용할 수 있습니다. 리소스 제한은 임시이며 다시 할당할 수 있습니다.

요청 없이 제한을 설정하거나 그 반대의 경우 OpenShift는 둘 다 동일한 값을 사용합니다. 리소스에 대한 동등한 요청 및 제한을 설정하면 서비스 품질이 보장되므로 OpenShift는 제한을 초과하지 않는 한 컨테이너를 종료하지 않습니다.

하나 이상의 지원되는 리소스에 대한 리소스 요청 및 제한을 구성할 수 있습니다.

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는 예약되지 않습니다.

이미지 속성을 사용하여 구성 요소에서 사용하는 컨테이너 이미지를 구성합니다.

다른 컨테이너 레지스트리 또는 사용자 지정 이미지를 사용해야 하는 경우에만 컨테이너 이미지를 재정의하는 것이 좋습니다.

예를 들어 네트워크에서 AMQ Streams에서 사용하는 컨테이너 리포지토리에 대한 액세스를 허용하지 않는 경우 AMQ Streams 이미지를 복사하거나 소스에서 빌드할 수 있습니다. 그러나 구성된 이미지가 AMQ Streams 이미지와 호환되지 않는 경우 제대로 작동하지 않을 수 있습니다.

컨테이너 이미지의 사본도 사용자 정의하고 디버깅에 사용할 수 있습니다.

다음 리소스의 image 속성을 사용하여 구성 요소에 사용할 컨테이너 이미지를 지정할 수 있습니다.

Kafka, Kafka Connect 및 Kafka MirrorMaker의 이미지 속성 구성

Kafka, Kafka Connect 및 Kafka MirrorMaker는 여러 버전의 Kafka를 지원합니다. 각 구성 요소에는 자체 이미지가 필요합니다. 다른 Kafka 버전의 기본 이미지는 다음 환경 변수에 구성됩니다.

이러한 환경 변수에는 Kafka 버전과 해당 이미지 간의 매핑이 포함됩니다. 매핑은 image 및 version 속성과 함께 사용됩니다.

다양한 구성 요소의 이미지 및 버전은 다음 속성에서 구성할 수 있습니다.

다른 리소스에서 image 속성 구성

다른 사용자 지정 리소스의 image 속성의 경우 배포 중에 지정된 값이 사용됩니다. 이미지 속성이 없으면 Cluster Operator 구성에 지정된 이미지가 사용됩니다. 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에서 지원되는 상태 점검 프로브를 구성합니다.

상태 점검은 애플리케이션의 상태를 확인하는 정기 테스트입니다. 상태 점검 프로브가 실패하면 OpenShift는 애플리케이션이 정상이 아니며 수정하려고 시도합니다.

프로브에 대한 자세한 내용은 활성 상태 및 준비 프로브 구성 을 참조하십시오.

livenessProbe 및 readinessProbe 모두 다음 옵션을 지원합니다.

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

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

livenessProbe 및 readinessProbe 옵션에 대한 자세한 내용은 프로브 스키마 참조를 참조하십시오.

metricsConfig 속성을 사용하여 Prometheus 지표를 활성화하고 구성합니다.

metricsConfig 속성에는 Prometheus Cryostat Exporter 에 대한 추가 구성이 있는 ConfigMap에 대한 참조가 포함되어 있습니다. AMQ Streams는 Prometheus Cryostat 내보내기를 사용하여 Apache Kafka 및 Zoo Cryostat에서 지원하는 Cryostat 메트릭을 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 구성 요소는 JVM(Java Virtual Machine) 내에서 실행됩니다.

다른 플랫폼 및 아키텍처에서 성능을 최적화하려면 다음 리소스에서 jvmOptions 속성을 구성합니다.

구성에 다음 옵션을 지정할 수 있습니다.

JVM에 할당된 메모리를 더 많이 제어하도록 힙 크기를 지정합니다. 힙 크기는 컨테이너의 메모리 제한(및 요청) 을 초과하지 않고 최대한 활용해야 합니다. 힙 크기 및 다른 메모리 요구 사항은 지정된 메모리 제한에 적합해야 합니다. 구성에 힙 크기를 지정하지 않고 메모리 리소스 제한(및 요청)을 구성하는 경우 Cluster Operator는 기본 힙 크기를 자동으로 적용합니다. Cluster Operator는 메모리 리소스 구성의 백분율에 따라 기본 최대 및 최소 힙 값을 설정합니다.

다음 표에서는 기본 힙 값을 보여줍니다.

메모리 제한(및 요청)을 지정하지 않으면 JVM의 최소 힙 크기가 128M 로 설정됩니다. JVM의 최대 힙 크기는 필요에 따라 메모리를 늘릴 수 있도록 정의되지 않습니다. 이는 테스트 및 개발의 단일 노드 환경에 이상적입니다.

적절한 메모리 요청을 설정하면 다음을 방지할 수 있습니다.

이 예에서 JVM은 힙에 대해 2GiB(=2,147,483,648 바이트)를 사용합니다. 총 JVM 메모리 사용량은 최대 힙 크기보다 훨씬 클 수 있습니다.

# ...
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 에 대한 자세한 내용은 JvmOptions 스키마 참조를 참조하십시오.

또한 jvmOptions 속성을 사용하면 가비지 수집기(GC) 로깅을 활성화하고 비활성화할 수 있습니다. GC 로깅은 기본적으로 비활성화되어 있습니다. 이를 활성화하려면 다음과 같이 gcLoggingEnabled 속성을 설정합니다.

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

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