절차

1. AMQ Streams 설치 파일을 편집하여 Cluster Operator가 설치될 네임스페이스를 사용합니다.

   예를 들어 이 절차에서는 Cluster Operator가 my-cluster-operator-namespace 네임스페이스에 설치됩니다.

   Linux에서 다음을 사용합니다.

   sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   MacOS에서 다음을 사용합니다.

   sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

2. Cluster Operator를 배포합니다.

   oc create -f install/cluster-operator -n my-cluster-operator-namespace

3. 배포 상태를 확인합니다.

   oc get deployments -n my-cluster-operator-namespace

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                      READY  UP-TO-DATE  AVAILABLE
   strimzi-cluster-operator  1/1    1           1

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. AMQ Streams 설치 파일을 편집하여 Cluster Operator가 설치될 네임스페이스를 사용합니다.

   예를 들어 이 절차에서는 Cluster Operator가 my-cluster-operator-namespace 네임스페이스에 설치됩니다.

   Linux에서 다음을 사용합니다.

   sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   MacOS에서 다음을 사용합니다.

   sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

2. install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml 파일을 편집하여 Cluster Operator가 STRIMZI_NAMESPACE 환경 변수를 조사하는 모든 네임스페이스 목록을 추가합니다.

   예를 들어, 이 절차에서 Cluster Operator는 watched-namespace-1 네임스페이스,watched-namespace-2,watched-namespace-3 을 확인합니다.

   apiVersion: apps/v1
   kind: Deployment
   spec:
     # ...
     template:
       spec:
         serviceAccountName: strimzi-cluster-operator
         containers:
         - name: strimzi-cluster-operator
           image: registry.redhat.io/amq7/amq-streams-rhel8-operator:2.3.0
           imagePullPolicy: IfNotPresent
           env:
           - name: STRIMZI_NAMESPACE
             value: watched-namespace-1,watched-namespace-2,watched-namespace-3

3. 나열된 각 네임스페이스에 대해 RoleBindings 를 설치합니다.

   이 예제에서는 이 명령에서 watched-namespace 를 이전 단계에 나열된 네임스페이스로 교체하고 watched-namespace-1,watched-namespace-2,watched-namespace-3 에 대해 반복합니다.

   oc create -f install/cluster-operator/020-RoleBinding-strimzi-cluster-operator.yaml -n <watched_namespace>
   oc create -f install/cluster-operator/023-RoleBinding-strimzi-cluster-operator.yaml -n <watched_namespace>
   oc create -f install/cluster-operator/031-RoleBinding-strimzi-cluster-operator-entity-operator-delegation.yaml -n <watched_namespace>

4. Cluster Operator를 배포합니다.

   oc create -f install/cluster-operator -n my-cluster-operator-namespace

5. 배포 상태를 확인합니다.

   oc get deployments -n my-cluster-operator-namespace

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                      READY  UP-TO-DATE  AVAILABLE
   strimzi-cluster-operator  1/1    1           1

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. AMQ Streams 설치 파일을 편집하여 Cluster Operator가 설치될 네임스페이스를 사용합니다.

   예를 들어 이 절차에서는 Cluster Operator가 my-cluster-operator-namespace 네임스페이스에 설치됩니다.

   Linux에서 다음을 사용합니다.

   sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   MacOS에서 다음을 사용합니다.

   sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

2. install/cluster-operator/060-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-rhel8-operator:2.3.0
           imagePullPolicy: IfNotPresent
           env:
           - name: STRIMZI_NAMESPACE
             value: "*"
           # ...

3. 모든 네임스페이스에 대한 클러스터 전체 액세스 권한을 Cluster Operator에 부여하는 ClusterRoleBindings 를 생성합니다.

   oc create clusterrolebinding strimzi-cluster-operator-namespaced --clusterrole=strimzi-cluster-operator-namespaced --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
   oc create clusterrolebinding strimzi-cluster-operator-watched --clusterrole=strimzi-cluster-operator-watched --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator
   oc create clusterrolebinding strimzi-cluster-operator-entity-operator-delegation --clusterrole=strimzi-entity-operator --serviceaccount my-cluster-operator-namespace:strimzi-cluster-operator

4. OpenShift 클러스터에 Cluster Operator를 배포합니다.

   oc create -f install/cluster-operator -n my-cluster-operator-namespace

5. 배포 상태를 확인합니다.

   oc get deployments -n my-cluster-operator-namespace

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                      READY  UP-TO-DATE  AVAILABLE
   strimzi-cluster-operator  1/1    1           1

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. 임시 또는 영구 클러스터를 생성하고 배포합니다.

   • 임시 클러스터를 생성하고 배포하려면 다음을 수행합니다.

     oc apply -f examples/kafka/kafka-ephemeral.yaml

   • 영구 클러스터를 생성하고 배포하려면 다음을 수행합니다.

     oc apply -f examples/kafka/kafka-persistent.yaml

2. 배포 상태를 확인합니다.

   oc get pods -n <my_cluster_operator_namespace>

   출력에는 Pod 이름과 준비 상태가 표시됩니다.

   NAME                        READY   STATUS    RESTARTS
   my-cluster-entity-operator  3/3     Running   0
   my-cluster-kafka-0          1/1     Running   0
   my-cluster-kafka-1          1/1     Running   0
   my-cluster-kafka-2          1/1     Running   0
   my-cluster-zookeeper-0      1/1     Running   0
   my-cluster-zookeeper-1      1/1     Running   0
   my-cluster-zookeeper-2      1/1     Running   0

   my-cluster 는 Kafka 클러스터의 이름입니다.

   기본 배포를 사용하면 Entity Operator 클러스터, Kafka Pod 3개 및 3 ZooKeeper Pod를 설치합니다.

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. STATUS 가 Running 으로 표시되면 배포가 성공적으로 수행됩니다.

절차

1. topicOperator 를 포함하도록 Kafka 리소스의 entityOperator 속성을 편집합니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   metadata:
     name: my-cluster
   spec:
     #...
     entityOperator:
       topicOperator: {}
       userOperator: {}

2. EntityTopicOperatorSpec 스키마 참조에 설명된 속성을 사용하여 Topic Operator 사양 을 구성합니다.

   모든 속성이 기본값을 사용하려면 빈 오브젝트({})를 사용합니다.

3. 리소스를 생성하거나 업데이트합니다.

   oc apply -f <kafka_configuration_file>

4. 배포 상태를 확인합니다.

   oc get pods -n <my_cluster_operator_namespace>

   출력에 Pod 이름과 준비 상태가 표시됩니다.

   NAME                        READY   STATUS    RESTARTS
   my-cluster-entity-operator  3/3     Running   0
   # ...

   my-cluster 는 Kafka 클러스터의 이름입니다.

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. STATUS 가 Running 으로 표시되면 배포가 성공적으로 수행됩니다.

절차

