Eventing

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless → Eventing으로 이동합니다.
2. 생성 목록에서 이벤트 소스를 선택합니다. 그러면 이벤트 소스 페이지로 이동합니다.
3. 생성할 이벤트 소스 유형을 선택합니다.

1. 이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩을 YAML 파일로 만듭니다.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   이 네임스페이스를 이벤트 소스 설치를 위해 선택한 네임스페이스로 변경합니다.

2. YAML 파일을 적용합니다.

   $ oc apply -f <filename>

3. 개발자 화면에서 +추가 → 이벤트 소스로 이동합니다. 이벤트 소스 페이지가 표시됩니다.
4. 선택 사항: 이벤트 소스에 대한 공급자가 여러 개인 경우 공급자 목록에서 필요한 공급자를 선택하여 해당 공급자의 사용 가능한 이벤트 소스를 필터링합니다.
5. ApiServerSource를 선택한 다음 이벤트 소스 생성을 클릭합니다. 이벤트 소스 생성 페이지가 표시됩니다.

6. 양식 보기 또는 YAML 보기를 사용하여 ApiServerSource 설정을 구성합니다.

   참고

   양식 보기와 YAML 보기를 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

   1. APIVERSION으로 v1을, KIND로 Event를 입력합니다.
   2. 생성한 서비스 계정의 서비스 계정 이름을 선택합니다.

   3. 대상 섹션에서 이벤트 싱크를 선택합니다. 리소스 또는 URI 일 수 있습니다.

      1. 채널, 브로커 또는 서비스를 이벤트 소스의 이벤트 싱크로 사용하려면 리소스 를 선택합니다.
      2. URI 를 선택하여 이벤트가 라우팅되는 URI(Uniform Resource Identifier)를 지정합니다.
7. 생성을 클릭합니다.

API 서버 소스 삭제

1. 토폴로지 보기로 이동합니다.

2. API 서버 소스를 마우스 오른쪽 버튼으로 클릭하고 ApiServerSource 삭제를 선택합니다.

   

1. 이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩을 YAML 파일로 만듭니다.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   이 네임스페이스를 이벤트 소스 설치를 위해 선택한 네임스페이스로 변경합니다.

2. YAML 파일을 적용합니다.

   $ oc apply -f <filename>

3. 이벤트 싱크가 있는 API 서버 소스를 생성합니다. 다음 예에서 싱크는 브로커입니다.

   $ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource

4. API 서버 소스가 올바르게 설정되었는지 확인하려면 수신되는 메시지를 로그로 덤프하는 Knative 서비스를 생성합니다.

   $ kn service create event-display --image quay.io/openshift-knative/showcase

5. 브로커를 이벤트 싱크로 사용한 경우 default 브로커의 이벤트를 서비스로 필터링하는 트리거를 생성합니다.

   $ kn trigger create <trigger_name> --sink ksvc:event-display

6. 기본 네임스페이스에서 Pod를 시작하여 이벤트를 생성합니다.

   $ oc create deployment event-origin --image quay.io/openshift-knative/showcase

7. 생성된 출력을 다음 명령으로 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

   $ kn source apiserver describe <source_name>

   출력 예

   Name:                mysource
   Namespace:           default
   Annotations:         sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:                 3m
   ServiceAccountName:  events-sa
   Mode:                Resource
   Sink:
     Name:       default
     Namespace:  default
     Kind:       Broker (eventing.knative.dev/v1)
   Resources:
     Kind:        event (v1)
     Controller:  false
   Conditions:
     OK TYPE                     AGE REASON
     ++ Ready                     3m
     ++ Deployed                  3m
     ++ SinkProvided              3m
     ++ SufficientPermissions     3m
     ++ EventTypesProvided        3m

API 서버 소스 삭제

1. 트리거를 삭제합니다.

   $ kn trigger delete <trigger_name>

2. 이벤트 소스를 삭제합니다.

   $ kn source apiserver delete <source_name>

3. 서비스 계정, 클러스터 역할, 클러스터 바인딩을 삭제합니다.

   $ oc delete -f authentication.yaml

1. 이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩을 YAML 파일로 만듭니다.

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: events-sa
     namespace: default 1
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: Role
   metadata:
     name: event-watcher
     namespace: default 2
   rules:
     - apiGroups:
         - ""
       resources:
         - events
       verbs:
         - get
         - list
         - watch
   
   ---
   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: k8s-ra-event-watcher
     namespace: default 3
   roleRef:
     apiGroup: rbac.authorization.k8s.io
     kind: Role
     name: event-watcher
   subjects:
     - kind: ServiceAccount
       name: events-sa
       namespace: default 4

   1 2 3 4

   이 네임스페이스를 이벤트 소스 설치를 위해 선택한 네임스페이스로 변경합니다.

