Serving

手順

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. Create リストで、Service を選択します。
3. YAML または JSON 定義を手動で入力するか、またはファイルをエディターにドラッグし、ドロップします。
4. Create をクリックします。

手順

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

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

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

   $ tree ./

   Copy to Clipboard Toggle word wrap

   出力例

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

   Copy to Clipboard Toggle word wrap

   • --target で指定する現在の ./ ディレクトリーには新しい test/ ディレクトリーが含まれます。このディレクトリーの名前は、指定の namespace をもとに付けられます。
   • 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 ./ オプションは、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/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. サービスを変更して、追加のコンテナーを追加します。リクエストを処理できるコンテナーは 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. KnativeServing CR で multi-container-probing 機能を有効にして、サービスのマルチコンテナープローブを設定します。

   マルチコンテナープロービング設定

   ...
   spec:
     config:
       features:
         "multi-container-probing": enabled 

   1

   
   ...

   Copy to Clipboard Toggle word wrap

   1

   マルチコンテナープローブ機能が有効になる

2. 更新された KnativeServing CR を適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

3. 指定されたプローブが含まれるようにマルチコンテナーサービスを変更します。

   マルチコンテナープロービング

   apiVersion: serving.knative.dev/v1
   kind: Service
   ...
   spec:
    template:
      spec:
        containers:
          - name: first-container
            image: ghcr.io/knative/helloworld-go:latest
            ports:
              - containerPort: 8080
            readinessProbe: 

   1

   
              httpGet:
                port: 8080
          - name: second-container
            image: gcr.io/knative-samples/helloworld-java
            readinessProbe: 

   2

   
              httpGet:
                port: 8090

   Copy to Clipboard Toggle word wrap

   1

   最初のコンテナーの Readines プローブ

   2

   2 番目のコンテナーの Readines プローブ

手順

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 ストレージクラスを使用できます。

   ocs-storagecluster-cephfs ストレージクラスがサポートされており、Red Hat OpenShift Data Foundation から提供されています。

   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. アプリケーションへのアクセスを必要とする各 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. SelfSigned ClusterIssuer カスタムリソース (CR) を作成します。

   ClusterIssuer CR の例

   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: knative-serving-selfsigned-issuer
   spec:
     selfSigned: {}

   Copy to Clipboard Toggle word wrap

2. 次のコマンドを実行して ClusterIssuer CR を適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

3. ClusterIssuer CR を参照するルート証明書を作成します。

   ルート証明書の例

   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: knative-serving-selfsigned-ca
     namespace: cert-manager 

   1

   
   spec:
     secretName: knative-serving-ca 

   2

   
   
     isCA: true
     commonName: selfsigned-ca
     privateKey:
       algorithm: ECDSA
       size: 256
   
     issuerRef:
       name: knative-serving-selfsigned-issuer
       kind: ClusterIssuer
       group: cert-manager.io

   Copy to Clipboard Toggle word wrap

   1

   Red Hat OpenShift namespace の cert-manager Operator (デフォルトでは cert-manager)。

   2

   後で Knative Serving の ClusterIssuer CR に使用されるシークレット名。

4. 次のコマンドを実行して Certificate CR を適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

手順

1. Serving 用の knative-serving-ca-issuer ClusterIssuer を作成します。

   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: knative-serving-ca-issuer
   spec:
     ca:
       secretName: knative-serving-ca 

   1

   Copy to Clipboard Toggle word wrap

   1

   新しい証明書の OpenShift Serverless Serving コンポーネントで使用できる証明書を含む、Red Hat OpenShift namespace の cert-manager Operator 内のシークレット名 (デフォルトでは cert-manager)。

2. 次のコマンドを実行して ClusterIssuer リソースを適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

1. 使用する ClusterIssuer 発行者を指定します。

   • clusterLocalIssuerRef: Ingress に使用される cluster-local-domain 証明書の発行者
   • systemInternalIssuerRef: Knative 内部コンポーネントによって使用される system-internal-tls 証明書の発行者

2. 使用するトランスポート暗号化機能を指定します。

   • cluster-local-domain-tls: cluster-local ドメインのトランスポート暗号化機能の有効化
   • system-internal-tls: OpenShift Serverless Serving 内部コンポーネントのトランスポート暗号化機能を有効にします。

手順

1. KnativeServing リソースでのトランスポート暗号化の有効化

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     ...
     config:
       certmanager:
         clusterLocalIssuerRef: |
           kind: ClusterIssuer
           name: knative-serving-ca-issuer 

   1

   
         systemInternalIssuerRef: |
           kind: ClusterIssuer
           name: knative-serving-ca-issuer 

   2

   
       network:
         cluster-local-domain-tls: Enabled 

   3

   
         system-internal-tls: Enabled 

   4

   Copy to Clipboard Toggle word wrap

   1

   各機能のクラスター発行者を定義します。同じまたは個別のクラスター発行者を使用できます。

   2

   クラスター発行者を定義します。

   3

   cluster-local-domain-tls 機能を有効にします。この機能と他の機能は個別に有効または無効にできます。

   4

   system-internal-tls 機能を有効にします。

2. 次のコマンドを実行して、KnativeServing リソースを適用します。

   $ oc apply -f <filename>

   Copy to Clipboard Toggle word wrap

3. 必要に応じて、Ingress Controller の defaultCertificate 値を変更します。

   apiVersion: operator.openshift.io/v1
   kind: IngressController
    ...
   spec:
     defaultCertificate:
       name: ca-ingress-cert

   Copy to Clipboard Toggle word wrap

4. defaultCertificate 値を変更した場合は、KnativeServing カスタムリソースの openshift-Ingress-default-certificate フィールドにカスタム証明書名を指定する必要があります。

   たとえば、カスタム証明書名が ca-ingress-cert の場合、次の設定を追加します。

   ...
   spec:
     config:
       network:
         system-internal-tls: Enabled
         openshift-ingress-default-certificate: "ca-ingress-cert"
   ...

   Copy to Clipboard Toggle word wrap

5. cluster-local-domain-tls または system-internal-tls を有効にした場合は、次のコマンドを実行して Controller コンポーネントを再起動します。

   重要

   cluster-local-domain-tls または system-internal-tls 機能のいずれかが有効になっている場合は、Knative Serving cert-manager インテグレーションを有効にするために、Controller コンポーネントを再起動する必要があります。

   $ oc rollout restart deploy/controller -n knative-serving

   Copy to Clipboard Toggle word wrap

6. system-internal-tls を有効にした場合は、次のコマンドを実行して Activator コンポーネントを再起動します。

   重要

   system-internal-tls 機能が有効化されている場合、Activator コンポーネントを再起動して内部 Web サーバーを再設定する必要があります (ランタイム時にはできないため)。

   $ oc rollout restart deploy/activator -n knative-serving

   Copy to Clipboard Toggle word wrap

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

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

   図8.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 つのノードを表示します。

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

      

手順

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 仕様の少なくとも 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 リソースを再適用してこのサービスを再デプロイすると、アプリケーションの 2 番目のリビジョンがステージングされます。トラフィックはメインの 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 にアクセスして、アプリケーションの古いバージョンに送信されていないことを確認します。