1. userOperator 를 포함하도록 Kafka 리소스의 entityOperator 속성을 편집합니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   metadata:
     name: my-cluster
   spec:
     #...
     entityOperator:
       topicOperator: {}
       userOperator: {}

2. EntityUserOperatorSpec 스키마 참조에 설명된 속성을 사용하여 User Operator 사양 을 구성합니다.

   모든 속성이 기본값을 사용하려면 빈 오브젝트({})를 사용합니다.

3. 리소스를 생성하거나 업데이트합니다.

   oc apply -f <kafka_configuration_file>

4. 배포 상태를 확인합니다.

   oc get pods -n <my_cluster_operator_namespace>

   출력에 Pod 이름과 준비 상태가 표시됩니다.

   NAME                        READY   STATUS    RESTARTS
   my-cluster-entity-operator  3/3     Running   0
   # ...

   my-cluster 는 Kafka 클러스터의 이름입니다.

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. STATUS 가 Running 으로 표시되면 배포가 성공적으로 수행됩니다.

절차

1. OpenShift 클러스터에 Kafka Connect를 배포합니다. examples/connect/kafka-connect.yaml 파일을 사용하여 Kafka Connect를 배포합니다.

   oc apply -f examples/connect/kafka-connect.yaml

2. 배포 상태를 확인합니다.

   oc get deployments -n <my_cluster_operator_namespace>

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                        READY  UP-TO-DATE  AVAILABLE
   my-connect-cluster-connect  1/1    1           1

   my-connect-cluster 는 Kafka Connect 클러스터의 이름입니다.

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. Kafka MirrorMaker를 OpenShift 클러스터에 배포합니다.

   MirrorMaker의 경우:

   oc apply -f examples/mirror-maker/kafka-mirror-maker.yaml

   MirrorMaker 2.0의 경우:

   oc apply -f examples/mirror-maker/kafka-mirror-maker-2.yaml

2. 배포 상태를 확인합니다.

   oc get deployments -n <my_cluster_operator_namespace>

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                          READY  UP-TO-DATE  AVAILABLE
   my-mirror-maker-mirror-maker  1/1    1           1
   my-mm2-cluster-mirrormaker2   1/1    1           1

   my-mirror-maker 는 Kafka MirrorMaker 클러스터의 이름입니다. my-mm2-cluster 는 Kafka MirrorMaker 2.0 클러스터의 이름입니다.

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. OpenShift 클러스터에 Kafka 브리지를 배포합니다.

   oc apply -f examples/bridge/kafka-bridge.yaml

2. 배포 상태를 확인합니다.

   oc get deployments -n <my_cluster_operator_namespace>

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME              READY  UP-TO-DATE  AVAILABLE
   my-bridge-bridge  1/1    1           1

   my-bridge 는 Kafka 브리지 클러스터의 이름입니다.

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. OpenShift 클러스터에 있는 포드 이름을 나열합니다.

   oc get pods -o name
   
   pod/kafka-consumer
   # ...
   pod/my-bridge-bridge-7cbd55496b-nclrt

2. 포트 8080 의 Kafka 브리지 Pod에 연결합니다.

   oc port-forward pod/my-bridge-bridge-7cbd55496b-nclrt 8080:8080 &

   참고

   로컬 시스템의 8080 포트가 이미 사용 중인 경우 8008 과 같은 대체 HTTP 포트를 사용합니다.

절차

1. install/topic-operator/05-Deployment-strimzi-topic-operator.yaml 독립 실행형 배포 파일에서 env 속성을 편집합니다.

   독립 실행형 주제 Operator 배포 구성의 예

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: strimzi-topic-operator
     labels:
       app: strimzi
   spec:
     # ...
     template:
       # ...
       spec:
         # ...
         containers:
           - name: strimzi-topic-operator
             # ...
             env:
               - name: STRIMZI_NAMESPACE 1
                 valueFrom:
                   fieldRef:
                     fieldPath: metadata.namespace
               - name: STRIMZI_KAFKA_BOOTSTRAP_SERVERS 2
                 value: my-kafka-bootstrap-address:9092
               - name: STRIMZI_RESOURCE_LABELS 3
                 value: "strimzi.io/cluster=my-cluster"
               - name: STRIMZI_ZOOKEEPER_CONNECT 4
                 value: my-cluster-zookeeper-client:2181
               - name: STRIMZI_ZOOKEEPER_SESSION_TIMEOUT_MS 5
                 value: "18000"
               - name: STRIMZI_FULL_RECONCILIATION_INTERVAL_MS 6
                 value: "120000"
               - name: STRIMZI_TOPIC_METADATA_MAX_ATTEMPTS 7
                 value: "6"
               - name: STRIMZI_LOG_LEVEL 8
                 value: INFO
               - name: STRIMZI_TLS_ENABLED 9
                 value: "false"
               - name: STRIMZI_JAVA_OPTS 10
                 value: "-Xmx=512M -Xms=256M"
               - name: STRIMZI_JAVA_SYSTEM_PROPERTIES 11
                 value: "-Djavax.net.debug=verbose -DpropertyName=value"
               - name: STRIMZI_PUBLIC_CA 12
                 value: "false"
               - name: STRIMZI_TLS_AUTH_ENABLED 13
                 value: "false"
               - name: STRIMZI_SASL_ENABLED 14
                 value: "false"
               - name: STRIMZI_SASL_USERNAME 15
                 value: "admin"
               - name: STRIMZI_SASL_PASSWORD 16
                 value: "password"
               - name: STRIMZI_SASL_MECHANISM 17
                 value: "scram-sha-512"
               - name: STRIMZI_SECURITY_PROTOCOL 18
                 value: "SSL"

   1

   KafkaTopic 리소스를 조사할 Topic Operator의 OpenShift 네임스페이스입니다. Kafka 클러스터의 네임스페이스를 지정합니다.

   2

   Kafka 클러스터의 모든 브로커를 검색하고 연결하는 부트스트랩 브로커 주소의 호스트 및 포트 쌍입니다. 서버가 중단된 경우 쉼표로 구분된 목록을 사용하여 두 개 또는 세 개의 브로커 주소를 지정합니다.

   3

   Topic Operator에서 관리하는 KafkaTopic 리소스를 식별하는 레이블입니다. Kafka 클러스터의 이름이 될 필요는 없습니다. KafkaTopic 리소스에 할당된 레이블일 수 있습니다. 둘 이상의 Topic Operator를 배포하는 경우 레이블은 각각에 대해 고유해야 합니다. 즉, Operator는 동일한 리소스를 관리할 수 없습니다.

   4

   ZooKeeper 클러스터에 연결할 주소의 호스트 및 포트 쌍입니다. Kafka 클러스터가 사용 중인 것과 동일한 ZooKeeper 클러스터여야 합니다.

   5

   ZooKeeper 세션 시간 초과(밀리초)입니다. 기본값은 18000 (18초)입니다.

   6

   정기적인 조정 간격(밀리초)입니다. 기본값은 120000 (2분)입니다.

   7

   Kafka에서 주제 메타데이터를 가져오는 시도 횟수입니다. 각 시도 사이의 시간은 지수 백오프로 정의됩니다. 파티션 또는 복제본 수로 인해 주제 생성에 시간이 더 걸리면 이 값을 늘리는 것이 좋습니다. 기본값은 6 번 시도입니다.

   8

   로깅 메시지를 출력하는 수준입니다. 수준을 ERROR,WARNING,INFO,DEBUG, TRACE 로 설정할 수 있습니다.

   9

   Kafka 브로커와의 암호화된 통신에 대한 TLS 지원을 활성화합니다.

   10

   (선택 사항) Topic Operator를 실행하는 JVM에서 사용하는 Java 옵션입니다.

   11

   (선택 사항) Topic Operator에 설정된 디버깅(-D) 옵션입니다.

   12

   (선택 사항) TLS가 STRIMZI_TLS_ENABLED 를 통해 활성화되는 경우 신뢰 저장소 인증서 생성에 영향을 미칩니다. 이 환경 변수가 활성화된 경우 브로커는 TLS 인증서에 신뢰할 수 있는 공개 인증 기관을 사용해야 합니다. 기본값은 false입니다.

   13

   (선택 사항) mTLS 인증을 위한 키 저장소 인증서를 생성합니다. 이 값을 false 로 설정하면 mTLS를 사용하여 Kafka 브로커에 대한 클라이언트 인증이 비활성화됩니다. 기본값은 true입니다.

   14

   (선택 사항) Kafka 브로커에 연결할 때 클라이언트 인증에 대해 SASL 지원을 활성화합니다. 기본값은 false입니다.

   15

   (선택 사항) 클라이언트 인증을 위한 SASL 사용자 이름입니다. STRIMZI_SASL_ENABLED 를 통해 SASL이 활성화된 경우에만 필수 항목입니다.

   16

   (선택 사항) 클라이언트 인증을 위한 SASL 암호입니다. STRIMZI_SASL_ENABLED 를 통해 SASL이 활성화된 경우에만 필수 항목입니다.

   17

   (선택 사항) 클라이언트 인증을 위한 SASL 메커니즘입니다. STRIMZI_SASL_ENABLED 를 통해 SASL이 활성화된 경우에만 필수 항목입니다. 값을 plain,scram-sha-256 또는 scram-sha-512 로 설정할 수 있습니다.

   18

   (선택 사항) Kafka 브로커와의 통신에 사용되는 보안 프로토콜입니다. 기본값은 "PLAINTEXT"입니다. 이 값을 PLAINTEXT,SSL,SASL_PLAINTEXT, SASL_SSL 로 설정할 수 있습니다.