2. YAML 파일을 적용합니다.

   $ oc apply -f <filename>

3. API 서버 소스를 YAML 파일로 만듭니다.

   apiVersion: sources.knative.dev/v1alpha1
   kind: ApiServerSource
   metadata:
     name: testevents
   spec:
     serviceAccountName: events-sa
     mode: Resource
     resources:
       - apiVersion: v1
         kind: Event
     sink:
       ref:
         apiVersion: eventing.knative.dev/v1
         kind: Broker
         name: default

4. ApiServerSource YAML 파일을 적용합니다.

   $ oc apply -f <filename>

5. API 서버 소스가 올바르게 설정되었는지 확인하려면 수신되는 메시지를 로그로 덤프하는 Knative 서비스를 YAML 파일로 생성합니다.

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-display
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/showcase

6. Service YAML 파일을 적용합니다.

   $ oc apply -f <filename>

7. default 브로커에서 이전 단계에서 생성된 서비스로 이벤트를 필터링하는 YAML 파일로 Trigger 오브젝트를 생성합니다.

   apiVersion: eventing.knative.dev/v1
   kind: Trigger
   metadata:
     name: event-display-trigger
     namespace: default
   spec:
     broker: default
     subscriber:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

8. Trigger YAML 파일을 적용합니다.

   $ oc apply -f <filename>

9. 기본 네임스페이스에서 Pod를 시작하여 이벤트를 생성합니다.

   $ oc create deployment event-origin --image=quay.io/openshift-knative/showcase

10. 다음 명령을 입력하고 출력을 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

    $ oc get apiserversource.sources.knative.dev testevents -o yaml

    출력 예

    apiVersion: sources.knative.dev/v1alpha1
    kind: ApiServerSource
    metadata:
      annotations:
      creationTimestamp: "2020-04-07T17:24:54Z"
      generation: 1
      name: testevents
      namespace: default
      resourceVersion: "62868"
      selfLink: /apis/sources.knative.dev/v1alpha1/namespaces/default/apiserversources/testevents2
      uid: 1603d863-bb06-4d1c-b371-f580b4db99fa
    spec:
      mode: Resource
      resources:
      - apiVersion: v1
        controller: false
        controllerSelector:
          apiVersion: ""
          kind: ""
          name: ""
          uid: ""
        kind: Event
        labelSelector: {}
      serviceAccountName: events-sa
      sink:
        ref:
          apiVersion: eventing.knative.dev/v1
          kind: Broker
          name: default

API 서버 소스 삭제

1. 트리거를 삭제합니다.

   $ oc delete -f trigger.yaml

2. 이벤트 소스를 삭제합니다.

   $ oc delete -f k8s-events.yaml

3. 서비스 계정, 클러스터 역할, 클러스터 바인딩을 삭제합니다.

   $ oc delete -f authentication.yaml

프로세스

1. ping 소스가 작동하는지 확인하려면 수신 메시지를 서비스 로그에 덤프하는 간단한 Knative 서비스를 생성합니다.

   1. 개발자 화면에서 +추가 → YAML로 이동합니다.

   2. 예제 YAML을 복사합니다.

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/showcase

   3. 생성을 클릭합니다.

2. 이전 단계에서 생성한 서비스와 동일한 네임스페이스 또는 이벤트를 보낼 다른 싱크에 ping 소스를 생성합니다.

   1. 개발자 화면에서 +추가 → 이벤트 소스로 이동합니다. 이벤트 소스 페이지가 표시됩니다.
   2. 선택 사항: 이벤트 소스에 대한 공급자가 여러 개인 경우 공급자 목록에서 필요한 공급자를 선택하여 해당 공급자의 사용 가능한 이벤트 소스를 필터링합니다.

   3. Ping 소스를 선택한 다음 이벤트 소스 생성을 클릭합니다. 이벤트 소스 생성 페이지가 표시됩니다.

      참고

      양식 보기 또는 YAML 보기를 사용하여 PingSource 설정을 구성하고 보기 간에 전환할 수 있습니다. 다른 보기로 전환해도 데이터는 유지됩니다.

   4. 스케줄 값을 입력합니다. 이 예에서 값은 */2 * * * *이며, 2분마다 메시지를 전송하는 PingSource를 생성합니다.
   5. 선택 사항: 메시지 페이로드에 해당하는 데이터 값을 입력할 수 있습니다.

   6. 대상 섹션에서 이벤트 싱크를 선택합니다. 리소스 또는 URI 일 수 있습니다.

      1. 채널, 브로커 또는 서비스를 이벤트 소스의 이벤트 싱크로 사용하려면 리소스 를 선택합니다. 이 예에서는 이전 단계에서 생성한 event-display 서비스가 대상 리소스로 사용됩니다.
      2. URI 를 선택하여 이벤트가 라우팅되는 URI(Uniform Resource Identifier)를 지정합니다.
   7. 생성을 클릭합니다.

