서빙

프로세스

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

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: showcase
     namespace: default
   spec:
     template:
       spec:
         containers:
           - image: quay.io/openshift-knative/showcase
             env:
               - name: GREET
                 value: Bonjour

   Copy to Clipboard Toggle word wrap

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

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

프로세스

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

프로세스

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

   $ kn service create showcase \
       --image quay.io/openshift-knative/showcase \
       --target ./ \
       --namespace test

   Copy to Clipboard Toggle word wrap

   출력 예

   Service 'showcase' created in namespace 'test'.

   Copy to Clipboard Toggle word wrap

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

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

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

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

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

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

   $ tree ./

   Copy to Clipboard Toggle word wrap

   출력 예

   ./
   └── test
       └── ksvc
           └── showcase.yaml
   
   2 directories, 1 file

   Copy to Clipboard Toggle word wrap

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

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

   $ cat test/ksvc/showcase.yaml

   Copy to Clipboard Toggle word wrap

   출력 예

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

   Copy to Clipboard Toggle word wrap

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

   $ kn service describe showcase --target ./ --namespace test

   Copy to Clipboard Toggle word wrap

   출력 예

   Name:       showcase
   Namespace:  test
   Age:
   URL:
   
   Revisions:
   
   Conditions:
     OK TYPE    AGE REASON

   Copy to Clipboard Toggle word wrap

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

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

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

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

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

   $ kn service create -f test/ksvc/showcase.yaml

   Copy to Clipboard Toggle word wrap

   출력 예

   Creating service 'showcase' in namespace 'test':
   
     0.058s The Route is still working to reflect the latest desired specification.
     0.098s ...
     0.168s Configuration "showcase" 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 'showcase' created to latest revision 'showcase-00001' is available at URL:
   http://showcase-test.apps.example.com

   Copy to Clipboard Toggle word wrap

프로세스

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

   $ oc get ksvc <service_name>

   Copy to Clipboard Toggle word wrap

   출력 예

   NAME       URL                                   LATESTCREATED    LATESTREADY      READY   REASON
   showcase   http://showcase-default.example.com   showcase-00001   showcase-00001   True

   Copy to Clipboard Toggle word wrap

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

   HTTP 요청의 예(HTTPie 툴 사용)

   $ http showcase-default.example.com

   Copy to Clipboard Toggle word wrap

   HTTPS 요청의 예

   $ https showcase-default.example.com

   Copy to Clipboard Toggle word wrap

   출력 예

   HTTP/1.1 200 OK
   Content-Type: application/json
   Server: Quarkus/2.13.7.Final-redhat-00003 Java/17.0.7
   X-Config: {"sink":"http://localhost:31111","greet":"Ciao","delay":0}
   X-Version: v0.7.0-4-g23d460f
   content-length: 49
   
   {
       "artifact": "knative-showcase",
       "greeting": "Ciao"
   }

   Copy to Clipboard Toggle word wrap

3. 선택 사항: 시스템에 HTTPie 툴이 설치되어 있지 않은 경우 대신 curl 툴을 사용할 수 있습니다.

   HTTPS 요청의 예

   $ curl http://showcase-default.example.com

   Copy to Clipboard Toggle word wrap

   출력 예

   {"artifact":"knative-showcase","greeting":"Ciao"}

   Copy to Clipboard Toggle word wrap

4. 선택 사항: 인증서 체인에서 자체 서명된 인증서와 관련된 오류가 발생하면 HTTPie 명령에 --verify=no 플래그를 추가하여 오류를 무시할 수 있습니다.

   $ https --verify=no showcase-default.example.com

   Copy to Clipboard Toggle word wrap

   출력 예

   HTTP/1.1 200 OK
   Content-Type: application/json
   Server: Quarkus/2.13.7.Final-redhat-00003 Java/17.0.7
   X-Config: {"sink":"http://localhost:31111","greet":"Ciao","delay":0}
   X-Version: v0.7.0-4-g23d460f
   content-length: 49
   
   {
       "artifact": "knative-showcase",
       "greeting": "Ciao"
   }

   Copy to Clipboard Toggle word wrap

   중요

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

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

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

   Copy to Clipboard Toggle word wrap

   출력 예

   {"artifact":"knative-showcase","greeting":"Ciao"}

   Copy to Clipboard Toggle word wrap

