5.3. 이벤트 싱크


5.3.1. 이벤트 싱크

이벤트 소스를 생성할 때 소스에서 이벤트를 보내는 싱크를 지정할 수 있습니다. 싱크는 다른 리소스에서 들어오는 이벤트를 수신할 수 있는 주소 지정 가능 또는 호출 가능한 리소스입니다. Knative 서비스, 채널 및 브로커는 모두 싱크의 예입니다.

주소 지정 오브젝트는 HTTP를 통해 제공되는 이벤트를 status.address.url 필드에 정의된 주소로 수신 및 승인합니다. 특수한 경우 Kubernetes 서비스 오브젝트도 주소 지정 가능한 인터페이스입니다.

호출 가능 오브젝트는 HTTP를 통해 전달되는 이벤트를 수신하고 이벤트를 변환하여 HTTP 응답에서 0 또는 1 개의 새 이벤트를 반환할 수 있습니다. 반환된 이벤트는 외부 이벤트 소스의 이벤트를 처리하는 것과 동일한 방식으로 추가로 처리할 수 있습니다.

5.3.1.1. Knative CLI 싱크 플래그

Knative(kn) CLI를 사용하여 이벤트 소스를 생성할 때 --sink 플래그를 사용하여 해당 리소스에서 이벤트가 전송되는 싱크를 지정할 수 있습니다. 싱크는 다른 리소스에서 들어오는 이벤트를 수신할 수 있는 주소 지정 가능 또는 호출 가능한 리소스일 수 있습니다.

다음 예제에서는 싱크로 서비스 http://event-display.svc.cluster.local 를 사용하는 싱크 바인딩을 생성합니다.

싱크 플래그를 사용하는 명령의 예

$ kn source binding create bind-heartbeat \
  --namespace sinkbinding-example \
  --subject "Job:batch/v1:app=heartbeat-cron" \
  --sink http://event-display.svc.cluster.local \ 1
  --ce-override "sink=bound"

1
http://event-display.svc.cluster.localsvc 는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는 channel, 및 broker가 포함됩니다.
작은 정보

kn( kn) CLI 명령에 --sink 플래그와 함께 사용할 수 있는 CR을 사용자 정의 하여 구성할 수 있습니다.

5.3.2. Kafka 싱크

Kafka 싱크는 클러스터 관리자가 클러스터에서 Kafka를 활성화한 경우 사용할 수 있는 이벤트 싱크 유형입니다. Kafka 싱크를 사용하여 이벤트 소스에서 Kafka 주제로 직접 이벤트를 보낼 수 있습니다.

5.3.2.1. Kafka 싱크 사용

Kafka 항목에 이벤트를 전송하는 Kafka 싱크라는 이벤트 싱크를 생성할 수 있습니다. YAML 파일을 사용하여 Knative 리소스를 생성하면 선언적 방식으로 애플리케이션을 재현할 수 있으며 재현 가능한 방식으로 애플리케이션을 설명할 수 있습니다. 기본적으로 Kafka 싱크는 구조화된 모드보다 효율적인 바이너리 콘텐츠 모드를 사용합니다. YAML을 사용하여 Kafka 싱크를 생성하려면 KafkaSink 오브젝트를 정의하는 YAML 파일을 생성한 다음 oc apply 명령을 사용하여 적용해야 합니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka CR(사용자 정의 리소스)이 클러스터에 설치되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • 가져오려는 Kafka 메시지를 생성하는 Red Hat AMQ Streams(Kafka) 클러스터에 액세스할 수 있습니다.
  • OpenShift CLI(oc)를 설치합니다.

절차

  1. KafkaSink 오브젝트 정의를 YAML 파일로 생성합니다.

    Kafka 싱크 YAML

    apiVersion: eventing.knative.dev/v1alpha1
    kind: KafkaSink
    metadata:
      name: <sink-name>
      namespace: <namespace>
    spec:
      topic: <topic-name>
      bootstrapServers:
       - <bootstrap-server>

  2. Kafka 싱크를 생성하려면 KafkaSink YAML 파일을 적용합니다.

    $ oc apply -f <filename>
  3. 싱크가 사양에 지정되도록 이벤트 소스를 구성합니다.

    API 서버 소스에 연결된 Kafka 싱크의 예

    apiVersion: sources.knative.dev/v1alpha2
    kind: ApiServerSource
    metadata:
      name: <source-name> 1
      namespace: <namespace> 2
    spec:
      serviceAccountName: <service-account-name> 3
      mode: Resource
      resources:
      - apiVersion: v1
        kind: Event
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1alpha1
          kind: KafkaSink
          name: <sink-name> 4

    1
    이벤트 소스의 이름입니다.
    2
    이벤트 소스의 네임스페이스입니다.
    3
    이벤트 소스에 대한 서비스 계정입니다.
    4
    Kafka 싱크 이름입니다.