1. 개발자 화면에서 토폴로지로 이동합니다.

2. ping 소스 및 싱크를 확인합니다.

   

3. 웹 브라우저에서 event-display 서비스를 확인합니다. 웹 UI에서 ping 소스 이벤트가 표시되어야 합니다.

   

ping 소스 삭제

1. 토폴로지 보기로 이동합니다.
2. API 서버 소스를 마우스 오른쪽 버튼으로 클릭하고 Ping Source 삭제 를 선택합니다.

프로세스

1. ping 소스가 작동하는지 확인하려면 수신 메시지를 서비스 로그에 덤프하는 간단한 Knative 서비스를 생성합니다.

   $ kn service create event-display \
       --image quay.io/openshift-knative/showcase

2. 요청할 각 ping 이벤트 세트에 대해 이벤트 소비자와 동일한 네임스페이스에 ping 소스를 생성합니다.

   $ kn source ping create test-ping-source \
       --schedule "*/2 * * * *" \
       --data '{"message": "Hello world!"}' \
       --sink ksvc:event-display

3. 다음 명령을 입력하고 출력을 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

   $ kn source ping describe test-ping-source

   출력 예

   Name:         test-ping-source
   Namespace:    default
   Annotations:  sources.knative.dev/creator=developer, sources.knative.dev/lastModifier=developer
   Age:          15s
   Schedule:     */2 * * * *
   Data:         {"message": "Hello world!"}
   
   Sink:
     Name:       event-display
     Namespace:  default
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE                 AGE REASON
     ++ Ready                 8s
     ++ Deployed              8s
     ++ SinkProvided         15s
     ++ ValidSchedule        15s
     ++ EventTypeProvided    15s
     ++ ResourcesCorrect     15s

1. 새 Pod가 생성되었는지 확인합니다.

   $ watch oc get pods

2. Ctrl+C를 사용하여 Pod를 감시한 다음 생성한 Pod의 로그를 확인합니다.

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   출력 예

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 99e4f4f6-08ff-4bff-acf1-47f61ded68c9
     time: 2020-04-07T16:16:00.000601161Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

프로세스

1. ping 소스가 작동하는지 확인하려면 수신 메시지를 서비스 로그에 덤프하는 간단한 Knative 서비스를 생성합니다.

   1. 서비스 YAML 파일을 생성합니다.

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: event-display
      spec:
        template:
          spec:
            containers:
              - image: quay.io/openshift-knative/showcase

   2. 서비스를 생성합니다.

      $ oc apply -f <filename>

2. 요청할 각 ping 이벤트 세트에 대해 이벤트 소비자와 동일한 네임스페이스에 ping 소스를 생성합니다.

   1. ping 소스에 대한 YAML 파일을 생성합니다.

      apiVersion: sources.knative.dev/v1
      kind: PingSource
      metadata:
        name: test-ping-source
      spec:
        schedule: "*/2 * * * *"
        data: '{"message": "Hello world!"}'
        sink:
          ref:
            apiVersion: serving.knative.dev/v1
            kind: Service
            name: event-display

   2. ping 소스를 생성합니다.

      $ oc apply -f <filename>

3. 다음 명령을 입력하여 컨트롤러가 올바르게 매핑되는지 확인합니다.

   $ oc get pingsource.sources.knative.dev <ping_source_name> -oyaml

   출력 예

   apiVersion: sources.knative.dev/v1
   kind: PingSource
   metadata:
     annotations:
       sources.knative.dev/creator: developer
       sources.knative.dev/lastModifier: developer
     creationTimestamp: "2020-04-07T16:11:14Z"
     generation: 1
     name: test-ping-source
     namespace: default
     resourceVersion: "55257"
     selfLink: /apis/sources.knative.dev/v1/namespaces/default/pingsources/test-ping-source
     uid: 3d80d50b-f8c7-4c1b-99f7-3ec00e0a8164
   spec:
     data: '{ value: "hello" }'
     schedule: '*/2 * * * *'
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display
         namespace: default

1. 새 Pod가 생성되었는지 확인합니다.

   $ watch oc get pods