2. 공개 인증 기관의 인증서를 사용하는 Kafka 브로커에 연결하려면 STRIMZI_ECDHELIC_CA 를 true 로 설정합니다. 이 속성을 true 로 설정합니다(예: Amazon AWS MSK 서비스를 사용하는 경우).

3. STRIMZI_TLS_ENABLED 환경 변수를 사용하여 mTLS를 활성화하면 Kafka 클러스터에 대한 연결을 인증하는 데 사용되는 키 저장소 및 신뢰 저장소를 지정합니다.

   mTLS 구성의 예

   # ....
   env:
     - name: STRIMZI_TRUSTSTORE_LOCATION 1
       value: "/path/to/truststore.p12"
     - name: STRIMZI_TRUSTSTORE_PASSWORD 2
       value: "TRUSTSTORE-PASSWORD"
     - name: STRIMZI_KEYSTORE_LOCATION 3
       value: "/path/to/keystore.p12"
     - name: STRIMZI_KEYSTORE_PASSWORD 4
       value: "KEYSTORE-PASSWORD"
   # ...

   1

   신뢰 저장소에는 Kafka 및 ZooKeeper 서버 인증서에 서명하는 데 사용되는 인증 기관의 공개 키가 포함되어 있습니다.

   2

   신뢰 저장소에 액세스하기 위한 암호입니다.

   3

   키 저장소에는 mTLS 인증을 위한 개인 키가 포함됩니다.

   4

   키 저장소에 액세스하기 위한 암호입니다.

4. Topic Operator를 배포합니다.

   oc create -f install/topic-operator

