서버리스

절차

1. 다음 샘플 코드를 포함하는 YAML 파일을 생성합니다.

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: event-delivery
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. YAML 파일이 포함된 디렉터리로 이동한 후 YAML 파일을 적용하여 애플리케이션을 배포합니다.

   $ oc apply -f <filename>

절차

1. Serverless → Serving 페이지로 이동합니다.
2. 생성 목록에서 서비스를 선택합니다.
3. YAML 또는 JSON 정의를 수동으로 입력하거나 파일을 편집기로 끌어서 놓습니다.
4. 생성을 클릭합니다.

절차

1. 오프라인 모드에서 로컬 Knative 서비스 설명자 파일을 생성합니다.

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest \
       --target ./ \
       --namespace test

   출력 예

   Service 'event-display' created in namespace 'test'.

   • --target ./ 플래그는 오프라인 모드를 활성화하고 새 디렉터리 트리를 저장하는 디렉토리로./를 지정합니다.

     기존 디렉터리를 지정하지 않고 --target my-service.yaml과 같은 파일 이름을 사용하면 디렉터리 트리가 생성되지 않습니다. 대신 서비스 설명자 파일 my-service.yaml만 현재 디렉터리에 생성됩니다.

     파일 이름에는. .yaml, .yml, 또는 .json 확장을 사용할 수 있습니다. .json을 선택하면 JSON 형식으로 서비스 설명자 파일을 생성합니다.

   • --namespace test 옵션은 새 서비스를 test 네임스페이스에 배치합니다.

     --namespace를 사용하지 않고 OpenShift Container Platform 클러스터에 로그인한 경우 현재 네임스페이스에 설명자 파일이 생성됩니다. 그렇지 않으면 설명자 파일이 default 네임스페이스에 생성됩니다.

2. 생성된 디렉터리 구조를 확인합니다.

   $ tree ./

   출력 예

   ./
   └── test
       └── ksvc
           └── event-display.yaml
   
   2 directories, 1 file

   • --target에서 지정된 현재 ./ 디렉터리에는 지정된 네임스페이스를 바탕으로 이름이 지정된 test/ 디렉터리가 포함되어 있습니다.
   • test/ 디렉터리에는 리소스 유형의 이름에 따라 이름이 지정된 ksvc 디렉터리가 포함되어 있습니다.
   • ksvc 디렉터리에는 지정된 서비스 이름에 따라 이름이 지정된 기술자 파일 event-display.yaml이 포함되어 있습니다.

3. 생성된 서비스 기술자 파일을 확인합니다.

   $ cat test/ksvc/event-display.yaml

   출력 예

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     creationTimestamp: null
     name: event-display
     namespace: test
   spec:
     template:
       metadata:
         annotations:
           client.knative.dev/user-image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
         creationTimestamp: null
       spec:
         containers:
         - image: quay.io/openshift-knative/knative-eventing-sources-event-display:latest
           name: ""
           resources: {}
   status: {}

4. 새 서비스에 대한 정보를 나열합니다.

   $ kn service describe event-display --target ./ --namespace test

   출력 예

   Name:       event-display
   Namespace:  test
   Age:
   URL:
   
   Revisions:
   
   Conditions:
     OK TYPE    AGE REASON

   • target ./ 옵션은 네임스페이스 하위 디렉터리를 포함하는 디렉터리 구조의 루트 디렉터리를 지정합니다.

     또는 --target 옵션을 사용하여 YAML 또는 JSON 파일 이름을 직접 지정할 수 있습니다. 허용된 파일 확장자는 .yaml, .yml, .json입니다.

   • --namespace 옵션은 필요한 서비스 기술자 파일을 포함하는 하위 디렉터리를 kn와 통신하는 네임스페이스를 지정합니다.

     --namespace를 사용하지 않고 OpenShift Container Platform 클러스터에 로그인한 경우 kn은 현재 네임스페이스를 바탕으로 이름이 지정된 하위 디렉터리에서 서비스를 검색합니다. 그렇지 않으면 kn은 default/ 하위 디렉터리에서 검색합니다.

5. 서비스 설명자 파일을 사용하여 클러스터에 서비스를 생성합니다.

   $ kn service create -f test/ksvc/event-display.yaml

   출력 예

   Creating service 'event-display' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "event-display" is waiting for a Revision to become ready.
    23.377s ...
    23.419s Ingress has not yet been reconciled.
    23.534s Waiting for load balancer to be ready
    23.723s Ready to serve.
   
   Service 'event-display' created to latest revision 'event-display-00001' is available at URL:
   http://event-display-test.apps.example.com

절차