2. Ctrl+C를 사용하여 Pod를 감시한 다음 생성한 Pod의 로그를 확인합니다.

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   출력 예

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.sources.ping
     source: /apis/v1/namespaces/default/pingsources/test-ping-source
     id: 042ff529-240e-45ee-b40c-3a908129853e
     time: 2020-04-07T16:22:00.000791674Z
     datacontenttype: application/json
   Data,
     {
       "message": "Hello world!"
     }

프로세스

1. 개발자 화면에서 +추가 페이지로 이동하여 이벤트 소스 를 선택합니다.
2. 이벤트 소스 페이지의 유형 섹션에서 Kafka 소스를 선택합니다.

3. Kafka 소스 설정을 구성합니다.

   1. 쉼표로 구분된 부트스트랩 서버 목록을 추가합니다.
   2. 쉼표로 구분된 주제 목록을 추가합니다.
   3. 소비자 그룹을 추가합니다.
   4. 생성한 서비스 계정의 서비스 계정 이름을 선택합니다.

   5. 대상 섹션에서 이벤트 싱크를 선택합니다. 리소스 또는 URI 일 수 있습니다.

      1. 채널, 브로커 또는 서비스를 이벤트 소스의 이벤트 싱크로 사용하려면 리소스 를 선택합니다.
      2. URI 를 선택하여 이벤트가 라우팅되는 URI(Uniform Resource Identifier)를 지정합니다.
   6. Kafka 이벤트 소스로 이름을 입력합니다.
4. 생성을 클릭합니다.

1. 개발자 화면에서 토폴로지로 이동합니다.

2. Kafka 이벤트 소스 및 싱크를 확인합니다.

   

프로세스

1. Kafka 이벤트 소스가 작동하는지 확인하려면 수신 이벤트를 서비스 로그에 덤프하는 Knative 서비스를 생성합니다.

   $ kn service create event-display \
       --image quay.io/openshift-knative/showcase

2. KafkaSource CR을 생성합니다.

   $ kn source kafka create <kafka_source_name> \
       --servers <cluster_kafka_bootstrap>.kafka.svc:9092 \
       --topics <topic_name> --consumergroup my-consumer-group \
       --sink event-display

   참고

   이 명령의 자리 표시자 값을 소스 이름, 부트스트랩 서버 및 주제의 값으로 바꿉니다.

   --servers, --topics, --consumergroup 옵션은 Kafka 클러스터에 대한 연결 매개 변수를 지정합니다. --consumergroup 옵션은 선택 사항입니다.

3. 선택 사항: 생성한 KafkaSource CR에 대한 세부 정보를 확인합니다.

   $ kn source kafka describe <kafka_source_name>

   출력 예

   Name:              example-kafka-source
   Namespace:         kafka
   Age:               1h
   BootstrapServers:  example-cluster-kafka-bootstrap.kafka.svc:9092
   Topics:            example-topic
   ConsumerGroup:     example-consumer-group
   
   Sink:
     Name:       event-display
     Namespace:  default
     Resource:   Service (serving.knative.dev/v1)
   
   Conditions:
     OK TYPE            AGE REASON
     ++ Ready            1h
     ++ Deployed         1h
     ++ SinkProvided     1h

검증 단계

1. Kafka 인스턴스를 트리거하여 메시지를 항목에 보냅니다.

   $ oc -n kafka run kafka-producer \
       -ti --image=quay.io/strimzi/kafka:latest-kafka-2.7.0 --rm=true \
       --restart=Never -- bin/kafka-console-producer.sh \
       --broker-list <cluster_kafka_bootstrap>:9092 --topic my-topic

   프롬프트에 메시지를 입력합니다. 이 명령은 다음을 가정합니다.

   • Kafka 클러스터는 kafka 네임스페이스에 설치됩니다.
   • my-topic 주제를 사용하도록 KafkaSource 오브젝트가 구성되어 있습니다.

2. 로그를 보고 메시지가 도착했는지 확인합니다.

   $ oc logs $(oc get pod -o name | grep event-display) -c user-container

   출력 예

   ☁️  cloudevents.Event
   Validation: valid
   Context Attributes,
     specversion: 1.0
     type: dev.knative.kafka.event
     source: /apis/v1/namespaces/default/kafkasources/example-kafka-source#example-topic
     subject: partition:46#0
     id: partition:46/offset:0
     time: 2021-03-10T11:21:49.4Z
   Extensions,
     traceparent: 00-161ff3815727d8755848ec01c866d1cd-7ff3916c44334678-00
   Data,
     Hello!