5. 배포 상태를 확인합니다.

   oc get deployments

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                    READY  UP-TO-DATE  AVAILABLE
   strimzi-topic-operator  1/1    1           1

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. install/user-operator/05-Deployment-strimzi-user-operator.yaml 독립 실행형 배포 파일에서 다음 env 속성을 편집합니다.

   독립 실행형 User Operator 배포 구성 예

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: strimzi-user-operator
     labels:
       app: strimzi
   spec:
     # ...
     template:
       # ...
       spec:
         # ...
         containers:
           - name: strimzi-user-operator
             # ...
             env:
               - name: STRIMZI_NAMESPACE 1
                 valueFrom:
                   fieldRef:
                     fieldPath: metadata.namespace
               - name: STRIMZI_KAFKA_BOOTSTRAP_SERVERS 2
                 value: my-kafka-bootstrap-address:9092
               - name: STRIMZI_CA_CERT_NAME 3
                 value: my-cluster-clients-ca-cert
               - name: STRIMZI_CA_KEY_NAME 4
                 value: my-cluster-clients-ca
               - name: STRIMZI_LABELS 5
                 value: "strimzi.io/cluster=my-cluster"
               - name: STRIMZI_FULL_RECONCILIATION_INTERVAL_MS 6
                 value: "120000"
               - name: STRIMZI_WORK_QUEUE_SIZE 7
                 value: 10000
               - name: STRIMZI_CONTROLLER_THREAD_POOL_SIZE 8
                 value: 10
               - name: STRIMZI_LOG_LEVEL 9
                 value: INFO
               - name: STRIMZI_GC_LOG_ENABLED 10
                 value: "true"
               - name: STRIMZI_CA_VALIDITY 11
                 value: "365"
               - name: STRIMZI_CA_RENEWAL 12
                 value: "30"
               - name: STRIMZI_JAVA_OPTS 13
                 value: "-Xmx=512M -Xms=256M"
               - name: STRIMZI_JAVA_SYSTEM_PROPERTIES 14
                 value: "-Djavax.net.debug=verbose -DpropertyName=value"
               - name: STRIMZI_SECRET_PREFIX 15
                 value: "kafka-"
               - name: STRIMZI_ACLS_ADMIN_API_SUPPORTED 16
                 value: "true"
               - name: STRIMZI_MAINTENANCE_TIME_WINDOWS 17
                 value: '* * 8-10 * * ?;* * 14-15 * * ?'
               - name: STRIMZI_KAFKA_ADMIN_CLIENT_CONFIGURATION 18
                 value: |
                   default.api.timeout.ms=120000
                   request.timeout.ms=60000

   1

   KafkaUser 리소스를 조사할 User Operator의 OpenShift 네임스페이스입니다. 하나의 네임스페이스만 지정할 수 있습니다.

   2

   Kafka 클러스터의 모든 브로커를 검색하고 연결하는 부트스트랩 브로커 주소의 호스트 및 포트 쌍입니다. 서버가 중단된 경우 쉼표로 구분된 목록을 사용하여 두 개 또는 세 개의 브로커 주소를 지정합니다.

   3

   mTLS 인증을 위해 새 사용자 인증서에 서명하는 인증 기관의 공개 키(ca.crt) 값이 포함된 OpenShift Secret

   4

   mTLS 인증을 위해 새 사용자 인증서에 서명하는 인증 기관의 개인 키(ca.key) 값이 포함된 OpenShift Secret.

   5

   User Operator가 관리하는 KafkaUser 리소스를 식별하는 레이블입니다. Kafka 클러스터의 이름이 될 필요는 없습니다. KafkaUser 리소스에 할당된 레이블일 수 있습니다. 둘 이상의 User Operator를 배포하는 경우 레이블은 각각에 대해 고유해야 합니다. 즉, Operator는 동일한 리소스를 관리할 수 없습니다.

   6

   정기적인 조정 간격(밀리초)입니다. 기본값은 120000 (2분)입니다.

   7

   컨트롤러 이벤트 큐의 크기입니다. 대기열 크기는 User Operator가 작동할 것으로 예상되는 최대 사용자 수만큼 커야 합니다. 기본값은 1024 입니다.

   8

   사용자 조정을 위한 작업자 풀의 크기입니다. 더 큰 풀에는 더 많은 리소스가 필요할 수 있지만 더 많은 KafkaUser 리소스를 처리할 수도 있습니다. 기본값은 50 입니다.

   9

   로깅 메시지를 출력하는 수준입니다. 수준을 ERROR,WARNING,INFO,DEBUG, TRACE 로 설정할 수 있습니다.

   10

   가비지 컬렉션(GC) 로깅을 활성화합니다. 기본값은 true입니다.

   11

   인증 기관의 유효 기간입니다. 기본값은 365 일입니다.

   12

   인증 기관의 갱신 기간입니다. 갱신 기간은 현재 인증서의 만료 날짜에서 역으로 측정됩니다. 기본값은 이전 인증서가 만료되기 전에 인증서 갱신을 시작하는 30 일입니다.

   13

   (선택 사항) User Operator를 실행하는 JVM에서 사용하는 Java 옵션입니다.

   14

   (선택 사항) User Operator에 설정된 디버깅(-D) 옵션

   15

   (선택 사항) User Operator가 생성한 OpenShift 시크릿의 이름에 대한 접두사입니다.

   16

   (선택 사항) Kafka 클러스터가 Kafka Admin API를 사용하여 권한 부여 ACL 규칙 관리를 지원하는지 여부를 나타냅니다. false 로 설정하면 User Operator는 간단한 권한 부여 ACL 규칙이 있는 모든 리소스를 거부합니다. 이는 Kafka 클러스터 로그에서 불필요한 예외를 방지하는 데 도움이 됩니다. 기본값은 true입니다.

   17

   (선택 사항) 만료 사용자 인증서가 갱신되는 동안 유지 관리 시간 창을 정의하는 Cron 표현식의 반 연속으로 구분된 목록입니다.

   18

   (선택 사항) User Operator가 속성 형식으로 사용하는 Kafka 관리자 클라이언트를 구성하기 위한 구성 옵션입니다.

2. Kafka 클러스터에 연결하는 데 mTLS를 사용하는 경우 연결을 인증하는 데 사용되는 시크릿을 지정합니다. 그렇지 않으면 다음 단계로 이동합니다.

   mTLS 구성의 예

   # ....
   env:
     - name: STRIMZI_CLUSTER_CA_CERT_SECRET_NAME 1
       value: my-cluster-cluster-ca-cert
     - name: STRIMZI_EO_KEY_SECRET_NAME 2
       value: my-cluster-entity-operator-certs
   # ..."

   1

   Kafka 브로커 인증서에 서명하는 CA의 공개 키(ca.crt) 값이 포함된 OpenShift Secret 입니다.

   2

   Kafka 클러스터에 대한 mTLS 인증에 대한 개인 키 및 인증서가 있는 키 저장소(entity-operator.p12)를 포함하는 OpenShift Secret 입니다. 시크릿에 는 키 저장소에 액세스하기 위한 암호(entity-operator.password)도 포함되어야 합니다.

3. User Operator를 배포합니다.

   oc create -f install/user-operator

4. 배포 상태를 확인합니다.

   oc get deployments

   출력에 배포 이름과 준비 상태가 표시됩니다.

   NAME                   READY  UP-TO-DATE  AVAILABLE
   strimzi-user-operator  1/1    1           1

   READY 에는 준비되거나 예상된 복제본 수가 표시됩니다. AVAILABLE 출력에 1 이 표시되면 배포가 성공적으로 수행됩니다.

절차

1. 사용자 정의 프로젝트에 대한 모니터링이 활성화되어 있는지 확인합니다.

   oc get pods -n openshift-user-workload-monitoring

   활성화된 경우 모니터링 구성 요소의 Pod가 반환됩니다. 예를 들면 다음과 같습니다.

   NAME                                   READY   STATUS    RESTARTS   AGE
   prometheus-operator-5cc59f9bc6-kgcq8   1/1     Running   0          25s
   prometheus-user-workload-0             5/5     Running   1          14s
   prometheus-user-workload-1             5/5     Running   1          14s
   thanos-ruler-user-workload-0           3/3     Running   0          14s
   thanos-ruler-user-workload-1           3/3     Running   0          14s

   Pod가 반환되지 않으면 사용자 정의 프로젝트에 대한 모니터링이 비활성화됩니다. 8.5절. “OpenShift에서 Kafka 메트릭 및 대시보드 보기” 의 사전 요구 사항을 참조하십시오.

2. 여러 PodMonitor 리소스는 examples/metrics/prometheus-install/strimzi-pod-monitor.yaml 에 정의됩니다.

   각 PodMonitor 리소스에 대해 spec.namespaceSelector.matchNames 속성을 편집합니다.

   apiVersion: monitoring.coreos.com/v1
   kind: PodMonitor
   metadata:
     name: cluster-operator-metrics
     labels:
       app: strimzi
   spec:
     selector:
       matchLabels:
         strimzi.io/kind: cluster-operator
     namespaceSelector:
       matchNames:
         - <project-name> 1
     podMetricsEndpoints:
     - path: /metrics
       port: http
   # ...

   1

   Kafka 와 같이 메트릭을 스크랩할 Pod가 실행 중인 프로젝트입니다.

3. Kafka 클러스터가 실행 중인 프로젝트에 strimzi-pod-monitor.yaml 파일을 배포합니다.

   oc apply -f strimzi-pod-monitor.yaml -n MY-PROJECT