1. 애플리케이션 URL을 찾습니다.

   $ oc get ksvc <service_name>

   출력 예

   NAME            URL                                        LATESTCREATED         LATESTREADY           READY   REASON
   event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

2. 클러스터에 요청한 후 출력을 확인합니다.

   HTTP 요청의 예

   $ curl http://event-delivery-default.example.com

   HTTPS 요청의 예

   $ curl https://event-delivery-default.example.com

   출력 예

   Hello Serverless!

3. 선택 사항입니다. 인증서 체인에서 자체 서명된 인증서와 관련된 오류가 발생하면 --insecure 플래그를 curl 명령에 추가하여 오류를 무시할 수 있습니다.

   $ curl https://event-delivery-default.example.com --insecure

   출력 예

   Hello Serverless!

   중요

   프로덕션 배포에는 자체 서명된 인증서를 사용해서는 안 됩니다. 이 방법은 테스트 목적으로만 사용됩니다.

4. 선택 사항입니다. OpenShift Container Platform 클러스터가 CA(인증 기관)에서 서명한 인증서로 구성되어 있지만 아직 시스템에 전역적으로 구성되지 않은 경우 curl 명령으로 이 인증서를 지정할 수 있습니다. 인증서 경로는 --cacert 플래그를 사용하여 curl 명령에 전달할 수 있습니다.

   $ curl https://event-delivery-default.example.com --cacert <file>

   출력 예

   Hello Serverless!

절차

1. 추가 컨테이너를 포함하도록 서비스를 수정합니다. 하나의 컨테이너만 요청을 처리할 수 있으므로 정확히 하나의 컨테이너에 대한 포트를 지정합니다. 다음은 두 개의 컨테이너가 있는 구성의 예입니다.

   여러 컨테이너 구성

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
     template:
       spec:
         containers:
           - name: first-container 1
             image: gcr.io/knative-samples/helloworld-go
             ports:
               - containerPort: 8080 2
           - name: second-container 3
             image: gcr.io/knative-samples/helloworld-java

   1

   첫 번째 컨테이너 구성.

   2

   첫 번째 컨테이너의 포트 사양입니다.

   3

   두 번째 컨테이너 구성.

절차

1. Knative Serving에서 PVC를 사용하고 여기에 쓰도록 활성화하려면 다음 YAML을 포함하도록 KnativeServing 사용자 정의 리소스(CR)를 수정합니다.

   쓰기 액세스로 PVC 활성화

   ...
   spec:
     config:
       features:
         "kubernetes.podspec-persistent-volume-claim": enabled
         "kubernetes.podspec-persistent-volume-write": enabled
   ...

   • kubernetes.podspec-persistent-volume-claim 확장은 Knative Serving에서 영구 볼륨(PV)을 사용할 수 있는지 여부를 제어합니다.
   • kubernetes.podspec-persistent-volume-write 확장은 쓰기 액세스 권한으로 Knative Serving에서 PV를 사용할 수 있는지 여부를 제어합니다.

2. PV를 클레임하려면 PV 구성을 포함하도록 서비스를 수정합니다. 예를 들어 다음 구성이 포함된 영구 볼륨 클레임이 있을 수 있습니다.

   참고

   요청하는 액세스 모드를 지원하는 스토리지 클래스를 사용합니다. 예를 들어 ReadWriteMany 액세스 모드에 ocs-storagecluster-cephfs 클래스를 사용할 수 있습니다.

   PersistentVolumeClaim 구성

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: example-pv-claim
     namespace: my-ns
   spec:
     accessModes:
       - ReadWriteMany
     storageClassName: ocs-storagecluster-cephfs
     resources:
       requests:
         storage: 1Gi

   이 경우 쓰기 액세스 권한이 있는 PV를 클레임하려면 다음과 같이 서비스를 수정합니다.

   Knative 서비스 PVC 구성

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     namespace: my-ns
   ...
   spec:
    template:
      spec:
        containers:
            ...
            volumeMounts: 1
              - mountPath: /data
                name: mydata
                readOnly: false
        volumes:
          - name: mydata
            persistentVolumeClaim: 2
              claimName: example-pv-claim
              readOnly: false 3

   1

   볼륨 마운트 사양.

   2

   영구 볼륨 클레임 사양.

   3

   읽기 전용 액세스를 활성화하는 플래그입니다.

   참고

   Knative 서비스에서 영구 스토리지를 성공적으로 사용하려면 Knative 컨테이너 사용자의 사용자 권한과 같은 추가 구성이 필요합니다.

절차

1. 사양에 internal-encryption: "true" 필드를 포함하는 Knative 서비스를 생성합니다.

   ...
   spec:
     config:
       network:
         internal-encryption: "true"
   ...