프로세스

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

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   • 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

   Copy to Clipboard Toggle word wrap

   이 경우 쓰기 액세스 권한이 있는 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

   Copy to Clipboard Toggle word wrap

   1

   볼륨 마운트 사양.

   2

   영구 볼륨 클레임 사양.

   3

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

   참고

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

프로세스

1. KnativeServing 리소스를 생성하거나 업데이트하고 사양에 internal-encryption: "true" 필드가 포함되어 있는지 확인합니다.

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

프로세스

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

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

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

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   1

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

   2

   애플리케이션이 있는 네임스페이스입니다.

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

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

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

   

   View larger image

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

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

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

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

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

      

      View larger image

      

프로세스

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

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

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

   Copy to Clipboard Toggle word wrap

   명령 예

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

   Copy to Clipboard Toggle word wrap

   출력 예

   $ showcase-00001

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

   $ oc get ksvc <service_name>

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

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

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

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

   Copy to Clipboard Toggle word wrap

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

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

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

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

   Copy to Clipboard Toggle word wrap

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

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

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

    Copy to Clipboard Toggle word wrap

    작은 정보

    버전을 롤백하지 않으려는 경우 첫 번째 버전을 트래픽의 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>
     ...

     Copy to Clipboard Toggle word wrap

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

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

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

     Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

      Copy to Clipboard Toggle word wrap

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

      $ oc apply -f <filename>

      Copy to Clipboard Toggle word wrap

   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

      Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   다음 출력이 표시됩니다.

   No resources found in knative-serving-ingress namespace.

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   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>

   Copy to Clipboard Toggle word wrap

프로세스

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

   $ export san="knative"

   Copy to Clipboard Toggle word wrap
   참고

   이러한 인증서가 < 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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

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 -

      Copy to Clipboard Toggle word wrap

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

      KnativeServing CR의 예

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

      Copy to Clipboard Toggle word wrap

프로세스

1. 서버리스.openshift.io/default-enable-http2=true 주석을 KnativeServing 사용자 정의 리소스에 추가합니다.

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

   Copy to Clipboard Toggle word wrap

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

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

   Copy to Clipboard Toggle word wrap

   출력 예

   h2c

   Copy to Clipboard Toggle word wrap

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

   import "google.golang.org/grpc"
   
   grpc.Dial(
      YOUR_URL, 

   1

   
      grpc.WithTransportCredentials(insecure.NewCredentials())), 

   2

   
   )

   Copy to Clipboard Toggle word wrap

   1

   ksvc URL.

   2

   인증서입니다.

프로세스

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

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

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

   Copy to Clipboard Toggle word wrap

   출력 예

   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

   Copy to Clipboard Toggle word wrap

   공용 주소는 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

   Copy to Clipboard Toggle word wrap

   출력 예

   Hello Serverless!

   Copy to Clipboard Toggle word wrap

   수신 게이트웨이에 대해 직접 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(),
   )

   Copy to Clipboard Toggle word wrap
   참고

   위 예제와 같이 각 포트(기본값 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

   
   ...

   Copy to Clipboard Toggle word wrap

   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>

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

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

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

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

   Copy to Clipboard Toggle word wrap

   1

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

   2

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

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

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

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"]

   Copy to Clipboard Toggle word wrap

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

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

검증

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

   명령 예

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

   Copy to Clipboard Toggle word wrap

   출력 예

   RBAC: access denied

   Copy to Clipboard Toggle word wrap

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 -

      Copy to Clipboard Toggle word wrap

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

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

      Copy to Clipboard Toggle word wrap

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

      출력 예

      Hello OpenShift!

      Copy to Clipboard Toggle word wrap