4. 동일한 프로젝트에 예제 Prometheus 규칙을 배포합니다.

   oc apply -f prometheus-rules.yaml -n MY-PROJECT

절차

1. Grafana의 ServiceAccount 를 생성합니다. 여기에서 리소스의 이름은 grafana-serviceaccount 입니다.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: grafana-serviceaccount
     labels:
       app: strimzi

2. Kafka 클러스터가 포함된 프로젝트에 ServiceAccount 를 배포합니다.

   oc apply -f GRAFANA-SERVICEACCOUNT -n MY-PROJECT

3. cluster-monitoring-view 역할을 Grafana ServiceAccount 에 할당하는 ClusterRoleBinding 리소스를 생성합니다. 여기에서 리소스의 이름은 grafana-cluster-monitoring-binding 입니다.

   apiVersion: rbac.authorization.k8s.io/v1
   kind: ClusterRoleBinding
   metadata:
     name: grafana-cluster-monitoring-binding
     labels:
       app: strimzi
   subjects:
     - kind: ServiceAccount
       name: grafana-serviceaccount
       namespace: <my-project> 1
   roleRef:
     kind: ClusterRole
     name: cluster-monitoring-view
     apiGroup: rbac.authorization.k8s.io

   1

   프로젝트 이름입니다.

4. Kafka 클러스터가 포함된 프로젝트에 ClusterRoleBinding 을 배포합니다.

   oc apply -f <grafana-cluster-monitoring-binding> -n <my-project>

절차

1. Grafana ServiceAccount 의 액세스 토큰을 가져옵니다.

   oc serviceaccounts get-token grafana-serviceaccount -n MY-PROJECT

   다음 단계에서 사용할 액세스 토큰을 복사합니다.

2. Grafana에 대한 Thanos Querier 구성이 포함된 datasource.yaml 파일을 생성합니다.

   표시된 대로 액세스 토큰을 httpHeaderValue1 속성에 붙여넣습니다.

   apiVersion: 1
   
   datasources:
   - name: Prometheus
     type: prometheus
     url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
     access: proxy
     basicAuth: false
     withCredentials: false
     isDefault: true
     jsonData:
       timeInterval: 5s
       tlsSkipVerify: true
       httpHeaderName1: "Authorization"
     secureJsonData:
       httpHeaderValue1: "Bearer ${GRAFANA-ACCESS-TOKEN}" 1
     editable: true

   1

   GRAFANA-ACCESS-TOKEN: Grafana ServiceAccount 에 대한 액세스 토큰의 값입니다.

3. datasource.yaml 파일에서 grafana-config 라는 구성 맵을 생성합니다.

   oc create configmap grafana-config --from-file=datasource.yaml -n MY-PROJECT

4. 배포 및 서비스로 구성된 Grafana 애플리케이션을 생성합니다.

   grafana-config 구성 맵은 데이터 소스 구성을 위한 볼륨으로 마운트됩니다.

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: grafana
     labels:
       app: strimzi
   spec:
     replicas: 1
     selector:
       matchLabels:
         name: grafana
     template:
       metadata:
         labels:
           name: grafana
       spec:
         serviceAccountName: grafana-serviceaccount
         containers:
         - name: grafana
           image: grafana/grafana:9.3.1
           ports:
           - name: grafana
             containerPort: 3000
             protocol: TCP
           volumeMounts:
           - name: grafana-data
             mountPath: /var/lib/grafana
           - name: grafana-logs
             mountPath: /var/log/grafana
           - name: grafana-config
             mountPath: /etc/grafana/provisioning/datasources/datasource.yaml
             readOnly: true
             subPath: datasource.yaml
           readinessProbe:
             httpGet:
               path: /api/health
               port: 3000
             initialDelaySeconds: 5
             periodSeconds: 10
           livenessProbe:
             httpGet:
               path: /api/health
               port: 3000
             initialDelaySeconds: 15
             periodSeconds: 20
         volumes:
         - name: grafana-data
           emptyDir: {}
         - name: grafana-logs
           emptyDir: {}
         - name: grafana-config
           configMap:
             name: grafana-config
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: grafana
     labels:
       app: strimzi
   spec:
     ports:
     - name: grafana
       port: 3000
       targetPort: 3000
       protocol: TCP
     selector:
       name: grafana
     type: ClusterIP

5. Kafka 클러스터가 포함된 프로젝트에 Grafana 애플리케이션을 배포합니다.

   oc apply -f <grafana-application> -n <my-project>

절차

1. Grafana 서비스에 대한 경로 세부 정보를 가져옵니다. 예를 들면 다음과 같습니다.

   oc get routes
   
   NAME               HOST/PORT                         PATH  SERVICES
   MY-GRAFANA-ROUTE   MY-GRAFANA-ROUTE-amq-streams.net        grafana

2. 웹 브라우저에서 경로 호스트 및 포트의 URL을 사용하여 Grafana 로그인 화면에 액세스합니다.

3. 사용자 이름과 암호를 입력한 다음 로그인을 클릭합니다.

   기본 Grafana 사용자 이름과 암호는 모두 admin 입니다. 처음 로그인하면 암호를 변경할 수 있습니다.

4. 구성 > 데이터 소스에서 Prometheus 데이터 소스가 생성되었는지 확인합니다. 데이터 소스는 8.5.5절. “Prometheus 데이터 소스를 사용하여 Grafana 배포” 에서 생성되었습니다.
5. + 아이콘을 클릭한 다음 가져오기 를 클릭합니다.
6. examples/metrics/grafana-dashboards 에서 가져올 대시보드의 JSON을 복사합니다.
7. JSON을 텍스트 상자에 붙여넣고 Load 를 클릭합니다.
8. Grafana 대시보드 예제에 대해 5-7단계를 반복합니다.