2. knative-serving 네임스페이스에서 활성화기 Pod를 다시 시작하여 인증서를 로드합니다.

   $ oc delete pod -n knative-serving --selector app=activator

절차

1. 애플리케이션에 액세스해야 하는 각 Knative 시스템 네임스페이스에 knative.openshift.io/system-namespace=true 레이블을 추가합니다.

   1. knative-serving 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-serving knative.openshift.io/system-namespace=true

   2. knative-serving-ingress 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true

   3. knative-eventing 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-eventing knative.openshift.io/system-namespace=true

   4. knative-kafka 네임스페이스에 레이블을 지정합니다.

      $ oc label namespace knative-kafka knative.openshift.io/system-namespace=true

2. 애플리케이션 네임스페이스에 NetworkPolicy 오브젝트를 생성하여 knative.openshift.io/system-namespace 레이블이 있는 네임스페이스에서 액세스를 허용합니다.

   NetworkPolicy 오브젝트 예

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: <network_policy_name> 1
     namespace: <namespace> 2
   spec:
     ingress:
     - from:
       - namespaceSelector:
           matchLabels:
             knative.openshift.io/system-namespace: "true"
     podSelector: {}
     policyTypes:
     - Ingress

   1

   네트워크 정책의 이름을 제공합니다.

   2

   애플리케이션이 존재하는 네임스페이스입니다.

1. Knative 서비스를 클릭하여 측면 패널에서 개요를 확인합니다.

2. 리소스 탭을 클릭하여 서비스의 버전 및 경로로 구성된 목록을 확인합니다.

   그림 4.1. 서버리스 애플리케이션

   
3. 측면 패널 상단에 S 아이콘으로 표시된 서비스를 클릭하여 서비스 세부 정보 개요를 확인합니다.
4. YAML 탭을 클릭하고 YAML 편집기에서 서비스 구성을 수정한 다음 저장을 클릭합니다. 예를 들면 timeoutseconds를 300에서 301로 변경합니다. 이러한 구성 변경으로 인해 새 버전이 트리거됩니다. 토폴로지 보기에 최신 버전이 표시되고 서비스의 리소스 탭에 두 가지 버전이 표시됩니다.

5. 리소스 탭에서 트래픽 배포 설정을 클릭하여 트래픽 분산 대화 상자를 확인합니다.

   1. 분할 필드에 두 버전의 분할 트래픽 백분율 부분을 추가합니다.
   2. 두 버전에 대한 사용자 정의 URL을 생성하도록 태그를 추가합니다.

   3. 저장을 클릭하여 토폴로지 보기에서 두 버전을 나타내는 두 노드를 확인합니다.

      그림 4.2. 서버리스 애플리케이션의 버전

      

절차

1. 애플리케이션을 Knative 서비스로 생성하고 배포합니다.

2. 다음 명령의 출력을 확인하여 서비스를 배포할 때 생성된 첫 번째 버전의 이름을 찾습니다.

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   명령 예

   $ oc get ksvc example-service -o=jsonpath='{.status.latestCreatedRevisionName}'

   출력 예

   $ example-service-00001

3. 다음 YAML을 서비스 spec에 추가하여 인바운드 트래픽을 버전으로 전송합니다.

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic goes to this revision
   ...

4. 다음 명령을 실행하여 얻은 URL 출력에서 앱을 볼 수 있는지 확인합니다.

   $ oc get ksvc <service_name>

5. 서비스의 template 사양에서 하나 이상의 필드를 수정하고 재배포하여 애플리케이션의 두 번째 버전을 배포합니다. 예를 들어 서비스의 image 또는 env 환경 변수를 수정할 수 있습니다. 서비스 YAML 파일을 적용하거나 Knative(kn) CLI를 설치한 경우 kn service update 명령을 사용하여 서비스를 재배포할 수 있습니다.

6. 다음 명령을 실행하여 서비스를 재배포할 때 생성된 두 번째 최신 버전의 이름을 찾습니다.

   $ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'

   이때 서비스의 첫 번째 버전과 두 번째 버전이 모두 배포되고 실행됩니다.

7. 다른 모든 트래픽을 첫 번째 버전으로 전송하면서 두 번째 버전에 대한 새 테스트 끝점을 생성하도록 기존 서비스를 업데이트합니다.

   테스트 끝점을 사용하여 업데이트된 서비스 사양의 예

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 100 # All traffic is still being routed to the first revision
       - revisionName: <second_revision_name>
         percent: 0 # No traffic is routed to the second revision
         tag: v2 # A named route
   ...

   YAML 리소스를 다시 적용하여 이 서비스를 재배포하면 애플리케이션의 두 번째 버전이 준비됩니다. 기본 URL의 두 번째 버전으로 라우팅되는 트래픽이 없으며 Knative는 새로 배포된 버전을 테스트하기 위해 v2라는 새 서비스를 생성합니다.

