서빙

절차

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에서 사용할 수 있는지 여부를 제어합니다.

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) 검증이 필요합니다.

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. 서버리스.openshift.io/default-enable-http2=true 주석을 KnativeServing 사용자 정의 리소스에 추가합니다.

   $ oc annotate knativeserving <your_knative_CR> -n knative-serving serverless.openshift.io/default-enable-http2=true

2. 주석을 추가한 후 Kourier 서비스의 appProtocol 값이 h2c 인지 확인할 수 있습니다.

   $ oc get svc -n knative-serving-ingress kourier -o jsonpath="{.spec.ports[0].appProtocol}"

   출력 예

   h2c

3. 이제 외부 트래픽에 HTTP/2 프로토콜을 통해 gRPC 프레임워크를 사용할 수 있습니다. 예를 들면 다음과 같습니다.

   import "google.golang.org/grpc"
   
   grpc.Dial(
      YOUR_URL, 1
      grpc.WithTransportCredentials(insecure.NewCredentials())), 2
   )

   1

   ksvc URL입니다.

   2

   인증서입니다.

절차

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 요청을 수행할 수도 있습니다.

   import "google.golang.org/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 서비스의 준비 상태 프로브로 HTTP 프로브를 사용하므로 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 서비스의 준비 상태 프로브로 HTTP 프로브를 사용하므로 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.com
    namespace: default
   spec:
    ref:
      name: example-service
      kind: Service
      apiVersion: serving.knative.dev/v1

   경로 도메인 매핑 예

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

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

   $ oc apply -f <filename>

절차

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

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

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

검증

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

절차

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>

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

절차

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