2.4. 브로커

브로커는 트리거와 함께 이벤트 소스에서 이벤트 싱크로 이벤트를 전달하는 데 사용할 수 있습니다. 이벤트는 HTTP POST 요청으로 이벤트 소스에서 브로커로 전송됩니다. 이벤트가 브로커에 진입하면 트리거를 사용하여 CloudEvent 속성에 의해 필터링되고 이벤트 싱크에 HTTP POST 요청으로 전송할 수 있습니다.

브로커 이벤트 전달 개요

2.4.1. 브로커 유형

클러스터 관리자는 클러스터에 대한 기본 브로커 구현을 설정할 수 있습니다. 브로커를 생성할 때 Broker 오브젝트에 세트 구성을 제공하지 않으면 default 브로커 구현이 사용됩니다.

2.4.1.1. 개발을 위한 기본 브로커 구현

Knative는 기본 채널 기반 브로커 구현을 제공합니다. 이 채널 기반 브로커는 개발 및 테스트 목적으로 사용될 수 있지만 프로덕션 환경에 적절한 이벤트 전달 보장은 제공하지 않습니다. 기본 브로커는 기본적으로 InMemoryChannel 채널 구현에서 지원합니다.

Kafka를 사용하여 네트워크 홉을 줄이려면 Kafka 브로커 구현을 사용합니다. KafkaChannel 채널 구현에서 지원하도록 채널 기반 브로커를 구성하지 마십시오.

2.4.1.2. 프로덕션 지원 Kafka 브로커 구현

프로덕션 지원 Knative Eventing 배포의 경우 Red Hat은 Knative Kafka 브로커 구현을 사용하는 것이 좋습니다. Kafka 브로커는 Knative 브로커의 Apache Kafka 네이티브 구현이며 Kafka 인스턴스로 CloudEvent를 직접 보냅니다.

중요

Kafka 브로커에 대해 연방 정보 처리 표준(FIPS) 모드가 비활성화되어 있습니다.

Kafka 브로커는 이벤트를 저장하고 라우팅하기 위해 Kafka와 네이티브 통합을 수행합니다. 이를 통해 브로커에 대한 Kafka와 보다 효율적으로 통합하고 다른 브로커 유형에 대해 트리거 모델을 트리거할 수 있으며 네트워크 홉을 줄일 수 있습니다. Kafka 브로커 구현의 다른 이점은 다음과 같습니다.

  • at-least-once 제공 보장
  • CloudEvents 파티셔닝 확장에 따른 이벤트 전달
  • 컨트롤 플레인 고가용성
  • 수평으로 확장 가능한 데이터 플레인

Knative Kafka 브로커는 바이너리 콘텐츠 모드를 사용하여 들어오는 CloudEvents를 Kafka 레코드로 저장합니다. 즉, CloudEvent의 data 사양이 Kafka 레코드의 값에 해당하는 반면 모든 CloudEvent 속성 및 확장이 Kafka 레코드의 헤더로 매핑됩니다.

2.4.2. 다음 단계