프로세스

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

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: <source_name>
   spec:
     consumerGroup: <group_name> 1
     bootstrapServers:
     - <list_of_bootstrap_servers>
     topics:
     - <list_of_topics> 2
     sink:
     - <list_of_sinks> 3

   1

   소비자 그룹은 동일한 그룹 ID를 사용하고 한 주제의 데이터를 사용하는 소비자 그룹입니다.

   2

   주제에서는 데이터 스토리지의 대상을 제공합니다. 각 주제는 하나 이상의 파티션으로 나뉩니다.

   3

   싱크는 소스에서 이벤트를 보내는 위치를 지정합니다.

   중요

   OpenShift Serverless의 KafkaSource 개체에 대한 API의 v1beta1 버전만 지원됩니다. 이 버전은 더 이상 사용되지 않으므로 이 API의 v1alpha1 버전을 사용하지 마십시오.

   KafkaSource 오브젝트의 예

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: kafka-source
   spec:
     consumerGroup: knative-group
     bootstrapServers:
     - my-cluster-kafka-bootstrap.kafka:9092
     topics:
     - knative-demo-topic
     sink:
       ref:
         apiVersion: serving.knative.dev/v1
         kind: Service
         name: event-display

2. KafkaSource YAML 파일을 적용합니다.

   $ oc apply -f <filename>

프로세스

1. 선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-literal=password="SecretPassword" \
     --from-literal=saslType="SCRAM-SHA-512" \ 1
     --from-literal=user="my-sasl-user"

   1

   SASL 유형은 PLAIN,SCRAM-SHA-256 또는 SCRAM-SHA-512 일 수 있습니다.

2. 다음 사양 구성이 포함되도록 Kafka 소스를 생성하거나 수정합니다.

   apiVersion: sources.knative.dev/v1beta1
   kind: KafkaSource
   metadata:
     name: example-source
   spec:
   ...
     net:
       sasl:
         enable: true
         user:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: user
         password:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: password
         type:
           secretKeyRef:
             name: <kafka_auth_secret>
             key: saslType
       tls:
         enable: true
         caCert: 1
           secretKeyRef:
             name: <kafka_auth_secret>
             key: ca.crt
   ...

   1

   퍼블릭 클라우드 Kafka 서비스를 사용하는 경우 caCert 사양이 필요하지 않습니다.

프로세스

1. +추가 → 이벤트 소스로 이동하고 생성할 이벤트 소스 유형을 선택하여 모든 유형의 이벤트 소스를 생성합니다.

2. 이벤트 소스 생성 양식 보기의 대상 섹션에서 이벤트 싱크를 선택합니다. 리소스 또는 URI 일 수 있습니다.

   1. 채널, 브로커 또는 서비스를 이벤트 소스의 이벤트 싱크로 사용하려면 리소스 를 선택합니다.
   2. URI 를 선택하여 이벤트가 라우팅되는 URI(Uniform Resource Identifier)를 지정합니다.
3. 생성을 클릭합니다.

1. 개발자 화면에서 토폴로지로 이동합니다.
2. 이벤트 소스를 보고 연결된 이벤트 싱크를 클릭하여 오른쪽 패널에서 싱크 세부 정보를 확인합니다.

프로세스

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 싱크 이름입니다.

프로세스

1. 개발자 화면에서 +추가 보기로 이동합니다.
2. Eventing 카탈로그 에서 이벤트 싱크 를 클릭합니다.
3. 카탈로그 항목에서 KafkaSink 를 검색하고 클릭합니다.
4. 이벤트 싱크 생성을 클릭합니다.

5. 양식 뷰에서 호스트 이름과 포트의 조합인 부트스트랩 서버의 URL을 입력합니다.

   
6. 이벤트 데이터를 보낼 주제의 이름을 입력합니다.
7. 이벤트 싱크의 이름을 입력합니다.
8. 생성을 클릭합니다.

검증

1. 개발자 화면에서 토폴로지 보기로 이동합니다.
2. 생성된 이벤트 싱크를 클릭하여 오른쪽 패널에서 세부 정보를 확인합니다.

프로세스

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 세트를 사용하도록 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 세트를 사용하도록 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>

검증

1. 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

2. 선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.

   

프로세스

1. 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

   트리거에서 이벤트를 전송할 대상 이벤트 싱크 또는 구독자에 대한 세부 정보를 지정합니다.

2. Trigger YAML 파일을 적용합니다.

   $ oc apply -f <filename>

1. 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

2. 선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.

   

1. 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

2. 선택 사항: OpenShift Container Platform 웹 콘솔을 사용하는 경우 개발자 화면에서 토폴로지 보기로 이동하여 브로커가 존재하는지 관찰할 수 있습니다.

   

프로세스

