5.6. 채널
5.6.1. 채널 및 서브스크립션
채널은 단일 이벤트 전달 및 지속성 계층을 정의하는 사용자 정의 리소스입니다. 이벤트 소스 또는 생산자에서 채널로 이벤트를 보낸 후 서브스크립션을 사용하여 이러한 이벤트를 여러 Knative 서비스 또는 기타 싱크로 보낼 수 있습니다.
지원되는 Channel
오브젝트를 인스턴스화하여 채널을 생성하고 Subscription
오브젝트의 delivery
사양을 수정하여 재전송 시도 횟수를 구성할 수 있습니다.
Channel
오브젝트를 생성한 후에는 변경 승인 Webhook에서 기본 채널 구현을 기반으로 Channel
오브젝트에 일련의 spec.channelTemplate
속성을 추가합니다. 예를 들어 InMemoryChannel
기본 구현의 경우 Channel
오브젝트는 다음과 같습니다.
apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: default spec: channelTemplate: apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel
그런 다음 채널 컨트롤러에서 spec.channelTemplate
구성에 따라 지원 채널 인스턴스를 생성합니다.
spec.channelTemplate
속성은 사용자가 아닌 기본 채널 메커니즘에 의해 설정되기 때문에 생성 후에는 변경할 수 없습니다.
이 메커니즘을 앞의 예제와 함께 사용하면 일반 지원 채널과 InMemoryChannel
채널이라는 두 개의 오브젝트가 생성됩니다. 다른 기본 채널 구현을 사용하는 경우 InMemoryChannel이
구현에 고유한 채널로 교체됩니다. 예를 들어 Knative Kafka를 사용하면 KafkaChannel
채널이 생성됩니다.
지원 채널은 서브스크립션을 사용자가 생성한 채널 오브젝트에 복사하고 지원 채널의 상태를 반영하도록 사용자가 생성한 채널 오브젝트의 상태를 설정하는 프록시 역할을 합니다.
5.6.1.1. 채널 구현 유형
InMemoryChannel
및 KafkaChannel
채널 구현은 OpenShift Serverless에서 개발을 위해 사용할 수 있습니다.
다음은 InMemoryChannel
유형 채널에 대한 제한 사항입니다.
- 이벤트 지속성은 제공되지 않습니다. Pod가 다운되면 해당 Pod의 이벤트도 손실됩니다.
-
InMemoryChannel
채널에서는 이벤트에 순서를 지정하지 않으므로 해당 채널에서 두 개의 이벤트를 동시에 수신하는 경우 이벤트를 순서와 관계없이 구독자에게 전달할 수 있습니다. -
구독자가 이벤트를 거부하면 기본적으로 재전송을 시도하지 않습니다.
Subscription
오브젝트의delivery
사양을 수정하여 재전송 시도 횟수를 구성할 수 있습니다.
5.6.2. 채널 생성
채널은 단일 이벤트 전달 및 지속성 계층을 정의하는 사용자 정의 리소스입니다. 이벤트 소스 또는 생산자에서 채널로 이벤트를 보낸 후 서브스크립션을 사용하여 이러한 이벤트를 여러 Knative 서비스 또는 기타 싱크로 보낼 수 있습니다.
지원되는 Channel
오브젝트를 인스턴스화하여 채널을 생성하고 Subscription
오브젝트의 delivery
사양을 수정하여 재전송 시도 횟수를 구성할 수 있습니다.
5.6.2.1. 관리자 화면을 사용하여 채널 생성
클러스터에 Knative Eventing을 설치한 후 관리자 화면을 사용하여 채널을 생성할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Dedicated 클러스터에 설치되어 있습니다.
- 웹 콘솔에 로그인한 후 관리자 화면에 있습니다.
- OpenShift Dedicated에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
절차
-
OpenShift Dedicated 웹 콘솔의 관리자 화면에서 Serverless
Eventing 으로 이동합니다. - 생성 목록에서 채널을 선택합니다. 그러면 채널 페이지로 이동합니다.
유형 목록에서 생성할
Channel
오브젝트 유형을 선택합니다.참고현재
InMemoryChannel
채널 오브젝트만 기본적으로 지원됩니다. OpenShift Serverless에 Knative Kafka를 설치한 경우 Kafka 채널을 사용할 수 있습니다.- 생성을 클릭합니다.
5.6.2.2. 개발자 화면을 사용하여 채널 생성
OpenShift Dedicated 웹 콘솔을 사용하면 간소화되고 직관적인 사용자 인터페이스를 통해 채널을 생성할 수 있습니다. Knative Eventing이 클러스터에 설치되면 웹 콘솔을 사용하여 채널을 생성할 수 있습니다.
사전 요구 사항
- OpenShift Dedicated 웹 콘솔에 로그인했습니다.
- OpenShift Serverless Operator 및 Knative Eventing이 OpenShift Dedicated 클러스터에 설치되어 있습니다.
- 프로젝트를 생성했거나 OpenShift Dedicated에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
-
개발자 화면에서 +추가
채널로 이동합니다. -
유형 목록에서 생성할
Channel
오브젝트 유형을 선택합니다. - 생성을 클릭합니다.
검증
토폴로지 페이지로 이동하여 채널이 있는지 확인합니다.
5.6.2.3. Knative CLI를 사용하여 채널 생성
Knative(kn
) CLI를 사용하면 YAML 파일을 직접 수정하는 것보다 더 간소화되고 직관적인 사용자 인터페이스를 사용할 수 있습니다. kn channel create
명령을 사용하여 채널을 생성할 수 있습니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 클러스터에 설치되어 있습니다.
-
Knative(
kn
) CLI가 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Dedicated에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
채널을 생성합니다.
$ kn channel create <channel_name> --type <channel_type>
채널 유형은 선택 사항이지만 지정된 위치는
Group:Version:Kind
형식으로 지정해야 합니다. 예를 들면InMemoryChannel
오브젝트를 생성할 수 있습니다.$ kn channel create mychannel --type messaging.knative.dev:v1:InMemoryChannel
출력 예
Channel 'mychannel' created in namespace 'default'.
검증
채널이 존재하는지 확인하려면 기존 채널을 나열하고 출력을 검사합니다.
$ kn channel list
출력 예
kn channel list NAME TYPE URL AGE READY REASON mychannel InMemoryChannel http://mychannel-kn-channel.default.svc.cluster.local 93s True
채널 삭제
채널을 삭제합니다.
$ kn channel delete <channel_name>
5.6.2.4. YAML을 사용하여 기본 구현 채널 생성
YAML 파일을 사용하여 Knative 리소스를 생성하려면 선언적 API를 사용하므로 선언적으로 채널을 재현할 수 있는 방식으로 설명할 수 있습니다. YAML을 사용하여 서버리스 채널을 생성하려면 Channel
오브젝트를 정의하는 YAML 파일을 생성한 다음 oc apply
명령을 사용하여 적용해야 합니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 클러스터에 설치되어 있습니다.
-
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트를 생성했거나 OpenShift Dedicated에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
Channel
오브젝트를 YAML 파일로 생성합니다.apiVersion: messaging.knative.dev/v1 kind: Channel metadata: name: example-channel namespace: default
YAML 파일을 적용합니다.
$ oc apply -f <filename>
5.6.2.5. YAML을 사용하여 Kafka 채널 생성
YAML 파일을 사용하여 Knative 리소스를 생성하려면 선언적 API를 사용하므로 선언적으로 채널을 재현할 수 있는 방식으로 설명할 수 있습니다. Kafka 채널을 생성하여 Kafka 주제에서 지원하는 Knative Eventing 채널을 생성할 수 있습니다. YAML을 사용하여 Kafka 채널을 생성하려면 KafkaChannel
오브젝트를 정의하는 YAML 파일을 생성한 다음 oc apply
명령을 사용하여 적용해야 합니다.
사전 요구 사항
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
사용자 정의 리소스가 OpenShift Dedicated 클러스터에 설치되어 있습니다. -
OpenShift CLI(
oc
)를 설치합니다. - 프로젝트를 생성했거나 OpenShift Dedicated에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
절차
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
버전을 사용하지 마십시오.KafkaChannel
YAML 파일을 적용합니다.$ oc apply -f <filename>
5.6.2.6. 다음 단계
- 채널을 생성한 후 이벤트 싱크에서 채널을 구독하고 이벤트를 수신할 수 있는 서브스크립션을 생성합니다.
- 이벤트를 이벤트 싱크로 전달하지 못하는 경우 적용되는 이벤트 전달 매개변수를 구성합니다. 이벤트 전달 매개변수 구성 예를 참조하십시오.
5.6.3. 기본 채널 구현
default-ch-webhook
구성 맵을 사용하여 Knative Eventing의 기본 채널 구현을 지정할 수 있습니다. 전체 클러스터 또는 하나 이상의 네임스페이스에 대한 기본 채널 구현을 지정할 수 있습니다. 현재 InMemoryChannel
및 KafkaChannel
채널 유형이 지원됩니다.
5.6.3.1. 기본 채널 구현 구성
사전 요구 사항
- OpenShift Dedicated에 대한 관리자 권한이 있습니다.
- OpenShift Serverless Operator 및 Knative Eventing을 클러스터에 설치했습니다.
-
Kafka 채널을 기본 채널 구현으로 사용하려면 클러스터에
KnativeKafka
CR도 설치해야 합니다.
절차
KnativeEventing
사용자 정의 리소스를 수정하여default-ch-webhook
구성 맵에 대한 구성 세부 정보를 추가합니다.apiVersion: operator.knative.dev/v1beta1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: config: 1 default-ch-webhook: 2 default-ch-config: | clusterDefault: 3 apiVersion: messaging.knative.dev/v1 kind: InMemoryChannel spec: delivery: backoffDelay: PT0.5S backoffPolicy: exponential retry: 5 namespaceDefaults: 4 my-namespace: apiVersion: messaging.knative.dev/v1beta1 kind: KafkaChannel spec: numPartitions: 1 replicationFactor: 1
중요네임스페이스별 기본값을 구성하면 클러스터 수준 설정을 덮어씁니다.
5.6.4. Knative Kafka 채널의 보안 구성
5.6.4.1. Kafka 채널에 대한 TLS 인증 구성
TLS( Transport Layer Security )는 Apache Kafka 클라이언트와 서버에서 Knative와 Kafka 간의 트래픽을 암호화하고 인증에 사용됩니다. TLS는 Knative Kafka에 지원되는 유일한 트래픽 암호화 방법입니다.
사전 요구 사항
- OpenShift Dedicated에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
CR이 OpenShift Dedicated 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Dedicated에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
.pem
파일로 저장된 Kafka 클러스터 CA 인증서가 있어야 합니다. -
Kafka 클러스터 클라이언트 인증서와
.pem
파일로 저장된 키가 있습니다. -
OpenShift CLI(
oc
)를 설치합니다.
절차
선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.
$ 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
를 사용합니다. 이 값은 변경하지 마십시오.KnativeKafka
사용자 정의 리소스 편집을 시작합니다.$ oc edit knativekafka
시크릿 및 시크릿의 네임스페이스를 참조합니다.
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
5.6.4.2. Kafka 채널에 대한 SASL 인증 구성
SASL( Simple Authentication and Security Layer )은 Apache Kafka에서 인증을 위해 사용합니다. 클러스터에서 SASL 인증을 사용하는 경우 사용자가 Kafka 클러스터와 통신하기 위해 Knative에 인증 정보를 제공해야 합니다. 그렇지 않으면 이벤트를 생성하거나 사용할 수 없습니다.
사전 요구 사항
- OpenShift Dedicated에 대한 클러스터 또는 전용 관리자 권한이 있습니다.
-
OpenShift Serverless Operator, Knative Eventing,
KnativeKafka
CR이 OpenShift Dedicated 클러스터에 설치되어 있습니다. - 프로젝트를 생성했거나 OpenShift Dedicated에서 애플리케이션 및 기타 워크로드를 생성할 수 있는 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
- Kafka 클러스터의 사용자 이름 및 암호가 있습니다.
-
사용할 SASL 메커니즘을 선택했습니다(예:
PLAIN
,SCRAM-SHA-256
또는SCRAM-SHA-512
). -
TLS가 활성화된 경우 Kafka 클러스터의
ca.crt
인증서 파일도 필요합니다. -
OpenShift CLI(
oc
)를 설치합니다.
절차
선택한 네임스페이스에서 인증서 파일을 시크릿으로 생성합니다.
$ 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"
-
키 이름
KnativeKafka
사용자 정의 리소스 편집을 시작합니다.$ oc edit knativekafka
시크릿 및 시크릿의 네임스페이스를 참조합니다.
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