5.4. 브로커
5.4.1. 브로커
브로커는 트리거와 함께 이벤트 소스에서 이벤트 싱크로 이벤트를 전달하는 데 사용할 수 있습니다. 이벤트는 HTTP POST
요청으로 이벤트 소스에서 브로커로 전송됩니다. 이벤트가 브로커에 진입하면 트리거를 사용하여 CloudEvent 속성으로 필터링하고 이벤트 싱크에 HTTP POST
요청으로 전송할 수 있습니다.
5.4.2. 브로커 유형
클러스터 관리자는 클러스터에 대한 기본 브로커 구현을 설정할 수 있습니다. 브로커를 생성할 때 Broker
오브젝트에 세트 구성을 제공하지 않으면 default 브로커 구현이 사용됩니다.
5.4.2.1. 개발을 위한 기본 브로커 구현
Knative는 기본 채널 기반 브로커 구현을 제공합니다. 이 채널 기반 브로커는 개발 및 테스트 목적으로 사용될 수 있지만 프로덕션 환경에 적절한 이벤트 전달 보장은 제공하지 않습니다. 기본 브로커는 기본적으로 InMemoryChannel
채널 구현에서 지원합니다.
Kafka를 사용하여 네트워크 홉을 줄이려면 Kafka 브로커 구현을 사용합니다. KafkaChannel
채널 구현에서 지원하도록 채널 기반 브로커를 구성하지 마십시오.
5.4.2.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 레코드의 헤더로 매핑됩니다.
5.4.3. 브로커 생성
Knative는 기본 채널 기반 브로커 구현을 제공합니다. 이 채널 기반 브로커는 개발 및 테스트 목적으로 사용될 수 있지만 프로덕션 환경에 적절한 이벤트 전달 보장은 제공하지 않습니다.
클러스터 관리자가 Kafka를 기본 브로커 유형으로 사용하도록 OpenShift Serverless 배포를 구성한 경우 기본 설정을 사용하여 브로커를 생성하여 Kafka 기반 브로커를 생성합니다.
OpenShift Serverless 배포가 기본 브로커 유형으로 Kafka 브로커를 사용하도록 구성되지 않은 경우 다음 절차의 기본 설정을 사용할 때 채널 기반 브로커가 생성됩니다.
5.4.3.1. Knative CLI를 사용하여 브로커 생성
브로커는 트리거와 함께 이벤트 소스에서 이벤트 싱크로 이벤트를 전달하는 데 사용할 수 있습니다. Knative(kn
) CLI를 사용하여 브로커를 생성하면 YAML 파일을 직접 수정하는 것보다 더 간소화되고 직관적인 사용자 인터페이스를 제공합니다. kn broker create
명령을 사용하여 브로커를 생성할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
-
Knative(
kn
) CLI가 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
브로커를 생성합니다.
$ kn broker create <broker_name>
검증
kn
명령을 사용하여 기존 브로커를 모두 나열합니다.$ kn broker list
출력 예
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 True
선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.
5.4.3.2. 트리거에 주석을 달아 브로커 생성
브로커는 트리거와 함께 이벤트 소스에서 이벤트 싱크로 이벤트를 전달하는 데 사용할 수 있습니다. Trigger
오브젝트에 eventing.knative.dev/injection: enabled
주석을 추가하여 브로커를 생성할 수 있습니다.
eventing.knative.dev/injection: enabled
주석을 사용하여 브로커를 생성하는 경우 클러스터 관리자 권한이 없어 이 브로커를 삭제할 수 없습니다. 클러스터 관리자가 이 주석을 먼저 제거하기 전에 브로커를 삭제하면 삭제 후 브로커가 다시 생성됩니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
프로세스
eventing.knative.dev/injection: enabled
주석이 있는Trigger
오브젝트를 YAML 파일로 생성합니다.apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: annotations: eventing.knative.dev/injection: enabled name: <trigger_name> spec: broker: default subscriber: 1 ref: apiVersion: serving.knative.dev/v1 kind: Service name: <service_name>
- 1
- 트리거에서 이벤트를 전송할 대상 이벤트 싱크 또는 구독자에 대한 세부 정보를 지정합니다.
Trigger
YAML 파일을 적용합니다.$ oc apply -f <filename>
검증
oc
CLI를 사용하거나 웹 콘솔의 토폴로지 보기에서 브로커가 생성되었는지 확인할 수 있습니다.
oc
명령을 사용하여 브로커를 가져옵니다.$ oc -n <namespace> get broker default
출력 예
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56s
선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.
5.4.3.3. 네임스페이스에 라벨을 지정하여 브로커 생성
브로커는 트리거와 함께 이벤트 소스에서 이벤트 싱크로 이벤트를 전달하는 데 사용할 수 있습니다. 소유하고 있거나 쓰기 권한이 있는 네임스페이스에 라벨을 지정하여 default
브로커를 자동으로 생성할 수 있습니다.
레이블을 제거하는 경우 이 방법을 사용하여 생성된 브로커는 제거되지 않습니다. 수동으로 삭제해야 합니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
프로세스
eventing.knative.dev/injection=enabled
를 사용하여 네임스페이스에 라벨을 지정합니다.$ oc label namespace <namespace> eventing.knative.dev/injection=enabled
검증
oc
CLI를 사용하거나 웹 콘솔의 토폴로지 보기에서 브로커가 생성되었는지 확인할 수 있습니다.
oc
명령을 사용하여 브로커를 가져옵니다.$ oc -n <namespace> get broker <broker_name>
명령 예
$ oc -n default get broker default
출력 예
NAME READY REASON URL AGE default True http://broker-ingress.knative-eventing.svc.cluster.local/test/default 3m56s
선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.
5.4.3.4. 삽입을 통해 생성된 브로커 삭제
삽입을 통해 브로커를 생성하고 나중에 삭제하려는 경우 수동으로 삭제해야 합니다. 라벨 또는 주석을 제거하면 네임스페이스 라벨 또는 트리거 주석을 사용하여 생성한 브로커는 영구적으로 삭제되지 않습니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다.
절차
네임스페이스에서
eventing.knative.dev/injection=enabled
라벨을 제거합니다.$ oc label namespace <namespace> eventing.knative.dev/injection-
주석을 제거하면 Knative에서 브로커를 삭제한 후 다시 생성하지 않습니다.
선택한 네임스페이스에서 브로커를 삭제합니다.
$ oc -n <namespace> delete broker <broker_name>
검증
oc
명령을 사용하여 브로커를 가져옵니다.$ oc -n <namespace> get broker <broker_name>
명령 예
$ oc -n default get broker default
출력 예
No resources found. Error from server (NotFound): brokers.eventing.knative.dev "default" not found
5.4.3.5. 웹 콘솔을 사용하여 브로커 생성
Knative Eventing이 클러스터에 설치되면 웹 콘솔을 사용하여 브로커를 생성할 수 있습니다. OpenShift Container Platform 웹 콘솔을 사용하면 브로커 생성이 간소화되고 직관적인 사용자 인터페이스를 제공합니다.
사전 요구 사항
- OpenShift Container Platform 웹 콘솔에 로그인했습니다.
- OpenShift Serverless Operator, Knative Serving 및 Knative Eventing이 클러스터에 설치되어 있습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
-
개발자 화면에서 +추가
브로커 로 이동합니다. Broker 페이지가 표시됩니다. -
선택 사항: 브로커 의 이름을 업데이트합니다. 이름을 업데이트하지 않으면 생성된 브로커의 이름이
default
입니다. - 생성을 클릭합니다.
검증
토폴로지 페이지에서 브로커 구성 요소를 확인하여 브로커가 생성되었는지 확인할 수 있습니다.
- 개발자 화면에서 토폴로지로 이동합니다.
mt-broker-ingress
,mt-broker-filter
,mt-broker-controller
구성 요소를 확인합니다.
5.4.3.6. 관리자 화면을 사용하여 브로커 생성
브로커는 트리거와 함께 이벤트 소스에서 이벤트 싱크로 이벤트를 전달하는 데 사용할 수 있습니다. 이벤트는 HTTP POST
요청으로 이벤트 소스에서 브로커로 전송됩니다. 이벤트가 브로커에 진입하면 트리거를 사용하여 CloudEvent 속성으로 필터링하고 이벤트 싱크에 HTTP POST
요청으로 전송할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
- 웹 콘솔에 로그인한 후 관리자 화면에 있습니다.
- OpenShift Container Platform에 대한 클러스터 관리자 권한이 있습니다.
절차
-
OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless
Eventing으로 이동합니다. - 생성 목록에서 브로커를 선택합니다. 그러면 브로커 생성 페이지로 이동합니다.
- 선택 사항: 브로커의 YAML 구성을 수정합니다.
- 생성을 클릭합니다.
5.4.3.7. 다음 단계
- 이벤트가 이벤트 싱크로 전달되지 않는 경우 적용되는 이벤트 전달 매개변수를 구성합니다. 이벤트 전달 매개변수 구성 예를 참조하십시오.
5.4.3.8. 추가 리소스
5.4.4. 기본 브로커 지원 채널 구성
채널 기반 브로커를 사용하는 경우 브로커의 기본 지원 채널 유형을 InMemoryChannel 또는 KafkaChannel로 설정할 수
있습니다
.
사전 요구 사항
- OpenShift Container Platform에 대한 관리자 권한이 있습니다.
- OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
-
OpenShift(
oc
) CLI를 설치했습니다. -
Kafka 채널을 기본 지원 채널 유형으로 사용하려면 클러스터에
KnativeKafka
CR도 설치해야 합니다.
절차
KnativeEventing
CR(사용자 정의 리소스)을 수정하여config-br-default-channel
구성 맵에 대한 구성 세부 정보를 추가합니다.apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: config: 1 config-br-default-channel: channel-template-spec: | apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel 2 spec: numPartitions: 6 3 replicationFactor: 3 4
업데이트된
KnativeEventing
CR을 적용합니다.$ oc apply -f <filename>
5.4.5. 기본 브로커 클래스 구성
config-br-defaults
구성 맵을 사용하여 Knative Eventing의 기본 브로커 클래스 설정을 지정할 수 있습니다. 전체 클러스터 또는 하나 이상의 네임스페이스에 대해 default 브로커 클래스를 지정할 수 있습니다. 현재 MTChannelBasedBroker
및 Kafka
브로커 유형이 지원됩니다.
사전 요구 사항
- OpenShift Container Platform에 대한 관리자 권한이 있습니다.
- OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
-
Kafka 브로커를 기본 브로커 구현으로 사용하려면 클러스터에
KnativeKafka
CR도 설치해야 합니다.
절차
KnativeEventing
사용자 정의 리소스를 수정하여config-br-defaults
구성 맵에 대한 구성 세부 정보를 추가합니다.apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: defaultBrokerClass: Kafka 1 config: 2 config-br-defaults: 3 default-br-config: | clusterDefault: 4 brokerClass: Kafka apiVersion: v1 kind: ConfigMap name: kafka-broker-config 5 namespace: knative-eventing 6 namespaceDefaults: 7 my-namespace: brokerClass: MTChannelBasedBroker apiVersion: v1 kind: ConfigMap name: config-br-default-channel 8 namespace: knative-eventing 9 ...
- 1
- Knative Eventing의 기본 브로커 클래스입니다.
- 2
spec.config
에서 수정된 구성을 추가할 구성 맵을 지정할 수 있습니다.- 3
config-br-defaults
구성 맵은spec.config
설정 또는 브로커 클래스를 지정하지 않는 브로커의 기본 설정을 지정합니다.- 4
- 클러스터 전체 기본 브로커 클래스 구성입니다. 이 예에서 클러스터의 기본 브로커 클래스 구현은
Kafka
입니다. - 5
kafka-broker-config
구성 맵은 Kafka 브로커의 기본 설정을 지정합니다. "추가 리소스" 섹션의 Kafka 브로커 설정 구성을 참조하십시오.- 6
kafka-broker-config
구성 맵이 존재하는 네임스페이스입니다.- 7
- 네임스페이스 범위의 기본 브로커 클래스 구성입니다. 이 예에서
my-namespace
네임스페이스의 기본 브로커 클래스 구현은MTChannelBasedBroker
입니다. 여러 네임스페이스에 기본 브로커 클래스 구현을 지정할 수 있습니다. - 8
config-br-default-channel
구성 맵은 브로커의 기본 지원 채널을 지정합니다. "추가 리소스" 섹션의 "기본 브로커 백업 채널 구성"을 참조하십시오.- 9
config-br-default-channel
구성 맵이 존재하는 네임스페이스입니다.
중요네임스페이스별 기본값을 구성하면 클러스터 수준 설정을 덮어씁니다.
5.4.6. 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 레코드의 헤더로 매핑됩니다.
Kafka 브로커 사용에 대한 자세한 내용은 브로커 생성을 참조하십시오.
5.4.7. 기본 브로커 유형으로 구성되지 않은 경우 Kafka 브로커 생성
OpenShift Serverless 배포가 Kafka 브로커를 기본 브로커 유형으로 사용하도록 구성되지 않은 경우 다음 절차 중 하나를 사용하여 Kafka 기반 브로커를 생성할 수 있습니다.
5.4.7.1. YAML을 사용하여 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>
5.4.7.2. 외부 관리 Kafka 주제를 사용하는 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>
5.4.8. Knative Kafka의 보안 구성
Kafka 클러스터는 일반적으로 TLS 또는 SASL 인증 방법을 사용하여 보호됩니다. TLS 또는 SASL을 사용하여 보호된 Red Hat AMQ Streams 클러스터에서 작동하도록 Kafka 브로커 또는 채널을 구성할 수 있습니다.
SASL과 TLS를 모두 함께 활성화하는 것이 좋습니다.
5.4.8.1. Kafka 브로커에 대한 TLS 인증 구성
TLS( Transport Layer Security )는 Apache Kafka 클라이언트 및 서버에서 Knative와 Kafka 간 트래픽을 암호화하고 인증을 위해 사용합니다. TLS는 Knative Kafka에서 지원되는 유일한 트래픽 암호화 방법입니다.
사전 요구 사항
- OpenShift Container Platform에 대한 클러스터 또는 전용 관리자 권한이 있어야 합니다.
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
CR이 OpenShift Container Platform 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
Kafka 클러스터 CA 인증서가
.pem
파일로 저장되어 있습니다. -
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을 편집하고브로커
사양의 보안에 참조를 추가합니다.apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: broker: enabled: true defaultConfig: authSecretName: <secret_name> ...
5.4.8.2. 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
,암호
,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을 편집하고브로커
사양의 보안에 참조를 추가합니다.apiVersion: operator.serverless.openshift.io/v1alpha1 kind: KnativeKafka metadata: namespace: knative-eventing name: knative-kafka spec: broker: enabled: true defaultConfig: authSecretName: <secret_name> ...
5.4.9. 브로커 관리
Knative(kn
) CLI는 기존 브로커를 설명하고 나열하는 데 사용할 수 있는 명령을 제공합니다.
5.4.9.1. Knative CLI를 사용하여 기존 브로커 나열
Knative(kn
) CLI를 사용하여 브로커를 나열하면 간소화되고 직관적인 사용자 인터페이스가 제공됩니다. kn broker list
명령을 사용하여 Knative CLI를 사용하여 클러스터의 기존 브로커를 나열할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
-
Knative(
kn
) CLI가 설치되어 있습니다.
절차
기존 브로커를 모두 나열합니다.
$ kn broker list
출력 예
NAME URL AGE CONDITIONS READY REASON default http://broker-ingress.knative-eventing.svc.cluster.local/test/default 45s 5 OK / 5 True
5.4.9.2. Knative CLI를 사용하여 기존 브로커 설명
Knative(kn
) CLI를 사용하여 브로커를 설명하면 간소화되고 직관적인 사용자 인터페이스를 제공합니다. kn broker describe
명령을 사용하여 Knative CLI를 사용하여 클러스터의 기존 브로커에 대한 정보를 출력할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Container Platform 클러스터에 설치되어 있습니다.
-
Knative(
kn
) CLI가 설치되어 있습니다.
절차
기존 브로커를 설명합니다.
$ kn broker describe <broker_name>
기본 브로커를 사용하는 명령의 예
$ kn broker describe default
출력 예
Name: default Namespace: default Annotations: eventing.knative.dev/broker.class=MTChannelBasedBroker, eventing.knative.dev/creato ... Age: 22s Address: URL: http://broker-ingress.knative-eventing.svc.cluster.local/default/default Conditions: OK TYPE AGE REASON ++ Ready 22s ++ Addressable 22s ++ FilterReady 22s ++ IngressReady 22s ++ TriggerChannelReady 22s
5.4.10. 이벤트 전달
이벤트가 이벤트 싱크로 전달되지 않는 경우 적용되는 이벤트 전달 매개변수를 구성할 수 있습니다. dead letter sink를 포함하여 이벤트 전달 매개변수를 구성하면 이벤트 싱크로 전달되지 못한 이벤트를 다시 수행할 수 있습니다. 그렇지 않으면 전달되지 않은 이벤트가 삭제됩니다.
5.4.10.1. 채널 및 브로커에 대한 이벤트 전달 동작 패턴
다양한 채널 및 브로커 유형에는 이벤트 전달을 위해 그 뒤에 자체 동작 패턴이 있습니다.
5.4.10.1.1. Knative Kafka 채널 및 브로커
이벤트가 Kafka 채널 또는 브로커 수신자에게 성공적으로 전달되면 수신자는 202
상태 코드로 응답합니다. 즉, 이벤트가 Kafka 주제 내부에 안전하게 저장되어 손실되지 않습니다.
수신자가 다른 상태 코드로 응답하는 경우 이벤트는 안전하게 저장되지 않으며 문제를 해결하기 위해 사용자가 단계를 수행해야 합니다.
5.4.10.2. 구성 가능한 이벤트 전달 매개변수
이벤트 전달을 위해 다음 매개변수를 구성할 수 있습니다.
- dead letter sink
-
이벤트가 전달되지 않으면 지정된 이벤트 싱크에 저장되도록
deadLetterSink
전달 매개변수를 구성할 수 있습니다. dead letter sink에 저장되지 않은 이벤트가 삭제됩니다. dead letter sink는 Knative 서비스, Kubernetes 서비스 또는 URI와 같은 Knative Eventing 싱크 계약을 준수하는 주소 지정 가능한 오브젝트입니다. - retries
-
재시도 전달 매개변수를 정수 값으로 구성하여 이벤트가 dead letter sink로 전송되기 전에 전달을
retry
해야 하는 최소 횟수를 설정할 수 있습니다. - back off delay
-
backoffDelay
전달 매개변수를 설정하여 실패 후 이벤트 전달을 재시도하기 전에 시간 지연을 지정할 수 있습니다.backoffDelay
매개변수의 기간은 ISO 8601 형식을 사용하여 지정합니다. 예를 들어PT1S
는 1초 지연을 지정합니다. - back off policy
-
backoffPolicy
전달 매개 변수를 사용하여 재시도 정책을 지정할 수 있습니다. 정책을linear
또는exponential
로 지정할 수 있습니다.linear
백오프 정책을 사용하는 경우 백오프 지연은backoffDelay * <numberOfRetries>와 동일합니다
.exponential
백오프 정책을 사용하는 경우 백오프 지연은backoffDelay*2^<numberOfRetries>
와 동일합니다.
5.4.10.3. 이벤트 전달 매개변수 구성 예
브로커
,트리거
,채널
, 서브스크립션
오브젝트에 대한 이벤트 전달 매개변수를 구성할 수 있습니다. 브로커 또는 채널에 대한 이벤트 전달 매개변수를 구성하는 경우 이러한 매개변수는 해당 오브젝트에 대해 생성된 트리거 또는 서브스크립션으로 전파됩니다. 브로커 또는 채널의 설정을 재정의하도록 트리거 또는 서브스크립션에 대한 이벤트 전달 매개변수를 설정할 수도 있습니다.
Broker
오브젝트의 예
apiVersion: eventing.knative.dev/v1 kind: Broker metadata: ... spec: delivery: deadLetterSink: ref: apiVersion: eventing.knative.dev/v1alpha1 kind: KafkaSink name: <sink_name> backoffDelay: <duration> backoffPolicy: <policy_type> retry: <integer> ...
Trigger
오브젝트의 예
apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: ... spec: broker: <broker_name> delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: <sink_name> backoffDelay: <duration> backoffPolicy: <policy_type> retry: <integer> ...
Channel
오브젝트의 예
apiVersion: messaging.knative.dev/v1 kind: Channel metadata: ... spec: delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: <sink_name> backoffDelay: <duration> backoffPolicy: <policy_type> retry: <integer> ...
Subscription
개체 예
apiVersion: messaging.knative.dev/v1 kind: Subscription metadata: ... spec: channel: apiVersion: messaging.knative.dev/v1 kind: Channel name: <channel_name> delivery: deadLetterSink: ref: apiVersion: serving.knative.dev/v1 kind: Service name: <sink_name> backoffDelay: <duration> backoffPolicy: <policy_type> retry: <integer> ...
5.4.10.4. 트리거의 이벤트 전달 순서 구성
Kafka 브로커를 사용하는 경우 트리거에서 이벤트 싱크로 이벤트 전달 순서를 구성할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator, Knative Eventing, Knative Kafka가 OpenShift Container Platform 클러스터에 설치되어 있습니다.
- Kafka 브로커는 클러스터에서 사용할 수 있도록 활성화되며 Kafka 브로커를 생성했습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift(
oc
) CLI를 설치했습니다.
절차
Trigger
오브젝트를 생성하거나 수정하고kafka.eventing.knative.dev/delivery.order
주석을 설정합니다.apiVersion: eventing.knative.dev/v1 kind: Trigger metadata: name: <trigger_name> annotations: kafka.eventing.knative.dev/delivery.order: ordered ...
지원되는 소비자 제공 보장은 다음과 같습니다.
순서가 지정되지 않음
- 순서가 지정되지 않은 소비자는 적절한 오프셋 관리를 유지하면서 순서가 지정되지 않은 메시지를 전달하는 비차단 소비자입니다.
ordered
순서가 지정된 소비자는 CloudEvent 구독자의 성공적인 응답을 기다린 후 파티션의 다음 메시지를 전달하기 전에 대기 중인 소비자별 소비자입니다.
기본 주문 보장은 순서가
지정되지
않습니다.
Trigger
오브젝트를 적용합니다.$ oc apply -f <filename>