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

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

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

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

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

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

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

SSL 구성 및 암호화 제품군 사양을 통합하여 클라이언트 애플리케이션과 Kafka 클러스터 간의 TLS 기반 통신을 추가로 보호할 수 있습니다. 표준 TLS 구성 외에도 Kafka 브로커의 구성에서 지원되는 TLS 버전을 지정하고 암호화 제품군을 활성화할 수 있습니다. 사용하는 TLS 버전 및 암호화 제품군을 제한하려면 클라이언트에 구성을 추가할 수도 있습니다. 클라이언트의 구성은 브로커에서 활성화된 프로토콜 및 암호화 제품군만 사용해야 합니다.

암호화 제품군은 보안 연결 및 데이터 전송을 위한 보안 메커니즘 집합입니다. 예를 들어 암호화 제품군 TLS_AES_256_GCM_SHA384 는 TLS 프로토콜과 함께 사용되는 다음과 같은 메커니즘으로 구성됩니다.

이 조합은 TLS_AES_256_GCM_SHA384 암호화 제품군 사양에 캡슐화됩니다.

ssl.enabled.protocols 속성은 클러스터와 해당 클라이언트 간의 보안 통신에 사용할 수 있는 사용 가능한 TLS 버전을 지정합니다. ssl.protocol 속성은 모든 연결에 대한 기본 TLS 버전을 설정하며 활성화된 프로토콜에서 선택해야 합니다. ssl.endpoint.identification.algorithm 속성을 사용하여 호스트 이름 확인을 활성화하거나 비활성화합니다.

# ...
config:
  ssl.cipher.suites: TLS_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 

  ssl.enabled.protocols: TLSv1.3, TLSv1.2 

  ssl.protocol: TLSv1.3 

  ssl.endpoint.identification.algorithm: HTTPS 

# ...

TLS 암호화를 구성하기 위해 tls 를 설정하는 경우 trustedCertificates 속성을 사용하여 인증서가 X.509 형식으로 저장되는 키 이름으로 시크릿 목록을 제공합니다.

Kafka 클러스터의 Cluster Operator에서 생성한 보안을 사용하거나 고유한 TLS 인증서 파일을 생성한 다음 파일에서 시크릿 을 생성할 수 있습니다.

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 암호화를 활성화하지만 Java와 함께 제공되는 기본 공개 인증 기관 세트를 사용하려면 trustedCertificates 를 빈 배열로 지정할 수 있습니다.

tls:
  trustedCertificates: []

mTLS 인증 구성에 대한 자세한 내용은 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"

Topic Operator 및 User Operator에 대한 리소스 요청 및 제한은 Kafka 리소스에 설정됩니다.

리소스 요청이 OpenShift 클러스터에서 사용 가능한 리소스보다 많은 경우 Pod가 예약되지 않습니다.

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

컨테이너 이미지를 덮어쓰는 것은 다른 컨테이너 레지스트리 또는 사용자 지정된 이미지를 사용해야 하는 특별한 경우에만 권장됩니다.

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

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

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

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

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

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

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

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

다른 사용자 지정 리소스의 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:
    # ...

livenessProbe 및 readinessProbe 속성을 사용하여 AMQ Streams에서 지원되는 상태 점검 프로브를 구성합니다.

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

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

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

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

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

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

metricsConfig 속성에는 Prometheus exportser에 대한 추가 구성이 있는 ConfigMap에 대한 참조가 포함되어 있습니다. AMQ Streams는 Apache Kafka 및 ZooKeeper에서 지원하는 metrics를 Prometheus 지표로 변환하기 위해 Prometheus exporter를 사용하는 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

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 (또는 더 이상 사용되지 않는 메트릭) 속성이 리소스에 정의되지 않은 경우 Prometheus 지표가 비활성화됩니다.

Prometheus 및 Grafana 설정 및 배포에 대한 자세한 내용은 OpenShift 가이드에서 AMQ Streams 배포 및 업그레이드 에서 Kafka로 메트릭 소개 를 참조하십시오.

다음 AMQ Streams 구성 요소는 Java 가상 머신(JVM) 내에서 실행됩니다.

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

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

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

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

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

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

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

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

초기(-Xms) 및 최대(-Xmx) 힙 크기에 동일한 값을 설정하면 시작 후 JVM에서 메모리를 할당할 필요가 없습니다.

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

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

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

jvmOptions 에 대한 자세한 내용은 JvmOptions 스키마 참조 를 참조하십시오.

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

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