1. 네임스페이스에서 eventing.knative.dev/injection=enabled 라벨을 제거합니다.

   $ oc label namespace <namespace> eventing.knative.dev/injection-

   주석을 제거하면 Knative에서 브로커를 삭제한 후 다시 생성하지 않습니다.

2. 선택한 네임스페이스에서 브로커를 삭제합니다.

   $ oc -n <namespace> delete broker <broker_name>

프로세스

1. 개발자 화면에서 +추가 → 브로커로 이동합니다. 브로커 페이지가 표시됩니다.
2. 선택 사항: 브로커 의 이름을 업데이트합니다. 이름을 업데이트하지 않으면 생성된 브로커의 이름이 default 입니다.
3. 생성을 클릭합니다.

1. 개발자 화면에서 토폴로지로 이동합니다.

2. mt-broker-ingress,mt-broker-filter, mt-broker-controller 구성 요소를 확인합니다.

   

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless → Eventing으로 이동합니다.
2. 생성 목록에서 브로커를 선택합니다. 그러면 브로커 생성 페이지로 이동합니다.
3. 선택 사항: 브로커의 YAML 구성을 수정합니다.
4. 생성을 클릭합니다.

프로세스

1. 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"

2. 구성 맵을 적용합니다.

   $ oc apply -f <config_map_filename>

3. 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
   ...

   1

   브로커 이름입니다.

   2

   브로커가 존재하는 네임스페이스입니다.

   3

   브로커 클래스 주석입니다. 이 예에서 브로커는 클래스 값 Kafka를 사용하는 Kafka 브로커입니다.

   4

   구성 맵 이름입니다.

   5

   구성 맵이 있는 네임스페이스입니다.

4. 브로커를 적용합니다.

   $ oc apply -f <broker_filename>

프로세스

1. 토폴로지 보기에서 생성한 브로커를 가리킵니다. 화살표가 나타납니다. 브로커에 연결하려는 싱크로 화살표를 끕니다. 이 작업은 트리거 추가 대화 상자가 열립니다.
2. 트리거 추가 대화 상자에서 트리거의 이름을 입력하고 추가 를 클릭합니다.

1. 개발자 화면에서 토폴로지로 이동합니다.
2. 브로커를 싱크에 연결하는 행을 클릭하여 세부 정보 패널에서 트리거에 대한 세부 정보를 확인합니다.

프로세스

1. 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
   # ...

   지원되는 소비자 제공 보장은 다음과 같습니다.

   순서가 지정되지 않음

   순서가 지정되지 않은 소비자는 적절한 오프셋 관리를 유지하면서 정렬되지 않은 메시지를 전달하는 비차단 소비자입니다.

   주문됨

   순서가 지정된 소비자는 파티션의 다음 메시지를 전달하기 전에 CloudEvent 구독자의 성공적인 응답을 기다리는 파티션별 차단 소비자입니다.

   기본 주문 보증은 순서가 지정되지 않습니다.

2. Trigger 오브젝트를 적용합니다.

   $ oc apply -f <filename>

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless → Eventing으로 이동합니다.
2. 브로커 탭에서 트리거를 추가할 브로커의 옵션 메뉴 를 선택합니다.
3. 목록에서 트리거 추가를 클릭합니다.
4. 트리거 추가 대화 상자에서 트리거에 대한 구독자를 선택합니다. 구독자는 브로커에서 이벤트를 수신하는 Knative 서비스입니다.
5. 추가를 클릭합니다.

프로세스

1. 개발자 화면에서 토폴로지 페이지로 이동합니다.
2. 트리거를 생성할 브로커 위로 마우스 커서를 이동한 후 화살표를 끕니다. 트리거 추가 옵션이 표시됩니다.
3. 트리거 추가를 클릭합니다.
4. 구독자 목록에서 싱크를 선택합니다.
5. 추가를 클릭합니다.

트리거 삭제

1. 개발자 화면에서 토폴로지 페이지로 이동합니다.
2. 삭제할 트리거를 클릭합니다.
3. 작업 컨텍스트 메뉴에서 트리거 삭제를 선택합니다.

프로세스

1. 사용 가능한 트리거 목록을 인쇄합니다.

   $ kn trigger list

   출력 예

   NAME    BROKER    SINK           AGE   CONDITIONS   READY   REASON
   email   default   ksvc:edisplay   4s    5 OK / 5     True
   ping    default   ksvc:edisplay   32s   5 OK / 5     True

2. 선택 사항: JSON 형식으로 된 트리거 목록을 인쇄합니다.

   $ kn trigger list -o json

검증

1. 기존 트리거를 나열합니다.

   $ kn trigger list

