4.5. 외부 및 Ingress 라우팅

절차

1. OpenShift Dedicated 경로에 전달할 레이블 또는 주석이 포함된 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 Dedicated 경로가 생성되었는지 확인합니다.

   확인을 위한 명령 예

   $ 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 Dedicated 경로가 생성되지 않았는지 확인합니다.

   명령 예

   $ $ 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 Dedicated 경로의 시간 초과 값입니다. max-revision-timeout-seconds 설정과 동일한 값으로 설정해야 합니다(기본값: 600s).

   2

   OpenShift Dedicated 경로의 이름입니다.

   3

   OpenShift Dedicated 경로의 네임스페이스입니다. 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. 애플리케이션 호스트를 찾습니다. 서버리스 애플리케이션 배포 확인에 있는 지침을 참조하십시오.

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)를 두 호스트 모두에 추가해야 합니다.