5.8.2. Knative CLI를 사용하여 API 서버 소스 생성
kn source apiserver create
명령을 사용하여 kn
CLI를 사용하여 API 서버 소스를 생성할 수 있습니다. kn
CLI를 사용하여 API 서버 소스를 생성하면 YAML 파일을 직접 수정하는 것보다 더 효율적이고 직관적인 사용자 인터페이스가 제공됩니다.
사전 요구 사항
- OpenShift Serverless Operator 및 Knative Eventing이 클러스터에 설치되어 있습니다.
- 프로젝트를 생성했거나 OpenShift Container Platform에서 애플리케이션 및 기타 워크로드를 생성하는 데 적절한 역할 및 권한이 있는 프로젝트에 액세스할 수 있습니다.
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
Knative(
kn
) CLI가 설치되어 있습니다.
기존 서비스 계정을 다시 사용하려면 새 리소스를 생성하는 대신 필요한 권한을 포함하도록 기존 ServiceAccount
리소스를 수정할 수 있습니다.
이벤트 소스에 대한 서비스 계정, 역할, 역할 바인딩을 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
YAML 파일을 적용합니다.
$ oc apply -f <filename>
이벤트 싱크가 있는 API 서버 소스를 생성합니다. 다음 예에서 싱크는 브로커입니다.
$ kn source apiserver create <event_source_name> --sink broker:<broker_name> --resource "event:v1" --service-account <service_account_name> --mode Resource
API 서버 소스가 올바르게 설정되었는지 확인하려면 수신되는 메시지를 로그로 덤프하는 Knative 서비스를 생성합니다.
$ kn service create <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
브로커를 이벤트 싱크로 사용한 경우
default
브로커의 이벤트를 서비스에 필터링하는 트리거를 생성합니다.$ kn trigger create <trigger_name> --sink ksvc:<service_name>
기본 네임스페이스에서 Pod를 시작하여 이벤트를 생성합니다.
$ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest
생성된 출력을 다음 명령으로 검사하여 컨트롤러가 올바르게 매핑되는지 확인합니다.
$ 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
검증
메시지 덤퍼 기능 로그를 확인하면 Kubernetes 이벤트가 Knative로 전송되었는지 확인할 수 있습니다.
Pod를 가져옵니다.
$ oc get pods
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.apiserver.resource.update datacontenttype: application/json ... Data, { "apiVersion": "v1", "involvedObject": { "apiVersion": "v1", "fieldPath": "spec.containers{hello-node}", "kind": "Pod", "name": "hello-node", "namespace": "default", ..... }, "kind": "Event", "message": "Started container", "metadata": { "name": "hello-node.159d7608e3a3572c", "namespace": "default", .... }, "reason": "Started", ... }
API 서버 소스 삭제
트리거를 삭제합니다.
$ kn trigger delete <trigger_name>
이벤트 소스를 삭제합니다.
$ kn source apiserver delete <source_name>
서비스 계정, 클러스터 역할, 클러스터 바인딩을 삭제합니다.
$ oc delete -f authentication.yaml
5.8.2.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.local
의svc
는 싱크가 Knative 서비스인지 확인합니다. 기타 기본 싱크 접두사에는channel
, 및broker
가 포함됩니다.