2. 트리거가 더 이상 존재하지 않는지 확인합니다.

   출력 예

   No triggers found.

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless → Eventing으로 이동합니다.
2. 생성 목록에서 채널을 선택합니다. 그러면 채널 페이지로 이동합니다.

3. 유형 목록에서 생성할 Channel 오브젝트 유형을 선택합니다.

   참고

   현재 InMemoryChannel 채널 오브젝트만 기본적으로 지원됩니다. OpenShift Serverless에 Apache Kafka에 Knative 브로커 구현을 설치한 경우 Apache Kafka의 Knative 채널을 사용할 수 있습니다.

4. 생성을 클릭합니다.

프로세스

1. 개발자 화면에서 +추가 → 채널로 이동합니다.
2. 유형 목록에서 생성할 Channel 오브젝트 유형을 선택합니다.
3. 생성을 클릭합니다.

프로세스

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

   apiVersion: messaging.knative.dev/v1
   kind: Channel
   metadata:
     name: example-channel
     namespace: default

2. YAML 파일을 적용합니다.

   $ oc apply -f <filename>

프로세스

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

   apiVersion: messaging.knative.dev/v1beta1
   kind: KafkaChannel
   metadata:
     name: example-channel
     namespace: default
   spec:
     numPartitions: 3
     replicationFactor: 1

   중요

   OpenShift Serverless의 KafkaChannel 오브젝트에 대한 API의 v1beta1 버전만 지원됩니다. 이 버전은 더 이상 사용되지 않으므로 이 API의 v1alpha1 버전을 사용하지 마십시오.

2. KafkaChannel YAML 파일을 적용합니다.

   $ oc apply -f <filename>

프로세스

1. 개발자 화면에서 토폴로지 페이지로 이동합니다.

2. 다음 방법 중 하나를 사용하여 서브스크립션을 생성합니다.

   1. 서브스크립션을 생성할 채널 위로 마우스 커서를 이동하고 화살표를 끕니다. 서브스크립션 추가 옵션이 표시됩니다.

      
      1. 구독자 목록에서 싱크를 선택합니다.
      2. 추가를 클릭합니다.
   2. 채널과 동일한 네임스페이스 또는 프로젝트의 토폴로지 보기에서 서비스를 사용할 수 있는 경우, 서브스크립션을 생성할 채널을 클릭하고 화살표를 서비스로 직접 끌어 채널에서 해당 서비스로의 서브스크립션을 즉시 생성합니다.

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless → Eventing으로 이동합니다.
2. 채널 탭에서 서브스크립션을 추가할 채널의 옵션 메뉴 를 선택합니다.
3. 목록에서 서브스크립션 추가를 클릭합니다.
4. 서브스크립션 추가 대화 상자에서 서브스크립션에 대한 구독자를 선택합니다. 구독자는 채널에서 이벤트를 수신하는 Knative 서비스입니다.
5. 추가를 클릭합니다.

프로세스

1. 선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-file=user.crt=certificate.pem \
     --from-file=user.key=key.pem

   중요

   키 이름 ca.crt,user.crt, user.key를 사용합니다. 이 값은 변경하지 마십시오.

2. KnativeKafka 사용자 정의 리소스 편집을 시작합니다.

   $ oc edit knativekafka

3. 시크릿 및 시크릿의 네임스페이스를 참조합니다.

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     channel:
       authSecretName: <kafka_auth_secret>
       authSecretNamespace: <kafka_auth_secret_namespace>
       bootstrapServers: <bootstrap_servers>
       enabled: true
     source:
       enabled: true

   참고

   부트스트랩 서버에서 일치하는 포트를 지정해야 합니다.

   예를 들면 다음과 같습니다.

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     channel:
       authSecretName: tls-user
       authSecretNamespace: kafka
       bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9094
       enabled: true
     source:
       enabled: true

프로세스

1. 선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.

   $ oc create secret -n <namespace> generic <kafka_auth_secret> \
     --from-file=ca.crt=caroot.pem \
     --from-literal=password="SecretPassword" \
     --from-literal=saslType="SCRAM-SHA-512" \
     --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"

2. KnativeKafka 사용자 정의 리소스 편집을 시작합니다.

   $ oc edit knativekafka