1. spec.template 속성에서 tracer 서비스를 구성합니다.

   • 추적 환경 변수를 템플릿 구성 속성으로 사용합니다.
   • OpenTelemetry의 경우 spec.tracing.type 속성을 opentelemetry 로 설정합니다.
   • OpenTracing의 경우 spec.tracing.type 속성을 jaeger 로 설정합니다.

   OpenTelemetry를 사용하는 Kafka Connect의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaConnect
   metadata:
     name: my-connect-cluster
   spec:
     #...
     template:
       connectContainer:
         env:
           - name: OTEL_SERVICE_NAME
             value: my-otel-service
           - name: OTEL_EXPORTER_JAEGER_ENDPOINT
             value: "http://jaeger-host:14250"
     tracing:
       type: opentelemetry
     #...

   OpenTelemetry를 사용하는 MirrorMaker의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaMirrorMaker
   metadata:
     name: my-mirror-maker
   spec:
     #...
     template:
       mirrorMakerContainer:
         env:
           - name: OTEL_SERVICE_NAME
             value: my-otel-service
           - name: OTEL_EXPORTER_JAEGER_ENDPOINT
             value: "http://jaeger-host:14250"
     tracing:
       type: opentelemetry
   #...

   OpenTelemetry를 사용한 MirrorMaker 2.0의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaMirrorMaker2
   metadata:
     name: my-mm2-cluster
   spec:
     #...
     template:
       connectContainer:
         env:
           - name: OTEL_SERVICE_NAME
             value: my-otel-service
           - name: OTEL_EXPORTER_JAEGER_ENDPOINT
             value: "http://jaeger-host:14250"
     tracing:
       type: opentelemetry
   #...

   OpenTelemetry를 사용하는 Kafka 브리지의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     #...
     template:
       bridgeContainer:
         env:
           - name: OTEL_SERVICE_NAME
             value: my-otel-service
           - name: OTEL_EXPORTER_JAEGER_ENDPOINT
             value: "http://jaeger-host:14250"
     tracing:
       type: opentelemetry
   #...

   OpenTracing을 사용하는 Kafka Connect의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaConnect
   metadata:
     name: my-connect-cluster
   spec:
     #...
     template:
       connectContainer:
         env:
           - name: JAEGER_SERVICE_NAME
             value: my-jaeger-service
           - name: JAEGER_AGENT_HOST
             value: jaeger-agent-name
           - name: JAEGER_AGENT_PORT
             value: "6831"
     tracing:
       type: jaeger
     #...

   OpenTracing을 사용하는 MirrorMaker의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaMirrorMaker
   metadata:
     name: my-mirror-maker
   spec:
     #...
     template:
       mirrorMakerContainer:
         env:
           - name: JAEGER_SERVICE_NAME
             value: my-jaeger-service
           - name: JAEGER_AGENT_HOST
             value: jaeger-agent-name
           - name: JAEGER_AGENT_PORT
             value: "6831"
     tracing:
       type: jaeger
   #...

   OpenTracing을 사용하는 MirrorMaker 2.0의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaMirrorMaker2
   metadata:
     name: my-mm2-cluster
   spec:
     #...
     template:
       connectContainer:
         env:
           - name: JAEGER_SERVICE_NAME
             value: my-jaeger-service
           - name: JAEGER_AGENT_HOST
             value: jaeger-agent-name
           - name: JAEGER_AGENT_PORT
             value: "6831"
     tracing:
       type: jaeger
   #...

   OpenTracing을 사용하는 Kafka 브리지의 추적 구성 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaBridge
   metadata:
     name: my-bridge
   spec:
     #...
     template:
       bridgeContainer:
         env:
           - name: JAEGER_SERVICE_NAME
             value: my-jaeger-service
           - name: JAEGER_AGENT_HOST
             value: jaeger-agent-name
           - name: JAEGER_AGENT_PORT
             value: "6831"
     tracing:
       type: jaeger
   #...

2. 리소스를 생성하거나 업데이트합니다.

   oc apply -f <resource_configuration_file>

1. 클라이언트 애플리케이션의 pom.xml 파일에 Maven 종속성을 추가합니다.

   OpenTelemetry의 종속 항목

   <dependency>
       <groupId>io.opentelemetry</groupId>
       <artifactId>opentelemetry-sdk-extension-autoconfigure</artifactId>
       <version>1.18.0-alpha</version>
   </dependency>
   <dependency>
     <groupId>io.opentelemetry.instrumentation</groupId>
     <artifactId>opentelemetry-kafka-clients-{OpenTelemetryKafkaClient}</artifactId>
     <version>1.18.0-alpha</version>
   </dependency>
   <dependency>
     <groupId>io.opentelemetry</groupId>
     <artifactId>opentelemetry-exporter-jaeger</artifactId>
     <version>1.18.0</version>
   </dependency>

   OpenTracing의 종속 항목

   <dependency>
       <groupId>io.jaegertracing</groupId>
       <artifactId>jaeger-client</artifactId>
       <version>1.3.2</version>
   </dependency>
   <dependency>
     <groupId>io.opentracing.contrib</groupId>
     <artifactId>opentracing-kafka-client</artifactId>
     <version>0.1.15</version>
   </dependency>

2. 추적 환경 변수를 사용하여 추적 프로그램의 구성을 정의합니다.

3. 환경 변수를 사용하여 초기화되는 추적기를 생성합니다.

   OpenTelemetry용 추적기 생성

   OpenTelemetry ot = GlobalOpenTelemetry.get();

   OpenTracing용 추적기 생성

   Tracer tracer = Configuration.fromEnv().getTracer();

4. 추적기를 글로벌 추적기로 등록합니다.

   GlobalTracer.register(tracer);

5. 클라이언트 사용 방법:

   • 9.3.4절. “추적을 위한 생산자 및 소비자 측정”
   • 9.3.5절. “추적을 위한 Kafka Streams 애플리케이션 조정”

절차

1. AMQ Streams Kafka 이미지의 /opt/kafka/libs/ 디렉터리에 추적 아티팩트를 추가합니다.

   Red Hat Ecosystem Catalog 에서 Kafka 컨테이너 이미지를 기본 이미지로 사용하여 새 사용자 지정 이미지를 생성할 수 있습니다.

   Zipkin에 대한 OpenTelemetry 아티팩트

   io.opentelemetry:opentelemetry-exporter-zipkin

2. 새 추적 구현에 대한 추적 내보내기 및 끝점을 설정합니다.

   Zikpin tracer 구성의 예

   apiVersion: kafka.strimzi.io/v1beta2
   kind: KafkaMirrorMaker2
   metadata:
     name: my-mm2-cluster
   spec:
     #...
     template:
       connectContainer:
         env:
           - name: OTEL_SERVICE_NAME
             value: my-zipkin-service
           - name: OTEL_EXPORTER_ZIPKIN_ENDPOINT
             value: http://zipkin-exporter-host-name:9411/api/v2/spans 1
           - name: OTEL_TRACES_EXPORTER
             value: zipkin 2
     tracing:
       type: opentelemetry
   #...

   1

   연결할 Zipkin 끝점을 지정합니다.

   2

   Zipkin 내보내기입니다.

1. 표준 시퀀스에 따라 AMQ Streams를 버전 1.7으로 업그레이드합니다.
2. AMQ Streams 1.8과 함께 제공되는 Red Hat AMQ Streams API 변환 툴을 사용하여 AMQ Streams 사용자 정의 리소스를 v1beta2 로 변환합니다.

3. 다음 중 하나를 수행합니다.

   • AMQ Streams 1.8로 업그레이드( ControlPlaneListener 기능 게이트가 기본적으로 비활성화되어 있는 경우)
   • ControlPlaneListener 기능 게이트가 비활성화되어 있는 AMQ Streams 2.0 또는 2.2( ControlPlaneListener 기능 게이트가 기본적으로 활성화되어 있는 위치)로 업그레이드
4. ControlPlaneListener 기능 게이트를 활성화합니다.
5. 표준 시퀀스에 따라 AMQ Streams 2.3으로 업그레이드합니다.

