Serving

手順

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

   Copy to Clipboard Toggle word wrap

2. YAML ファイルが含まれるディレクトリーに移動し、YAML ファイルを適用してアプリケーションをデプロイします。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

手順

1. Serverless → Serving ページに移動します。
2. Create 一覧で、Service を選択します。
3. YAML または JSON 定義を手動で入力するか、またはファイルをエディターにドラッグし、ドロップします。
4. Create をクリックします。

手順

1. オフラインモードでは、ローカルの Knative サービス記述子ファイルを作成します。

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

   Copy to Clipboard Toggle word wrap

   出力例

   Service 'event-display' 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 オプションは、新規サービスを テスト namespace に配置します。

     --namespace を使用せずに OpenShift Container Platform クラスターにログインしていると、記述子ファイルが現在の namespace に作成されます。それ以外の場合は、記述子ファイルが default の namespace に作成されます。

2. 作成したディレクトリー構造を確認します。

   $ tree ./

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

   • --target で指定する現在の ./ ディレクトリーには新しい test/ ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。
   • test/ ディレクトリーには、リソースタイプの名前が付けられた ksvc ディレクトリーが含まれます。
   • ksvc ディレクトリーには、指定のサービス名に従って命名される記述子ファイル event-display.yaml が含まれます。

3. 生成されたサービス記述子ファイルを確認します。

   $ cat test/ksvc/event-display.yaml

   Copy to Clipboard Toggle word wrap

   出力例

   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: {}

   Copy to Clipboard Toggle word wrap

4. 新しいサービスに関する情報を一覧表示します。

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

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

   • --target ./ オプションは、namespace サブディレクトリーを含むディレクトリー構造のルートディレクトリーを指定します。

     または、--target オプションで YAML または JSON ファイルを直接指定できます。使用可能なファイルの拡張子は、.yaml、.yml、および .json です。

   • --namespace オプションは、namespace を指定し、この namespace は必要なサービス記述子ファイルを含むサブディレクトリーの kn と通信します。

     --namespace を使用せず、OpenShift Container Platform クラスターにログインしている場合、kn は現在の namespace にちなんで名付けられたサブディレクトリーでサービスを検索します。それ以外の場合は、kn は default/ サブディレクトリーで検索します。

5. サービス記述子ファイルを使用してクラスターでサービスを作成します。

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

   Copy to Clipboard Toggle word wrap

   出力例

   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

   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
   event-delivery   http://event-delivery-default.example.com   event-delivery-4wsd2   event-delivery-4wsd2   True

   Copy to Clipboard Toggle word wrap

2. クラスターに対して要求を実行し、出力を確認します。

   HTTP 要求の例

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

   Copy to Clipboard Toggle word wrap

   HTTPS 要求の例

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

   Copy to Clipboard Toggle word wrap

   出力例

   Hello Serverless!

   Copy to Clipboard Toggle word wrap

3. オプション:証明書チェーンで自己署名証明書に関連するエラーが発生した場合は、curl コマンドに --insecure フラグを追加して、エラーを無視できます。

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

   Copy to Clipboard Toggle word wrap

   出力例

   Hello Serverless!

   Copy to Clipboard Toggle word wrap

   重要

   自己署名証明書は、実稼働デプロイメントでは使用しないでください。この方法は、テスト目的にのみ使用されます。

4. オプション:OpenShift Container Platform クラスターが認証局 (CA) で署名されているが、システムにグローバルに設定されていない証明書で設定されている場合、curl コマンドでこれを指定できます。証明書へのパスは、--cacert フラグを使用して curl コマンドに渡すことができます。

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

   Copy to Clipboard Toggle word wrap

   出力例

   Hello Serverless!

   Copy to Clipboard Toggle word wrap

手順

1. サービスを変更して、追加のコンテナーを追加します。リクエストを処理できるコンテナーは 1 つだけであるため、ポート は 1 つのコンテナーにのみ指定してください。以下は、2 つのコンテナーの設定例です。

   複数のコンテナー設定

   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

   2 つ目のコンテナー設定。

手順

1. Knative Serving が PVC を使用して書き込むことができるようにするには、KnativeServing カスタムリソース (CR) を変更して次の YAML を含めます。

   書き込みアクセスで 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 拡張機能は、永続ボリューム (PV) を Knative Serving で使用できるかどうかを制御します。
   • 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 を要求するには、次のようにサービスを変更します。

   ネイティブサービス 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. 仕様に internal-encryption: "true" フィールドを含む Knative サービスを作成します。

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

   Copy to Clipboard Toggle word wrap

2. knative-serving namespace でアクティベーター Pod を再起動して、証明書を読み込みます。

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

   Copy to Clipboard Toggle word wrap

手順

1. アプリケーションへのアクセスを必要とする各 Knative システム namespace に knative.openshift.io/system-namespace=true ラベルを追加します。

   1. knative-serving namespace にラベルを付けます。

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

      Copy to Clipboard Toggle word wrap

   2. knative-serving-ingress namespace にラベルを付けます。

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

      Copy to Clipboard Toggle word wrap

   3. knative-eventing namespace にラベルを付けます。

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

      Copy to Clipboard Toggle word wrap

   4. knative-kafka namespace にラベルを付けます。

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

      Copy to Clipboard Toggle word wrap

2. アプリケーション namespace で NetworkPolicy オブジェクトを作成し、knative.openshift.io/system-namespace ラベルのある 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

   アプリケーションが存在する namespace。

1. Knative サービスをクリックし、サイドパネルの概要を表示します。

2. Resources タブをクリックして、サービスの Revisions および Routes の一覧を表示します。

   図4.1 Serverless アプリケーション

   

   View larger image

   