8. 다음 명령을 실행하여 두 번째 버전에 대한 새 서비스의 URL을 가져옵니다.

   $ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"

   이 URL을 사용하여 트래픽을 라우팅하기 전에 애플리케이션의 새 버전이 예상대로 작동하는지 확인할 수 있습니다.

9. 트래픽의 50%가 첫 번째 버전으로 전송되고 50%가 두 번째 버전으로 전송되도록 기존 서비스를 다시 업데이트합니다.

   버전 간에 트래픽을 50/50으로 분할하는 업데이트된 서비스 사양 분할 예

   ...
   spec:
     traffic:
       - revisionName: <first_revision_name>
         percent: 50
       - revisionName: <second_revision_name>
         percent: 50
         tag: v2
   ...

10. 모든 트래픽을 새 버전의 앱으로 라우팅할 준비가 되면 두 번째 버전으로 트래픽의 100%를 보내도록 서비스를 다시 업데이트합니다.

    두 번째 버전으로 모든 트래픽을 전송하는 업데이트된 서비스 사양의 예

    ...
    spec:
      traffic:
        - revisionName: <first_revision_name>
          percent: 0
        - revisionName: <second_revision_name>
          percent: 100
          tag: v2
    ...

    작은 정보

    버전을 롤백하지 않으려는 경우 첫 번째 버전을 트래픽의 0%로 설정하는 대신 제거할 수 있습니다. 라우팅할 수 없는 버전 오브젝트는 가비지 수집됩니다.

11. 첫 번째 버전의 URL을 방문하여 이전 버전의 앱으로 더 이상 트래픽이 전송되지 않는지 확인합니다.

절차

1. OpenShift Container Platform 경로에 전달할 레이블 또는 주석이 포함된 Knative 서비스를 생성합니다.

   • YAML을 사용하여 서비스를 생성하려면 다음을 수행합니다.

     YAML을 사용하여 생성한 서비스 예

     apiVersion: serving.knative.dev/v1
     kind: Service
     metadata:
       name: <service_name>
       labels:
         <label_name>: <label_value>
       annotations:
         <annotation_name>: <annotation_value>
     ...

   • Knative(kn) CLI를 사용하여 서비스를 생성하려면 다음을 입력합니다.

     kn 명령을 사용하여 생성된 서비스 예

     $ kn service create <service_name> \
       --image=<image> \
       --annotation <annotation_name>=<annotation_value> \
       --label <label_value>=<label_value>

2. 다음 명령의 출력을 확인하여 추가한 주석 또는 레이블을 사용하여 OpenShift Container Platform 경로가 생성되었는지 확인합니다.

   확인을 위한 명령 예

   $ oc get routes.route.openshift.io \
        -l serving.knative.openshift.io/ingressName=<service_name> \ 1
        -l serving.knative.openshift.io/ingressNamespace=<service_namespace> \ 2
        -n knative-serving-ingress -o yaml \
            | grep -e "<label_name>: \"<label_value>\""  -e "<annotation_name>: <annotation_value>" 3

   1

   서비스 이름을 사용합니다.

   2

   서비스가 생성된 네임스페이스를 사용합니다.

   3

   레이블 및 주석 이름과 값의 값을 사용합니다.

절차

1. serving.knative.openshift.io/disableRoute=true 주석이 포함된 Knative 서비스를 생성합니다.

   중요

   serving.knative.openshift.io/disableRoute=true 주석은 OpenShift Serverless에서 경로를 자동으로 생성하지 않도록 지시합니다. 그러나 서비스는 여전히 URL을 표시하며 Ready 상태에 도달합니다. 이 URL은 URL의 호스트 이름과 동일한 호스트 이름으로 자체 경로를 생성할 때까지 외부에서 작동하지 않습니다.

   1. Knative 서비스 리소스를 생성합니다.

      리소스 예

      apiVersion: serving.knative.dev/v1
      kind: Service
      metadata:
        name: <service_name>
        annotations:
          serving.knative.openshift.io/disableRoute: "true"
      spec:
        template:
          spec:
            containers:
            - image: <image>
      ...

   2. Service 리소스를 적용합니다.

      $ oc apply -f <filename>

   3. 선택 사항입니다. kn service create 명령을 사용하여 Knative 서비스를 생성합니다.

      kn 명령 예제

      $ kn service create <service_name> \
        --image=gcr.io/knative-samples/helloworld-go \
        --annotation serving.knative.openshift.io/disableRoute=true

