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

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

   $ oc apply -f <filename>

手順

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

   出力例

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

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

   出力例

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

   • --target で指定する現在の ./ ディレクトリーには新しい test/ ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。
   • 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 ./ オプションは、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

   出力例

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

   $ 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. サービスを変更して、追加のコンテナーを追加します。リクエストを処理できるコンテナーは 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

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

   • 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

   この場合、書き込みアクセス権を持つ 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

   1

   ボリュームマウント仕様。

   2

   永続的なボリュームクレームの仕様。

   3

   読み取り専用アクセスを有効にするフラグ。

   注記

   Knative サービスで永続ストレージを正常に使用するには、Knative コンテナーユーザーのユーザー権限などの追加の設定が必要です。

手順

1. 仕様に internal-encryption: "true" フィールドを含む Knative サービスを作成します。

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

   1

   ネットワークポリシーの名前を指定します。

   2

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

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

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

   図4.1 Serverless アプリケーション

   
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 アプリケーションのリビジョン

      

手順

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

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

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

   この時点で、サービスの最初のバージョンと 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
   ...

   YAML リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 番目のリビジョンがステージングされます。トラフィックはメインの URL の 2 番目のリビジョンにルーティングされず、Knative は新たにデプロイされたリビジョンをテストするために v2 という名前の新規サービスを作成します。

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

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

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

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

   リビジョン間でトラフィックを 50/50 に分割する更新サービス仕様の例

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

10. すべてのトラフィックを新しいバージョンのアプリケーションにルーティングできる状態になったら、再度サービスを更新して、100% のトラフィックを 2 番目のリビジョンに送信します。

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

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

   サービスが作成された 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>
      ...

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

   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>

手順

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

   $ export san="knative"

   注記

   これらの証明書が <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

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

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

      KnativeServing CR の例

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

手順

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

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

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

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

   出力例

   Hello Serverless!

   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(),
   )

   注記

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

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

   $ oc apply -f <filename>

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

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

   $ oc apply -f <filename>

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

   1

   システム Pod でメトリクスを収集するためのアプリケーションのパス。

   2

   システム Pod でプローブするアプリケーションのパス。

6. AuthorizationPolicy リソースを適用します。

   $ oc apply -f <filename>

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

8. AuthorizationPolicy リソースを適用します。

   $ oc apply -f <filename>

検証

1. curl 要求を使用して Knative サービス URL を取得しようとすると、これは拒否されます。

   コマンドの例

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

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

   $ oc apply -f <filename>

3. 有効な JSON Web Tokens (JWT) の要求のみを許可する ServiceMeshMemberRoll オブジェクトのメンバーであるサーバーレスアプリケーション namespace でポリシーを作成します。

   重要

   パスの /metrics および /healthz は、knative-serving namespace のシステム 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. curl 要求を使用して Knative サービス URL を取得しようとすると、これは拒否されます。

   $ 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 と同じ namespace に 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 の両方の namespace。

   3

   カスタムドメインにマップするサービス名。

   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. Topology ページに移動します。
2. ドメインにマッピングするサービスを右クリックし、サービス名が含まれる Edit オプションを選択します。たとえば、サービスの名前が example-service である場合は、Edit example-service オプションを選択します。

3. Advanced options セクションで、Show advanced Routing options をクリックします。

   1. サービスにマッピングするドメインマッピング CR がすでに存在する場合は、ドメインマッピング リストで選択できます。
   2. 新規ドメインマッピング CR を作成する場合は、ドメイン名をボックスに入力し、Create オプションを選択します。たとえば、example.com と入力すると、Create オプションは Create "example.com" になります。
4. Save をクリックしてサービスへの変更を保存します。

検証

1. Topology ページに移動します。
2. 作成したサービスをクリックします。
3. サービス情報ウィンドウの Resources タブで、Domain mappings セクションにサービスにマッピングしたドメインが表示されます。

手順

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 の両方の namespace。

   3

   カスタムドメインにマップするサービス名。

   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 などの有用な情報が含まれている可能性があります。

   注記

   Red Hat OpenShift の cert-manager Operator は、テクノロジープレビューの機能です。詳細は、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 Web コンソールの Administrator パースペクティブで、OperatorHub → Installed Operators に移動します。
2. knative-serving namespace を選択します。
3. OpenShift Serverless Operator の Provided 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