1. AMQ Streams 1.7로 업그레이드
2. AMQ Streams 1.8과 함께 제공되는 Red Hat AMQ Streams API 변환 툴 을 다운로드합니다.

3. 사용자 정의 리소스 및 CRD를 v1beta2 로 변환합니다.

   자세한 내용은 AMQ Streams 1.7 업그레이드 설명서를 참조하십시오.

4. OperatorHub에서 Red Hat Integration - AMQ Streams Operator 의 1.7 버전을 삭제합니다.

5. 또한 Red Hat Integration - AMQ Streams Operator 의 2.3 버전을 삭제합니다.

   존재하지 않는 경우 다음 단계로 이동합니다.

   AMQ Streams Operator에 대한 승인 전략이 자동으로 설정된 경우 Operator의 2.3 버전이 클러스터에 이미 있을 수 있습니다. 사용자 정의 리소스 및 CRD를 릴리스 전에 v1beta2 API 버전으로 변환 하지 않은 경우 Operator에서 관리하는 사용자 정의 리소스 및 CRD는 이전 API 버전을 사용합니다. 결과적으로 2.3 Operator가 Pending 상태로 설정되어 있습니다. 이 경우 Red Hat Integration - AMQ Streams Operator 버전 및 1.7 버전을 삭제해야 합니다.

   두 Operator를 모두 삭제하면 새 Operator 버전이 설치될 때까지 조정이 일시 중지됩니다. 사용자 정의 리소스에 대한 변경 사항이 지연되지 않도록 다음 단계를 즉시 수행합니다.

6. OperatorHub에서 다음 중 하나를 수행합니다.

   • Red Hat Integration - AMQ Streams Operator 의 버전 1.8로 업그레이드 - AMQ Streams 기능 게이트는 기본적으로 비활성화되어 있습니다.
   • Red Hat Integration - AMQ Streams Operator 의 버전 2.0 또는 2.2로 업그레이드 - AMQ Streams Operator(기본적으로 ControlPlaneListener 기능 게이트가 활성화된 경우) ControlPlaneListener 기능 게이트가 비활성화되어 있습니다.

7. Red Hat Integration - AMQ Streams Operator 버전 2.3으로 즉시 업그레이드

   설치된 2.3 Operator는 클러스터를 감시하고 롤링 업데이트를 수행합니다. 이 프로세스 중에 클러스터 성능이 일시적으로 저하될 수 있습니다.

절차

1. 기존 Cluster Operator 리소스( /install/cluster-operator 디렉터리)에 대한 구성 변경 사항을 기록해 두십시오. 새로운 Cluster Operator 버전에서 모든 변경 사항을 덮어씁니다.
2. AMQ Streams 버전 2.3에 사용할 수 있는 지원되는 구성 옵션을 반영하도록 사용자 정의 리소스를 업데이트합니다.