3. サイドパネルの上部にある S アイコンで示されるサービスをクリックし、サービスの詳細の概要を確認します。
4. YAML タブをクリックし、YAML エディターでサービス設定を変更し、Save をクリックします。たとえば、timeoutseconds を 300 から 301 に変更します。この設定の変更により、新規リビジョンがトリガーされます。Topology ビューでは、最新のリビジョンが表示され、サービスの Resources タブに 2 つのリビジョンが表示されるようになります。

5. Resources タブで Set Traffic Distribution をクリックして、トラフィック分配ダイアログボックスを表示します。

   1. Splits フィールドに、2 つのリビジョンのそれぞれの分割されたトラフィックパーセンテージを追加します。
   2. 2 つのリビジョンのカスタム URL を作成するタグを追加します。

   3. Save をクリックし、Topology ビューで 2 つのリビジョンを表す 2 つのノードを表示します。

      図4.2 Serverless アプリケーションのリビジョン

      

      View larger image

      

手順

1. アプリケーションを Knative サービスとして作成し、デプロイします。

2. 以下のコマンドから出力を表示して、サービスのデプロイ時に作成された最初のリビジョンの名前を検索します。

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

   Copy to Clipboard Toggle word wrap

   コマンドの例

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

   Copy to Clipboard Toggle word wrap

   出力例

   $ example-service-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 仕様の少なくとも 1 つのフィールドを変更してアプリケーションの 2 番目のリビジョンをデプロイし、これを再デプロイします。たとえば、サービスの image や env 環境変数を変更できます。サービスの再デプロイは、サービスの YAML ファイルを適用するか、Knative (kn) CLI をインストールしている場合は、kn service update コマンドを使用します。

6. 以下のコマンドを実行して、サービスを再デプロイする際に作成された 2 番目の最新のリビジョンの名前を見つけます。

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

   Copy to Clipboard Toggle word wrap

   この時点で、サービスの最初のバージョンと 2 番目のリビジョンの両方がデプロイされ、実行されます。

7. 既存のサービスを更新して、2 番目のリビジョンの新規テストエンドポイントを作成し、他のすべてのトラフィックを最初のリビジョンに送信します。

   テストエンドポイントのある更新されたサービス仕様の例

   ...
   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 の 2 番目のリビジョンにルーティングされず、Knative は新たにデプロイされたリビジョンをテストするために v2 という名前の新規サービスを作成します。

8. 以下のコマンドを実行して、2 番目のリビジョンの新規サービスの URL を取得します。

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

   Copy to Clipboard Toggle word wrap

   この URL を使用して、トラフィックをルーティングする前に、新しいバージョンのアプリケーションが予想通りに機能していることを検証できます。

9. 既存のサービスを再度更新して、トラフィックの 50% が最初のリビジョンに送信され、50% が 2 番目のリビジョンに送信されます。

   リビジョン間でトラフィックを 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% のトラフィックを 2 番目のリビジョンに送信します。

    すべてのトラフィックを 2 番目のリビジョンに送信する更新済みのサービス仕様の例

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

   サービスが作成された namespace を使用します。

   3

   ラベルおよびアノテーション名および値の値を使用します。

手順

1. serving.knative.openshift.io/disableRoute=true アノテーションが含まれる Knative サービスを作成します。

   重要

   serving.knative.openshift.io/disableRoute=true アノテーションは、OpenShift Serverless に対してルートを自動的に作成しないように指示します。ただし、サービスには URL が表示され、ステータスが Ready に達します。URL のホスト名と同じホスト名を使用して独自のルートを作成するまで、この URL は外部では機能しません。

   1. Service サービスリソースを作成します。

      リソースの例

      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 namespace で 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 ルートの namespace。これは knative-serving-ingress である必要があります。

   4

   外部アクセスのホスト名。これを <service_name>-<service_namespace>.<domain> に設定できます。

   5

   使用する証明書。現時点で、edge termination のみがサポートされています。

4. Route リソースを適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

手順

1. サーバー証明書を knative-serving-ingress namespace にデプロイします。

   $ export san="knative"

   Copy to Clipboard Toggle word wrap
   注記

   これらの証明書が <app_name>.<namespace>.svc.cluster.local への要求を処理できるように、Subject Alternative Name (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. Courier ローカルゲートウェイのシークレットを設定します。

   1. 前の手順で作成した証明書から、knative-serving-ingress namespace にシークレットをデプロイします。

      $ 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. KnativeServing カスタムリソース (CR) 仕様を更新して、Kourier ゲートウェイによって作成されたシークレットを使用します。

      KnativeServing CR の例

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

      Copy to Clipboard Toggle word wrap

手順

1. serverless.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. Ingress ゲートウェイのパブリックアドレスを見つけます。

   $ 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 要求のホストヘッダーを手動でアプリケーションのホストに手動で設定しますが、Ingress ゲートウェイのパブリックアドレスに対して要求自体をダイレクトします。

   $ 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

   Ingress ゲートウェイに対して直接 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 以降では、HTTP プローブをデフォルトで Knative サービスの readiness プローブとして使用することから、Knative サービスでアノテーション sidecar.istio.io/rewriteAppHTTPProbers: "true" を設定する必要があります。

2. Service リソースを適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

3. ServiceMeshMemberRoll オブジェクトのメンバーである各サーバーレスアプリケーション namespace に 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 オブジェクトのメンバーである各サーバーレスアプリケーション namespace のシステム 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 オブジェクトのメンバーであるサーバーレスアプリケーション namespace ごとに、以下の 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. curl 要求を使用して Knative サービス URL を取得しようとすると、これは拒否されます。

   コマンドの例

   $ 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