4.6. Apache Kafka에 대한 Knative 브로커 구현
프로덕션 지원 Knative Eventing 배포의 경우 Apache Kafka에 Knative 브로커 구현을 사용하는 것이 좋습니다. 브로커는 Knative 브로커의 Apache Kafka 기본 구현으로 Kafka 인스턴스에 직접 CloudEvents를 보냅니다.
Knative 브로커는 이벤트를 저장하고 라우팅하기 위해 Kafka와 기본 통합됩니다. 이를 통해 브로커 및 다른 브로커 유형에 대해 Kafka와 보다 원활하게 통합할 수 있으며 네트워크 홉을 줄일 수 있습니다. Knative 브로커 구현의 기타 이점은 다음과 같습니다.
- at-least-once delivery guarantee
- CloudEvents 파티션 확장을 기반으로 이벤트 전달 순서
- 컨트롤 플레인 고가용성
- 수평으로 확장 가능한 데이터 플레인
Apache Kafka에 대한 Knative 브로커 구현은 바이너리 콘텐츠 모드를 사용하여 들어오는 CloudEvent를 Kafka 레코드로 저장합니다. 즉, 모든 CloudEvent 속성 및 확장은 Kafka 레코드의 헤더로 매핑되고 CloudEvent의 data
사양은 Kafka 레코드의 값에 해당합니다.
4.6.1. 기본 브로커 유형으로 구성되지 않은 경우 Apache Kafka 브로커 생성
OpenShift Serverless 배포가 Kafka 브로커를 기본 브로커 유형으로 사용하도록 구성되지 않은 경우 다음 절차 중 하나를 사용하여 Kafka 기반 브로커를 생성할 수 있습니다.
4.6.1.1. YAML을 사용하여 Apache Kafka 브로커 생성
YAML 파일을 사용하여 Knative 리소스를 생성하려면 선언적 API를 사용하므로 선언적으로 애플리케이션을 재현할 수 있는 방식으로 설명할 수 있습니다. YAML을 사용하여 Kafka 브로커를 생성하려면 Broker
오브젝트를 정의하는 YAML 파일을 생성한 다음 oc apply
명령을 사용하여 적용해야 합니다.
사전 요구 사항
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
사용자 정의 리소스가 OpenShift Container Platform 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
Kafka 기반 브로커를 YAML 파일로 생성합니다.
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka 1 name: example-kafka-broker spec: config: apiVersion: v1 kind: ConfigMap name: kafka-broker-config 2 namespace: knative-eventing
Kafka 기반 브로커 YAML 파일을 적용합니다.
$ oc apply -f <filename>
4.6.1.2. 외부 관리 Kafka 주제를 사용하는 Apache Kafka 브로커 생성
Kafka 브로커를 자체 내부 주제를 생성하지 않고 사용하려면 외부에서 관리되는 Kafka 주제를 대신 사용할 수 있습니다. 이렇게 하려면 kafka.eventing.knative.dev/external.topic
주석을 사용하는 Kafka Broker
오브젝트를 생성해야 합니다.
사전 요구 사항
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
사용자 정의 리소스가 OpenShift Container Platform 클러스터에 설치되어 있습니다. - Red Hat AMQ Streams 와 같은 Kafka 인스턴스에 액세스할 수 있으며 Kafka 주제를 생성했습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
Kafka 기반 브로커를 YAML 파일로 생성합니다.
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: Kafka 1 kafka.eventing.knative.dev/external.topic: <topic_name> 2 ...
Kafka 기반 브로커 YAML 파일을 적용합니다.
$ oc apply -f <filename>
4.6.1.3. 격리된 데이터 플레인이 있는 Apache Kafka에 대한 Knative Broker 구현
격리된 데이터 플레인이 있는 Apache Kafka에 대한 Knative Broker 구현은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
Apache Kafka의 Knative Broker 구현에는 두 개의 플레인이 있습니다.
- 컨트롤 플레인
- Kubernetes API와 통신하는 컨트롤러로 구성되며, 사용자 지정 오브젝트를 감시하고, 데이터 플레인을 관리합니다.
- 데이터 플레인
-
들어오는 이벤트를 수신하고 Apache Kafka와 통신하며 이벤트를 이벤트 싱크에 보내는 구성 요소 컬렉션입니다. Apache Kafka 데이터 플레인에 대한 Knative Broker 구현은 이벤트 흐름입니다. 구현은
kafka-broker-receiver
및kafka-broker-dispatcher
배포로 구성됩니다.
Kafka
의 Broker 클래스를 구성하면 Apache Kafka용 Knative Broker 구현에서 공유 데이터 플레인을 사용합니다. 즉, knative-eventing
네임스페이스의 kafka-broker-receiver
및 kafka-broker-dispatcher
배포가 클러스터의 모든 Apache Kafka 브로커에 사용됩니다.
그러나 KafkaNamespaced
의 Broker 클래스를 구성하면 Apache Kafka 브로커 컨트롤러는 브로커가 존재하는 각 네임스페이스에 대해 새 데이터 플레인을 생성합니다. 이 데이터 플레인은 해당 네임스페이스의 모든 KafkaNamespaced
브로커에서 사용합니다. 이는 데이터 플레인 간 격리를 제공하므로 사용자 네임스페이스의 kafka-broker-receiver
및 kafka-broker-dispatcher
배포가 해당 네임스페이스의 브로커에만 사용됩니다.
이 보안 기능은 별도의 데이터 플레인을 보유함으로써 더 많은 배포를 생성하고 더 많은 리소스를 사용합니다. 이러한 격리 요구 사항이 없는 경우 Kafka
클래스가 있는 일반 브로커를 사용하십시오.
4.6.1.4. 격리된 데이터 플레인을 사용하는 Apache Kafka용 Knative 브로커 생성
격리된 데이터 플레인이 있는 Apache Kafka에 대한 Knative Broker 구현은 기술 프리뷰 기능 전용입니다. 기술 프리뷰 기능은 Red Hat 프로덕션 서비스 수준 계약(SLA)에서 지원되지 않으며 기능적으로 완전하지 않을 수 있습니다. 따라서 프로덕션 환경에서 사용하는 것은 권장하지 않습니다. 이러한 기능을 사용하면 향후 제품 기능을 조기에 이용할 수 있어 개발 과정에서 고객이 기능을 테스트하고 피드백을 제공할 수 있습니다.
Red Hat 기술 프리뷰 기능의 지원 범위에 대한 자세한 내용은 기술 프리뷰 기능 지원 범위를 참조하십시오.
KafkaNamespaced
브로커를 생성하려면 eventing.knative.dev/broker.class
주석을 KafkaNamespaced
로 설정해야 합니다.
사전 요구 사항
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
사용자 정의 리소스가 OpenShift Container Platform 클러스터에 설치되어 있습니다. - Red Hat AMQ Streams 와 같은 Apache Kafka 인스턴스에 액세스하고 Kafka 주제를 생성했습니다.
- 프로젝트를 생성하거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
YAML 파일을 사용하여 Apache Kafka 기반 브로커를 생성합니다.
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: annotations: eventing.knative.dev/broker.class: KafkaNamespaced 1 name: default namespace: my-namespace 2 spec: config: apiVersion: v1 kind: ConfigMap name: my-config 3 ...
Apache Kafka 기반 브로커 YAML 파일을 적용합니다.
$ oc apply -f <filename>
spec.config
의 ConfigMap
오브젝트는 Broker
오브젝트와 동일한 네임스페이스에 있어야 합니다.
apiVersion: v1 kind: ConfigMap metadata: name: my-config namespace: my-namespace data: ...
KafkaNamespaced
클래스를 사용하여 첫 번째 Broker
오브젝트를 생성한 후 kafka-broker-receiver
및 kafka-broker-dispatcher
배포가 네임스페이스에 생성됩니다. 결과적으로 동일한 네임스페이스에 KafkaNamespaced
클래스가 있는 모든 브로커는 동일한 데이터 플레인을 사용합니다. KafkaNamespaced
클래스가 있는 브로커가 네임스페이스에 없으면 네임스페이스의 데이터 플레인이 삭제됩니다.
4.6.2. Apache Kafka 브로커 설정 구성
구성 맵을 생성하고 Kafka Broker
오브젝트에서 이 구성 맵을 참조하여 Kafka 브로커의 복제 요소, 부트스트랩 서버 및 주제 파티션 수를 구성할 수 있습니다.
사전 요구 사항
- OpenShift Container Platform에 대한 클러스터 또는 전용 관리자 권한이 있어야 합니다.
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
CR(사용자 정의 리소스)이 OpenShift Container Platform 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다.
절차
kafka-broker-config
구성 맵을 수정하거나 다음 구성이 포함된 고유한 구성 맵을 생성합니다.apiVersion: v1 kind: ConfigMap metadata: name: <config_map_name> 1 namespace: <namespace> 2 data: default.topic.partitions: <integer> 3 default.topic.replication.factor: <integer> 4 bootstrap.servers: <list_of_servers> 5
- 1
- 구성 맵 이름입니다.
- 2
- 구성 맵이 있는 네임스페이스입니다.
- 3
- Kafka 브로커의 주제 파티션 수입니다. 이는 브로커로 이벤트를 얼마나 빠르게 전송할 수 있는지 제어합니다. 파티션 수가 많을 경우 더 많은 컴퓨팅 리소스가 필요합니다.
- 4
- 주제 메시지의 복제 요인입니다. 이는 데이터 손실을 방지합니다. 복제 요소가 증가하려면 더 큰 컴퓨팅 리소스와 더 많은 스토리지가 필요합니다.
- 5
- 쉼표로 구분된 부트스트랩 서버 목록입니다. OpenShift Container Platform 클러스터 내부 또는 외부에 있을 수 있으며 브로커가 이벤트를 수신하고 이벤트를 보내는 Kafka 클러스터 목록입니다.
중요default.topic.replication.factor
값은 클러스터의 Kafka 브로커 인스턴스 수보다 작거나 같아야 합니다. 예를 들어 Kafka 브로커가 하나만 있는 경우default.topic.replication.factor
값은"1"
을 초과해서는 안 됩니다.Kafka 브로커 구성 맵의 예
apiVersion: v1 kind: ConfigMap metadata: name: kafka-broker-config namespace: knative-eventing data: default.topic.partitions: "10" default.topic.replication.factor: "3" bootstrap.servers: "my-cluster-kafka-bootstrap.kafka:9092"
구성 맵을 적용합니다.
$ oc apply -f <config_map_filename>
Kafka
Broker
오브젝트에 대한 구성 맵을 지정합니다.Broker 오브젝트의 예
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: name: <broker_name> 1 namespace: <namespace> 2 annotations: eventing.knative.dev/broker.class: Kafka 3 spec: config: apiVersion: v1 kind: ConfigMap name: <config_map_name> 4 namespace: <namespace> 5 ...
브로커를 적용합니다.
$ oc apply -f <broker_filename>
4.6.3. Apache Kafka의 Knative 브로커 구현에 대한 보안 구성
Kafka 클러스터는 일반적으로 TLS 또는 SASL 인증 방법을 사용하여 보호됩니다. TLS 또는 SASL을 사용하여 보호되는 Red Hat AMQ Streams 클러스터에서 작동하도록 Kafka 브로커 또는 채널을 구성할 수 있습니다.
SASL과 TLS를 함께 활성화하는 것이 좋습니다.
4.6.3.1. Apache Kafka 브로커의 TLS 인증 구성
TLS( Transport Layer Security )는 Apache Kafka 클라이언트와 서버에서 Knative와 Kafka 간의 트래픽을 암호화하고 인증에 사용됩니다. TLS는 Apache Kafka에 대한 Knative 브로커 구현에 대해 지원되는 유일한 트래픽 암호화 방법입니다.
사전 요구 사항
- OpenShift Container Platform에 대한 클러스터 또는 전용 관리자 권한이 있어야 합니다.
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
CR이 OpenShift Container Platform 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
.pem
파일로 저장된 Kafka 클러스터 CA 인증서가 있어야 합니다. -
Kafka 클러스터 클라이언트 인증서와
.pem
파일로 저장된 키가 있습니다. -
OpenShift CLI(
oc
)를 설치합니다.
절차
knative-eventing
네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.$ oc create secret -n knative-eventing generic <secret_name> \ --from-literal=protocol=SSL \ --from-file=ca.crt=caroot.pem \ --from-file=user.crt=certificate.pem \ --from-file=user.key=key.pem
중요키 이름
ca.crt
,user.crt
,user.key
를 사용합니다. 이 값은 변경하지 마십시오.KnativeKafka
CR을 편집하고broker
사양에서 보안에 대한 참조를 추가합니다.apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: broker: enabled: true defaultConfig: authSecretName: <secret_name> ...
4.6.3.2. Apache Kafka 브로커의 SASL 인증 구성
SASL( Simple Authentication and Security Layer )은 Apache Kafka에서 인증을 위해 사용합니다. 클러스터에서 SASL 인증을 사용하는 경우 사용자가 Kafka 클러스터와 통신하기 위해 Knative에 인증 정보를 제공해야 합니다. 그렇지 않으면 이벤트를 생성하거나 사용할 수 없습니다.
사전 요구 사항
- OpenShift Container Platform에 대한 클러스터 또는 전용 관리자 권한이 있어야 합니다.
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
CR이 OpenShift Container Platform 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
- Kafka 클러스터의 사용자 이름 및 암호가 있습니다.
-
사용할 SASL 메커니즘을 선택했습니다(예:
PLAIN
,SCRAM-SHA-256
또는SCRAM-SHA-512
). -
TLS가 활성화된 경우 Kafka 클러스터의
ca.crt
인증서 파일도 필요합니다. -
OpenShift CLI(
oc
)를 설치합니다.
절차
knative-eventing
네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.$ oc create secret -n knative-eventing generic <secret_name> \ --from-literal=protocol=SASL_SSL \ --from-literal=sasl.mechanism=<sasl_mechanism> \ --from-file=ca.crt=caroot.pem \ --from-literal=password="SecretPassword" \ --from-literal=user="my-sasl-user"
-
키 이름
ca.crt
,password
,sasl.mechanism
을 사용합니다. 이 값은 변경하지 마십시오. 공용 CA 인증서와 함께 SASL을 사용하려면 시크릿을 생성할 때
ca.crt
인수 대신tls.enabled=true
플래그를 사용해야 합니다. 예를 들면 다음과 같습니다.$ oc create secret -n <namespace> generic <kafka_auth_secret> \ --from-literal=tls.enabled=true \ --from-literal=password="SecretPassword" \ --from-literal=saslType="SCRAM-SHA-512" \ --from-literal=user="my-sasl-user"
-
키 이름
KnativeKafka
CR을 편집하고broker
사양에서 보안에 대한 참조를 추가합니다.apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: broker: enabled: true defaultConfig: authSecretName: <secret_name> ...