3. Cluster Operator를 업데이트합니다.

   1. Cluster Operator가 실행 중인 네임스페이스에 따라 새 Cluster Operator 버전의 설치 파일을 수정합니다.

      Linux에서 다음을 사용합니다.

      sed -i 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

      MacOS에서 다음을 사용합니다.

      sed -i '' 's/namespace: .*/namespace: my-cluster-operator-namespace/' install/cluster-operator/*RoleBinding*.yaml

   2. 기존 Cluster Operator Deployment 에서 하나 이상의 환경 변수를 수정한 경우 install/cluster-operator/060-Deployment-strimzi-cluster-operator.yaml 파일을 편집하여 해당 환경 변수를 사용합니다.

4. 업데이트된 구성이 있는 경우 나머지 설치 리소스와 함께 배포합니다.

   oc replace -f install/cluster-operator

   롤링 업데이트가 완료될 때까지 기다립니다.

5. 새 Operator 버전에서 업그레이드할 Kafka 버전을 더 이상 지원하지 않는 경우 Cluster Operator는 해당 버전이 지원되지 않는 경우 오류 메시지를 반환합니다. 그렇지 않으면 오류 메시지가 반환되지 않습니다.

   • 오류 메시지가 반환되면 새 Cluster Operator 버전에서 지원하는 Kafka 버전으로 업그레이드합니다.

     1. Kafka 사용자 정의 리소스를 편집합니다.
     2. spec.kafka.version 속성을 지원되는 Kafka 버전으로 변경합니다.
   • 오류 메시지가 반환되지 않으면 다음 단계로 이동합니다. 나중에 Kafka 버전을 업그레이드합니다.

6. Kafka Pod의 이미지를 가져와서 업그레이드가 성공했는지 확인합니다.

   oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'

   이미지 태그는 새 Operator 버전을 표시합니다. 예를 들면 다음과 같습니다.

   registry.redhat.io/amq7/amq-streams-kafka-33-rhel8:2.3.0

브로커 수준 소비자 첫 번째 전략

1. 모든 사용 애플리케이션을 업그레이드합니다.
2. broker-level log.message.format.version 을 새 버전으로 변경합니다.
3. 모든 생성 애플리케이션을 업그레이드합니다.

1. 모든 사용 애플리케이션을 업그레이드합니다.
2. topic-level message.format.version 을 새 버전으로 변경합니다.
3. 모든 생성 애플리케이션을 업그레이드합니다.

1. topic-level message.format.version 을 이전 버전으로 변경합니다(또는 broker-level log.message.format.version).
2. 모든 소비 및 생성 애플리케이션을 업그레이드합니다.
3. 업그레이드된 애플리케이션이 제대로 작동하는지 확인합니다.
4. topic-level message.format.version 을 새 버전으로 변경합니다.

절차

1. Kafka 클러스터 구성을 업데이트합니다.

   oc edit kafka <my_cluster>

2. 구성된 경우 inter.broker.protocol.version 및 log.message.format.version 속성이 현재 버전으로 설정되어 있는지 확인합니다.

   예를 들어 Kafka 버전 3.2.3에서 3.3.1로 업그레이드하는 경우 현재 버전은 3.2입니다.

   kind: Kafka
   spec:
     # ...
     kafka:
       version: 3.2.3
       config:
         log.message.format.version: "3.2"
         inter.broker.protocol.version: "3.2"
         # ...

   log.message.format.version 및 inter.broker.protocol.version 이 구성되지 않은 경우 AMQ Streams는 다음 단계에서 Kafka 버전으로 업데이트한 후 이러한 버전을 현재 기본값으로 자동으로 업데이트합니다.

   참고

   log.message.format.version 및 inter.broker.protocol.version 의 값은 해당 값이 부동 소수점 숫자로 해석되지 않도록 문자열이어야 합니다.

3. Kafka.spec.kafka.version 을 변경하여 새 Kafka 버전을 지정합니다. 현재 Kafka 버전의 기본값으로 log.message.format.version 및 inter.broker.protocol.version 을 그대로 둡니다.

   참고

   kafka.version 을 변경하면 클러스터의 모든 브로커가 새 브로커 바이너리를 사용하도록 업그레이드됩니다. 이 프로세스 중에 일부 브로커는 이전 바이너리를 사용하고 다른 브로커는 이미 새 바이너리로 업그레이드 중입니다. 현재 설정을 변경하지 않고 inter.broker.protocol.version 을 남겨 두면 브로커가 업그레이드 중에 서로 계속 통신할 수 있습니다.

   예를 들어 Kafka 3.2.3에서 3.3.1로 업그레이드하는 경우 다음을 수행합니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   spec:
     # ...
     kafka:
       version: 3.3.1 1
       config:
         log.message.format.version: "3.2" 2
         inter.broker.protocol.version: "3.2" 3
         # ...

   1

   Kafka 버전이 새 버전으로 변경되었습니다.

   2

   메시지 형식 버전은 변경되지 않습니다.

   3

   inter-broker 프로토콜 버전은 변경되지 않습니다.

   주의

   새 Kafka 버전의 inter.broker.protocol.version 이 변경되면 Kafka를 다운그레이드할 수 없습니다. The inter-broker protocol version determines the schemas used for persistent metadata stored by the broker, including messages written to __consumer_offsets. 다운그레이드된 클러스터는 메시지를 이해할 수 없습니다.

4. Kafka 클러스터의 이미지가 Kafka 사용자 정의 리소스인 Kafka.spec.kafka. image 에 정의된 경우 새 Kafka 버전이 있는 컨테이너 이미지를 가리키도록 이미지를 업데이트합니다.

   Kafka 버전 및 이미지 매핑참조

5. 편집기를 저장하고 종료한 다음 롤링 업데이트가 완료될 때까지 기다립니다.

   Pod 상태 전환을 확인하여 롤링 업데이트의 진행 상황을 확인합니다.

   oc get pods my-cluster-kafka-0 -o jsonpath='{.spec.containers[0].image}'

   롤링 업데이트를 통해 각 Pod가 새 Kafka 버전에 브로커 바이너리를 사용하고 있는지 확인합니다.

6. 클라이언트 업그레이드를 위한 선택한 전략에 따라 모든 클라이언트 애플리케이션을 업그레이드하여 새 버전의 클라이언트 바이너리를 사용합니다.

   필요한 경우 Kafka Connect 및 MirrorMaker의 version 속성을 Kafka의 새 버전으로 설정합니다.

   1. Kafka Connect의 경우 KafkaConnect.spec.version 을 업데이트합니다.
   2. MirrorMaker의 경우 KafkaMirrorMaker.spec.version 을 업데이트합니다.
   3. MirrorMaker 2.0의 경우 KafkaMirrorMaker2.spec.version 을 업데이트합니다.

7. 구성된 경우 새 inter.broker.protocol.version 버전을 사용하도록 Kafka 리소스를 업데이트합니다. 그렇지 않으면 9 단계로 이동합니다.

   예를 들어 Kafka 3.3.1로 업그레이드하는 경우 다음을 수행합니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   spec:
     # ...
     kafka:
       version: 3.3.1
       config:
         log.message.format.version: "3.2"
         inter.broker.protocol.version: "3.3"
         # ...

8. Cluster Operator가 클러스터를 업데이트할 때까지 기다립니다.

9. 구성된 경우 새 log.message.format.version 버전을 사용하도록 Kafka 리소스를 업데이트합니다. 그렇지 않으면 10 단계로 이동합니다.

   예를 들어 Kafka 3.3.1로 업그레이드하는 경우 다음을 수행합니다.

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   spec:
     # ...
     kafka:
       version: 3.3.1
       config:
         log.message.format.version: "3.3"
         inter.broker.protocol.version: "3.3"
         # ...

   중요

   Kafka 3.0.0에서 inter.broker.protocol.version 이 3.0 이상으로 설정되면 log.message.format.version 옵션이 무시되고 설정할 필요가 없습니다.

10. Cluster Operator가 클러스터를 업데이트할 때까지 기다립니다.

    • Kafka 클러스터 및 클라이언트는 이제 새 Kafka 버전을 사용합니다.
    • 브로커는 inter-broker 프로토콜 버전과 Kafka의 새 버전의 메시지 형식 버전을 사용하여 메시지를 전송하도록 구성됩니다.

절차

1. Kafka 클러스터 구성을 업데이트합니다.

   oc edit kafka KAFKA-CONFIGURATION-FILE

2. Kafka.spec.kafka.version 을 변경하여 이전 버전을 지정합니다.

   예를 들어 Kafka 3.3.1에서 3.2.3으로 다운그레이드하는 경우:

   apiVersion: kafka.strimzi.io/v1beta2
   kind: Kafka
   spec:
     # ...
     kafka:
       version: 3.2.3 1
       config:
         log.message.format.version: "3.2" 2
         inter.broker.protocol.version: "3.2" 3
         # ...

   1

   Kafka 버전이 이전 버전으로 변경되었습니다.

   2

   메시지 형식 버전은 변경되지 않습니다.

   3

   inter-broker 프로토콜 버전은 변경되지 않습니다.

   참고

   log.message.format.version 및 inter.broker.protocol.version 의 값은 해당 값이 부동 소수점 숫자로 해석되지 않도록 문자열이어야 합니다.

3. Kafka 버전의 이미지가 Cluster Operator의 STRIMZI_KAFKA_IMAGES 에 정의된 이미지와 다른 경우 Kafka.spec.kafka.image 를 업데이트합니다.

   참조 10.5.3절. “Kafka 버전 및 이미지 매핑”

4. 편집기를 저장하고 종료한 다음 롤링 업데이트가 완료될 때까지 기다립니다.

   로그 또는 Pod 상태 전환을 확인하여 업데이트를 확인합니다.

   oc logs -f CLUSTER-OPERATOR-POD-NAME | grep -E "Kafka version downgrade from [0-9.]+ to [0-9.]+, phase ([0-9]+) of \1 completed"

   oc get pod -w

   INFO 수준 메시지가 있는지 Cluster Operator 로그를 확인합니다.

   Reconciliation #NUM(watch) Kafka(NAMESPACE/NAME): Kafka version downgrade from FROM-VERSION to TO-VERSION, phase 1 of 1 completed

5. 이전 버전의 클라이언트 바이너리를 사용하도록 모든 클라이언트 애플리케이션(소유자)을 다운그레이드합니다.

   Kafka 클러스터 및 클라이언트는 이제 이전 Kafka 버전을 사용합니다.

6. 주제 메타데이터 스토리지에 ZooKeeper를 사용하는 1.7 이전의 AMQ Streams 버전으로 되돌리는 경우 Kafka 클러스터에서 내부 주제 저장소 주제를 삭제합니다.

   oc run kafka-admin -ti --image=registry.redhat.io/amq7/amq-streams-kafka-33-rhel8:2.3.0 --rm=true --restart=Never -- ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi-topic-operator-kstreams-topic-store-changelog --delete && ./bin/kafka-topics.sh --bootstrap-server localhost:9092 --topic __strimzi_store_topic --delete