5.3.2.2. Kafka 싱크에 대한 보안 구성

TLS( Transport Layer Security )는 Apache Kafka 클라이언트와 서버에서 Knative와 Kafka 간의 트래픽 암호화 및 인증에 사용됩니다. TLS는 Knative Kafka에서 지원되는 유일한 트래픽 암호화 방법입니다.

SASL( Simple Authentication and Security Layer )은 Apache Kafka에서 인증에 사용됩니다. 클러스터에서 SASL 인증을 사용하는 경우 사용자는 Kafka 클러스터와 통신하기 위해 Knative에 인증 정보를 제공해야 합니다. 그러지 않으면 이벤트를 생성하거나 사용할 수 없습니다.

사전 요구 사항

  • OpenShift Serverless Operator, Knative Eventing, KnativeKafka 사용자 정의 리소스(CR)가 OpenShift Container Platform 클러스터에 설치되어 있습니다.
  • Kafka 싱크는 KnativeKafka CR에서 활성화되어 있습니다.
  • 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
  • Kafka 클러스터 CA 인증서가 .pem 파일로 저장되어 있습니다.
  • Kafka 클러스터 클라이언트 인증서 및 키가 .pem 파일로 저장되어 있습니다.
  • OpenShift(oc) CLI를 설치했습니다.
  • 사용할 SASL 메커니즘을 선택했습니다(예: PLAIN,SCRAM-SHA-256 또는 SCRAM-SHA-512 ).

절차

  1. KafkaSink 오브젝트와 동일한 네임스페이스에 인증서 파일을 시크릿으로 생성합니다.

    중요

    인증서 및 키는 PEM 형식이어야 합니다.

    • 암호화 없이 SASL을 사용한 인증의 경우:

      $ oc create secret -n <namespace> generic <secret_name> \
        --from-literal=protocol=SASL_PLAINTEXT \
        --from-literal=sasl.mechanism=<sasl_mechanism> \
        --from-literal=user=<username> \
        --from-literal=password=<password>
    • TLS를 사용한 SASL 및 암호화를 사용한 인증의 경우:

      $ oc create secret -n <namespace> generic <secret_name> \
        --from-literal=protocol=SASL_SSL \
        --from-literal=sasl.mechanism=<sasl_mechanism> \
        --from-file=ca.crt=<my_caroot.pem_file_path> \ 1
        --from-literal=user=<username> \
        --from-literal=password=<password>
      1
      퍼블릭 클라우드 관리 Kafka 서비스를 사용하는 경우 시스템의 루트 CA 세트(예: Red Hat OpenShift Streams for Apache Kafka)를 사용하도록 ca.crt 를 생략할 수 있습니다.
    • TLS를 사용한 인증 및 암호화의 경우:

      $ oc create secret -n <namespace> generic <secret_name> \
        --from-literal=protocol=SSL \
        --from-file=ca.crt=<my_caroot.pem_file_path> \ 1
        --from-file=user.crt=<my_cert.pem_file_path> \
        --from-file=user.key=<my_key.pem_file_path>
      1
      퍼블릭 클라우드 관리 Kafka 서비스를 사용하는 경우 시스템의 루트 CA 세트(예: Red Hat OpenShift Streams for Apache Kafka)를 사용하도록 ca.crt 를 생략할 수 있습니다.
  2. KafkaSink 오브젝트를 생성하거나 수정하고 auth 사양에서 보안에 대한 참조를 추가합니다.

    apiVersion: eventing.knative.dev/v1alpha1
    kind: KafkaSink
    metadata:
       name: <sink_name>
       namespace: <namespace>
    spec:
    ...
       auth:
         secret:
           ref:
             name: <secret_name>
    ...
  3. KafkaSink 오브젝트를 적용합니다.

    $ oc apply -f <filename>
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.