2. 서비스에 OpenShift Container Platform 경로가 생성되지 않았는지 확인합니다.

   명령 예

   $ $ oc get routes.route.openshift.io \
     -l serving.knative.openshift.io/ingressName=$KSERVICE_NAME \
     -l serving.knative.openshift.io/ingressNamespace=$KSERVICE_NAMESPACE \
     -n knative-serving-ingress

   다음 출력이 표시됩니다.

   No resources found in knative-serving-ingress namespace.

3. knative-serving-ingress 네임스페이스에 Route 리소스를 생성합니다.

   apiVersion: route.openshift.io/v1
   kind: Route
   metadata:
     annotations:
       haproxy.router.openshift.io/timeout: 600s 1
     name: <route_name> 2
     namespace: knative-serving-ingress 3
   spec:
     host: <service_host> 4
     port:
       targetPort: http2
     to:
       kind: Service
       name: kourier
       weight: 100
     tls:
       insecureEdgeTerminationPolicy: Allow
       termination: edge 5
       key: |-
         -----BEGIN PRIVATE KEY-----
         [...]
         -----END PRIVATE KEY-----
       certificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE-----
       caCertificate: |-
         -----BEGIN CERTIFICATE-----
         [...]
         -----END CERTIFICATE----
     wildcardPolicy: None

   1

   OpenShift Container Platform 경로에 대한 타임아웃 값입니다. max-revision-timeout-seconds 설정과 동일한 값으로 설정해야 합니다(기본값: 600s).

   2

   OpenShift Container Platform 경로의 이름입니다.

   3

   OpenShift Container Platform 경로의 네임스페이스입니다. knative-serving-ingress여야 합니다.

   4

   외부 액세스를 위한 호스트 이름입니다. 이 값을 <service_name>-<service_namespace>.<domain>으로 설정할 수 있습니다.

   5

   사용할 인증서입니다. 현재는 edge 종료만 지원됩니다.

4. Route 리소스를 적용합니다.

   $ oc apply -f <filename>

절차

1. knative-serving-ingress 네임스페이스에 서버 인증서를 배포합니다.

   $ export san="knative"

   참고

   이러한 인증서가 < app_name>.<namespace>.svc.cluster.local 에 대한 요청을 제공할 수 있도록 SAN(Subject Alternative Name) 검증이 필요합니다.

2. 루트 키 및 인증서를 생성합니다.

   $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
       -subj '/O=Example/CN=Example' \
       -keyout ca.key \
       -out ca.crt

3. SAN 검증을 사용하는 서버 키를 생성합니다.

   $ openssl req -out tls.csr -newkey rsa:2048 -nodes -keyout tls.key \
     -subj "/CN=Example/O=Example" \
     -addext "subjectAltName = DNS:$san"

4. 서버 인증서를 생성합니다.

   $ openssl x509 -req -extfile <(printf "subjectAltName=DNS:$san") \
     -days 365 -in tls.csr \
     -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt

5. Kourier 로컬 게이트웨이의 시크릿을 구성합니다.

   1. 이전 단계에서 생성한 인증서에서 knative-serving-ingress 네임스페이스에 보안을 배포합니다.

      $ oc create -n knative-serving-ingress secret tls server-certs \
          --key=tls.key \
          --cert=tls.crt --dry-run=client -o yaml | oc apply -f -

   2. Kourier 게이트웨이에서 생성한 보안을 사용하도록 KnativeServing CR(사용자 정의 리소스) 사양을 업데이트합니다.

      KnativeServing CR의 예

      ...
      spec:
        config:
          kourier:
            cluster-cert-secret: server-certs
      ...

절차

1. 애플리케이션 호스트를 찾습니다. 서버리스 애플리케이션 배포 확인에 있는 지침을 참조하십시오.

2. 수신 게이트웨이의 공용 주소를 찾습니다.

   $ oc -n knative-serving-ingress get svc kourier

   출력 예

   NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP                                                             PORT(S)                                                                                                                                      AGE
   kourier   LoadBalancer   172.30.51.103   a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com   80:31380/TCP,443:31390/TCP   67m

   공용 주소는 EXTERNAL-IP 필드에 있으며 이 경우 a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com입니다.