3. 시크릿 및 시크릿의 네임스페이스를 참조합니다.

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     channel:
       authSecretName: <kafka_auth_secret>
       authSecretNamespace: <kafka_auth_secret_namespace>
       bootstrapServers: <bootstrap_servers>
       enabled: true
     source:
       enabled: true

   참고

   부트스트랩 서버에서 일치하는 포트를 지정해야 합니다.

   예를 들면 다음과 같습니다.

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     namespace: knative-eventing
     name: knative-kafka
   spec:
     channel:
       authSecretName: scram-user
       authSecretNamespace: kafka
       bootstrapServers: eventing-kafka-bootstrap.kafka.svc:9093
       enabled: true
     source:
       enabled: true

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 Serverless → Eventing으로 이동합니다.
2. 채널 탭에서 서브스크립션을 추가할 채널의 옵션 메뉴 를 선택합니다.
3. 목록에서 서브스크립션 추가를 클릭합니다.
4. 서브스크립션 추가 대화 상자에서 서브스크립션에 대한 구독자를 선택합니다. 구독자는 채널에서 이벤트를 수신하는 Knative 서비스입니다.
5. 추가를 클릭합니다.

프로세스

1. 개발자 화면에서 토폴로지 페이지로 이동합니다.

2. 다음 방법 중 하나를 사용하여 서브스크립션을 생성합니다.

   1. 서브스크립션을 생성할 채널 위로 마우스 커서를 이동하고 화살표를 끕니다. 서브스크립션 추가 옵션이 표시됩니다.

      
      1. 구독자 목록에서 싱크를 선택합니다.
      2. 추가를 클릭합니다.
   2. 채널과 동일한 네임스페이스 또는 프로젝트의 토폴로지 보기에서 서비스를 사용할 수 있는 경우, 서브스크립션을 생성할 채널을 클릭하고 화살표를 서비스로 직접 끌어 채널에서 해당 서비스로의 서브스크립션을 즉시 생성합니다.

프로세스

1. 터미널에서 사용 가능한 이벤트 소스 유형을 나열합니다.

   $ kn source list-types

   출력 예

   TYPE              NAME                                            DESCRIPTION
   ApiServerSource   apiserversources.sources.knative.dev            Watch and send Kubernetes API events to a sink
   PingSource        pingsources.sources.knative.dev                 Periodically send ping events to a sink
   SinkBinding       sinkbindings.sources.knative.dev                Binding for connecting a PodSpecable to a sink

2. 선택 사항: OpenShift Container Platform에서 사용 가능한 이벤트 소스 유형을 YAML 형식으로 나열할 수도 있습니다.

   $ kn source list-types -o yaml

프로세스

1. 개발자 화면에 액세스합니다.
2. +추가를 클릭합니다.
3. 이벤트 소스 를 클릭합니다.
4. 사용 가능한 이벤트 소스 유형을 확인합니다.

프로세스

1. 터미널에서 기존 이벤트 소스를 나열합니다.

   $ kn source list

   출력 예

   NAME   TYPE              RESOURCE                               SINK         READY
   a1     ApiServerSource   apiserversources.sources.knative.dev   ksvc:eshow2   True
   b1     SinkBinding       sinkbindings.sources.knative.dev       ksvc:eshow3   False
   p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

2. 선택 사항: --type 플래그를 사용하여 특정 유형의 이벤트 소스만 나열할 수 있습니다.

   $ kn source list --type <event_source_type>

   명령 예

   $ kn source list --type PingSource

   출력 예

   NAME   TYPE              RESOURCE                               SINK         READY
   p1     PingSource        pingsources.sources.knative.dev        ksvc:eshow1   True

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 OperatorHub → 설치된 Operator로 이동합니다.
2. knative-serving 네임스페이스를 선택합니다.
3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Eventing을 클릭하여 Knative Eventing 탭으로 이동합니다.

4. knative-eventing을 클릭한 다음 knative-eventing 페이지의 YAML 탭으로 이동합니다.

   

5. KnativeEventing CR의 복제본 수를 수정합니다.

   YAML의 예

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeEventing
   metadata:
     name: knative-eventing
     namespace: knative-eventing
   spec:
     high-availability:
       replicas: 3

프로세스

1. OpenShift Container Platform 웹 콘솔의 관리자 화면에서 OperatorHub → 설치된 Operator로 이동합니다.
2. knative-serving 네임스페이스를 선택합니다.
3. OpenShift Serverless Operator의 제공되는 API 목록에서 Knative Kafka를 클릭하여 Knative Kafka 탭으로 이동합니다.

4. knative-kafka를 클릭한 다음 knative-kafka 페이지의 YAML 탭으로 이동합니다.

   

5. KnativeKafka CR의 복제본 수를 수정합니다.

   YAML의 예

   apiVersion: operator.serverless.openshift.io/v1alpha1
   kind: KnativeKafka
   metadata:
     name: knative-kafka
     namespace: knative-eventing
   spec:
     high-availability:
       replicas: 3