3. HTTP 요청의 호스트 헤더를 애플리케이션의 호스트로 수동으로 설정하되 요청 자체는 수신 게이트웨이의 공개 주소로 지정합니다.

   $ curl -H "Host: hello-default.example.com" a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com

   출력 예

   Hello Serverless!

   수신 게이트웨이에 대한 요청을 직접 지시하는 동안 애플리케이션 호스트에 기관을 설정하여 gRPC 요청을 생성할 수도 있습니다.

   grpc.Dial(
       "a83e86291bcdd11e993af02b7a65e514-33544245.us-east-1.elb.amazonaws.com:80",
       grpc.WithAuthority("hello-default.example.com:80"),
       grpc.WithInsecure(),
   )

   참고

   위 예제와 같이 각 포트(기본값 80)를 두 호스트 모두에 추가해야 합니다.

절차

1. 서비스에 sidecar.istio.io/inject="true" 주석을 추가합니다.

   서비스의 예

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   sidecar.istio.io/inject="true" 주석을 추가합니다.

   2

   OpenShift Serverless 버전 1.14.0 이상은 기본적으로 Knative 서비스에 대한 준비 상태 프로브로 사용하므로 Knative 서비스에서 주석 sidecar.istio.io/rewriteAppHTTPProbers: "true" 를 설정해야 합니다.

2. Service 리소스를 적용합니다.

   $ oc apply -f <filename>

3. ServiceMeshMemberRoll 오브젝트의 멤버인 각 서버리스 애플리케이션 네임스페이스에 RequestAuthentication 리소스를 생성합니다.

   apiVersion: security.istio.io/v1beta1
   kind: RequestAuthentication
   metadata:
     name: jwt-example
     namespace: <namespace>
   spec:
     jwtRules:
     - issuer: testing@secure.istio.io
       jwksUri: https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/jwks.json

4. RequestAuthentication 리소스를 적용합니다.

   $ oc apply -f <filename>

5. 다음 AuthorizationPolicy 리소스를 생성하여 ServiceMeshMemberRoll 오브젝트의 멤버인 각 서버리스 애플리케이션 네임스페이스의 시스템 Pod에서 RequestAuthenticaton 리소스에 대한 액세스를 허용합니다.

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allowlist-by-paths
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - to:
       - operation:
           paths:
           - /metrics 1
           - /healthz 2

   1

   시스템 Pod별 지표를 수집하는 애플리케이션의 경로입니다.

   2

   시스템 Pod별로 검색할 애플리케이션의 경로입니다.

6. AuthorizationPolicy 리소스를 적용합니다.

   $ oc apply -f <filename>

7. ServiceMeshMemberRoll 오브젝트의 멤버인 각 서버리스 애플리케이션 네임스페이스에서 다음 AuthorizationPolicy 리소스를 생성합니다.

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: require-jwt
     namespace: <namespace>
   spec:
     action: ALLOW
     rules:
     - from:
       - source:
          requestPrincipals: ["testing@secure.istio.io/testing@secure.istio.io"]

8. AuthorizationPolicy 리소스를 적용합니다.

   $ oc apply -f <filename>

검증

1. Knative 서비스 URL을 가져오기 위해 curl 요청을 사용하면 해당 요청이 거부됩니다.

   명령 예

   $ curl http://hello-example-1-default.apps.mycluster.example.com/

   출력 예

   RBAC: access denied

2. 유효한 JWT로 요청을 확인합니다.

   1. 유효한 JWT 토큰을 가져옵니다.

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.8/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. curl 요청 헤더에 유효한 토큰을 사용하여 서비스에 액세스합니다.

      $ curl -H "Authorization: Bearer $TOKEN"  http://hello-example-1-default.apps.example.com

      그러면 요청이 허용됩니다.

      출력 예

      Hello OpenShift!

절차

1. 서비스에 sidecar.istio.io/inject="true" 주석을 추가합니다.

   서비스의 예

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: <service_name>
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: "true" 1
           sidecar.istio.io/rewriteAppHTTPProbers: "true" 2
   ...

   1

   sidecar.istio.io/inject="true" 주석을 추가합니다.

   2

   OpenShift Serverless 버전 1.14.0 이상은 기본적으로 Knative 서비스에 대한 준비 상태 프로브로 사용하므로 Knative 서비스에서 주석 sidecar.istio.io/rewriteAppHTTPProbers: "true" 를 설정해야 합니다.

2. Service 리소스를 적용합니다.

   $ oc apply -f <filename>

3. 유효한 JWT(JSON 웹 토큰)가 있는 요청만 허용하는 ServiceMeshMemberRoll 오브젝트의 멤버인 서버리스 애플리케이션 네임스페이스에 정책을 생성합니다.

   중요

   /metrics 및 /healthz 경로는 knative-serving 네임스페이스의 시스템 Pod에서 액세스하므로 excludedPaths에 포함되어야 합니다.

   apiVersion: authentication.istio.io/v1alpha1
   kind: Policy
   metadata:
     name: default
     namespace: <namespace>
   spec:
     origins:
     - jwt:
         issuer: testing@secure.istio.io
         jwksUri: "https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/jwks.json"
         triggerRules:
         - excludedPaths:
           - prefix: /metrics 1
           - prefix: /healthz 2
     principalBinding: USE_ORIGIN

   1

   시스템 Pod별 지표를 수집하는 애플리케이션의 경로입니다.

   2

   시스템 Pod별로 검색할 애플리케이션의 경로입니다.

4. Policy 리소스를 적용합니다.

   $ oc apply -f <filename>

검증

1. Knative 서비스 URL을 가져오기 위해 curl 요청을 사용하면 해당 요청이 거부됩니다.

   $ curl http://hello-example-default.apps.mycluster.example.com/

   출력 예

   Origin authentication failed.

2. 유효한 JWT로 요청을 확인합니다.

   1. 유효한 JWT 토큰을 가져옵니다.

      $ TOKEN=$(curl https://raw.githubusercontent.com/istio/istio/release-1.6/security/tools/jwt/samples/demo.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode -

   2. curl 요청 헤더에 유효한 토큰을 사용하여 서비스에 액세스합니다.

      $ curl http://hello-example-default.apps.mycluster.example.com/ -H "Authorization: Bearer $TOKEN"

      그러면 요청이 허용됩니다.

      출력 예

      Hello OpenShift!

절차

1. 매핑하려는 대상 CR과 동일한 네임스페이스에 DomainMapping CR을 포함하는 YAML 파일을 생성합니다.

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   대상 CR에 매핑할 사용자 정의 도메인 이름입니다.

   2

   DomainMapping CR 및 대상 CR의 네임스페이스입니다.

   3

   사용자 정의 도메인에 매핑할 대상 CR의 이름입니다.

   4

   사용자 지정 도메인에 매핑되는 CR 유형입니다.

   서비스 도메인 매핑 예

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example-domain
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

   경로 도메인 매핑 예

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: example-domain
    namespace: default
   spec:
    ref:
      name: example-route
      kind: Route
      apiVersion: serving.knative.dev/v1

2. DomainMapping CR을 YAML 파일로 적용합니다.

   $ oc apply -f <filename>

절차

1. 토폴로지 페이지로 이동합니다.
2. 도메인에 매핑할 서비스를 마우스 오른쪽 버튼으로 클릭하고 서비스 이름이 포함된 Edit (편집) 옵션을 선택합니다. 예를 들어 서비스 이름이 example-service 인 경우 Edit example-service 옵션을 선택합니다.

3. 고급 옵션 섹션에서 고급 라우팅 옵션 표시를 클릭합니다.

   1. 서비스에 매핑할 도메인 매핑 CR이 이미 존재하는 경우 도메인 매핑 목록에서 선택할 수 있습니다.
   2. 새 도메인 매핑 CR을 생성하려면 도메인 이름을 상자에 입력하고 생성 옵션을 선택합니다. 예를 들어 example.com 을 입력하면 Create "example.com" 옵션이 있습니다.
4. 저장을 클릭하여 서비스에 대한 변경 사항을 저장합니다.

검증

1. 토폴로지 페이지로 이동합니다.
2. 생성한 서비스를 클릭합니다.
3. 서비스 정보 창의 Resources 탭에서 도메인 매핑 아래에 나열된 서비스에 매핑한 도메인을 볼 수 있습니다.

절차

1. CustomResourceDefinitions 로 이동하여 검색 상자를 사용하여 DomainMapping CRD(사용자 정의 리소스 정의)를 찾습니다.
2. DomainMapping CRD를 클릭한 다음 Instances (인스턴스) 탭으로 이동합니다.
3. Create DomainMapping 을 클릭합니다.

4. 인스턴스에 대한 다음 정보를 포함하도록 DomainMapping CR의 YAML을 수정합니다.

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: <domain_name> 1
    namespace: <namespace> 2
   spec:
    ref:
      name: <target_name> 3
      kind: <target_type> 4
      apiVersion: serving.knative.dev/v1

   1

   대상 CR에 매핑할 사용자 정의 도메인 이름입니다.

   2

   DomainMapping CR 및 대상 CR의 네임스페이스입니다.

   3

   사용자 정의 도메인에 매핑할 대상 CR의 이름입니다.

   4

   사용자 지정 도메인에 매핑되는 CR 유형입니다.

   Knative 서비스에 대한 도메인 매핑 예

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
    name: custom-ksvc-domain.example.com
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

절차

1. Kubernetes TLS 시크릿을 생성합니다.

   $ oc create secret tls <tls_secret_name> --cert=<path_to_certificate_file> --key=<path_to_key_file>

2. networking.internal.knative.dev/certificate-uid: <id>' 레이블을 Kubernetes TLS 보안에 추가합니다.

   $ oc label secret <tls_secret_name> networking.internal.knative.dev/certificate-uid="<id>"

   cert-manager와 같은 타사 시크릿 공급자를 사용하는 경우, Kubernetes TLS 보안에 자동으로 레이블을 지정하도록 시크릿 관리자를 구성할 수 있습니다. cert-manager 사용자는 제공된 보안 템플릿을 사용하여 올바른 레이블이 있는 보안을 자동으로 생성할 수 있습니다. 이 경우 시크릿 필터링은 키를 기반으로만 수행되지만 이 값은 시크릿에 포함된 인증서 ID와 같은 유용한 정보를 제공할 수 있습니다.

   참고

   cert-manager Operator for Red Hat OpenShift는 기술 프리뷰 기능입니다. 자세한 내용은 Red Hat OpenShift용 cert-manager Operator 설치 설명서를 참조하십시오.

3. 생성한 TLS 보안을 사용하도록 DomainMapping CR을 업데이트합니다.

   apiVersion: serving.knative.dev/v1alpha1
   kind: DomainMapping
   metadata:
     name: <domain_name>
     namespace: <namespace>
   spec:
     ref:
       name: <service_name>
       kind: Service
       apiVersion: serving.knative.dev/v1
   # TLS block specifies the secret to be used
     tls:
       secretName: <tls_secret_name>

검증

1. DomainMapping CR 상태가 True 인지 확인하고 출력의 URL 열에 스키마 https 를 사용하여 매핑된 도메인이 표시되는지 확인합니다.

   $ oc get domainmapping <domain_name>

   출력 예

   NAME                      URL                               READY   REASON
   example.com               https://example.com               True

2. 선택 사항: 서비스가 공개적으로 노출되면 다음 명령을 실행하여 서비스를 사용할 수 있는지 확인합니다.

   $ curl https://<domain_name>

   인증서가 자체 서명된 경우 -k 플래그를 curl 명령에 추가하여 확인을 건너뜁니다.

절차

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

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

   

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

   YAML의 예

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

절차

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일 수 있습니다.
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 서버 소스를 생성합니다. 다음 예에서 sink는 브로커입니다.

   $ 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 <service_name> --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

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

   $ kn trigger create <trigger_name> --sink ksvc:<service_name>

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

   $ oc create deployment hello-node --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

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

1. Pod를 가져옵니다.

   $ oc get pods

2. 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 서버 소스 삭제

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/knative-eventing-sources-event-display:latest

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 hello-node --image=quay.io/openshift-knative/knative-eventing-sources-event-display

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

1. 다음 명령을 입력하여 pod를 가져옵니다.

   $ oc get pods

2. 다음 명령을 입력하여 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 서버 소스 삭제

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/knative-eventing-sources-event-display:latest

   3. 생성을 클릭합니다.

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

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

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

      참고

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

   4. 스케줄 값을 입력합니다. 이 예에서 값은 */2 * * * *이며, 2분마다 메시지를 전송하는 PingSource를 생성합니다.
   5. 선택 사항: 메시지 페이로드에 해당하는 데이터 값을 입력할 수 있습니다.
   6. 싱크를 선택합니다. 리소스 또는 URI일 수 있습니다. 이 예제에서는 이전 단계에서 생성한 event-display 서비스를 리소스 싱크로 사용합니다.
   7. 생성을 클릭합니다.

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

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

   

ping 소스 삭제

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

절차

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

   $ kn service create event-display \
       --image quay.io/openshift-knative/knative-eventing-sources-event-display:latest

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/knative-eventing-sources-event-display:latest

   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일 수 있습니다.
   6. Kafka 이벤트 소스로 이름을 입력합니다.
4. 생성을 클릭합니다.

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

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

   

프로세스

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

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

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

   Apache Kafka용 Red Hat OpenShift Streams와 같은 퍼블릭 클라우드 Kafka 서비스를 사용하는 경우에는 caCert 사양이 필요하지 않습니다.

프로세스

1. +추가 → 이벤트 소스로 이동하여 모든 유형의 이벤트 소스를 생성하고 생성할 이벤트 소스 유형을 선택합니다.
2. 이벤트 소스 생성 양식 보기의 싱크 섹션에서 리소스 목록에서 싱크를 선택합니다.
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 싱크 이름입니다.