Integrations

手順

1. Knative サービスの証明書に署名する root 証明書と秘密鍵を作成します。

   $ openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 \
       -subj '/O=Example Inc./CN=example.com' \
       -keyout root.key \
       -out root.crt

2. ワイルドカード証明書を作成します。

   $ openssl req -nodes -newkey rsa:2048 \
       -subj "/CN=*.apps.openshift.example.com/O=Example Inc." \
       -keyout wildcard.key \
       -out wildcard.csr

3. ワイルドカード証明書を署名します。

   $ openssl x509 -req -days 365 -set_serial 0 \
       -CA root.crt \
       -CAkey root.key \
       -in wildcard.csr \
       -out wildcard.crt

4. ワイルドカード証明書を使用してシークレットを作成します。

   $ oc create -n istio-system secret tls wildcard-certs \
       --key=wildcard.key \
       --cert=wildcard.crt

   この証明書は、OpenShift Serverless をサービスメッシュと統合する際に作成されるゲートウェイによって取得され、Ingress ゲートウェイはこの証明書でトラフィックを提供します。

手順

1. prometheus を Knative Serving カスタムリソース (CR) の observability 仕様で metrics.backend-destination として指定します。

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeServing
   metadata:
     name: knative-serving
     namespace: knative-serving
   spec:
     config:
       observability:
         metrics.backend-destination: "prometheus"
   ...

   この手順により、メトリックがデフォルトで無効になることを防ぎます。

   注記

   ServiceMeshControlPlane を manageNetworkPolicy: false で設定する場合は、適切なイベント配信を確実に行うために、KnativeEventing のアノテーションを使用する必要があります。

   Knative Eventing でも同じメカニズムが使用されます。Knative Eventing のメトリクスを有効にするには、次のように、Knative Eventing カスタムリソース (CR) の observability 仕様で metrics.backend-destination として prometheus を指定する必要があります。

   apiVersion: operator.knative.dev/v1beta1
   kind: KnativeEventing
   metadata:
     name: knative-eventing
     namespace: knative-eventing
   spec:
     config:
       observability:
         metrics.backend-destination: "prometheus"
   ...

2. istio-system namespace のデフォルトのサービスメッシュコントロールプレーンを変更して再適用し、以下の仕様が含まれるようにします。

   ...
   spec:
     proxy:
       networking:
         trafficControl:
           inbound:
             excludedPorts:
             - 8444
   ...

手順

1. テナントのすべての Red Hat OpenShift Serverless プロジェクトがメンバーとして同じ ServiceMeshMemberRoll オブジェクトの一部であることを確認します。

   apiVersion: maistra.io/v1
   kind: ServiceMeshMemberRoll
   metadata:
    name: default
    namespace: istio-system
   spec:
    members:
      - knative-serving    # static value, needs to be here, see setup page
      - knative-eventing   # static value, needs to be here, see setup page
      - team-alpha-1       # example OpenShift project that belongs to the team-alpha tenant
      - team-alpha-2       # example OpenShift project that belongs th the team-alpha tenant
      - team-bravo-1       # example OpenShift project that belongs to the team-bravo tenant
      - team-bravo-2       # example OpenShift project that belongs th the team-bravo tenant

   メッシュの一部であるすべてのプロジェクトは、mTLS を厳密モードで強制する必要があります。これにより、Istio はクライアント証明書が存在する接続のみを受け入れるようになり、Service Mesh サイドカーが AuthorizationPolicy オブジェクトを使用して接続元を検証できるようになります。

2. knative-serving および knative-eventing namespace に AuthorizationPolicy オブジェクトを使用して設定を作成します。

   knative-default-authz-policies.yaml 設定ファイルの例

   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: deny-all-by-default
     namespace: knative-eventing
   spec: { }
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: deny-all-by-default
     namespace: knative-serving
   spec: { }
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-mt-channel-based-broker-ingress-to-imc-dispatcher
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "imc-dispatcher"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-mt-channel-based-broker-ingress-to-kafka-channel
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-channel-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/mt-broker-ingress" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-kafka-channel-to-mt-channel-based-broker-filter
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "broker-filter"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/knative-kafka-channel-data-plane" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-imc-to-mt-channel-based-broker-filter
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "broker-filter"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/imc-dispatcher" ]
         to:
           - operation:
               methods: [ "POST" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-broker-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-broker-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-sink-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-sink-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-probe-kafka-channel-receiver
     namespace: knative-eventing
   spec:
     action: ALLOW
     selector:
       matchLabels:
         app.kubernetes.io/component: "kafka-channel-receiver"
     rules:
       - from:
           - source:
               namespaces: [ "knative-eventing" ]
               principals: [ "cluster.local/ns/knative-eventing/sa/kafka-controller" ]
         to:
           - operation:
               methods: [ "GET" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-traffic-to-activator
     namespace: knative-serving
   spec:
     selector:
       matchLabels:
         app: activator
     action: ALLOW
     rules:
       - from:
           - source:
               namespaces: [ "knative-serving", "istio-system" ]
   ---
   apiVersion: security.istio.io/v1beta1
   kind: AuthorizationPolicy
   metadata:
     name: allow-traffic-to-autoscaler
     namespace: knative-serving
   spec:
     selector:
       matchLabels:
         app: autoscaler
     action: ALLOW
     rules:
       - from:
           - source:
               namespaces: [ "knative-serving" ]

   これらのポリシーは、Serverless システムコンポーネント間のネットワーク通信のアクセスルールを制限します。具体的には、次のルールが適用されます。

   • knative-serving および knative-eventing namespace で明示的に許可されていないすべてのトラフィックを拒否します。
   • istio-system および knative-serving namespace からアクティベーターへのトラフィックを許可する
   • knative-serving namespace からオートスケーラーへのトラフィックを許可する
   • knative-eventing namespace で Apache Kafka コンポーネントの正常性プローブを許可する
   • knative-eventing namespace でチャネルベースのブローカーの内部トラフィックを許可する

3. 認可ポリシー設定を適用します。

   $ oc apply -f knative-default-authz-policies.yaml

4. どの OpenShift プロジェクトが相互に通信できるかを定義します。この通信のために、テナントのすべての OpenShift プロジェクトには以下が必要です。

   • テナントのプロジェクトへの直接受信トラフィックを制限する 1 つの AuthorizationPolicy オブジェクト
   • knative-serving プロジェクトで実行する Serverless のアクティベータコンポーネントを使用して受信トラフィックを制限する 1 つの AuthorizationPolicy オブジェクト
   • Kubernetes が Knative Services で PreStopHooks を呼び出すことを許可する 1 つの AuthorizationPolicy オブジェクト

   これらのポリシーを手動で作成する代わりに、helm ユーティリティーをインストールし、各テナントに必要なリソースを作成します。

   Helm ユーティリティーのインストール

   $ helm repo add openshift-helm-charts https://charts.openshift.io/

   team alpha 用のサンプル設定の作成

   $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.31.0 --set "name=team-alpha" --set "namespaces={team-alpha-1,team-alpha-2}" > team-alpha.yaml

   team bravo の設定例の作成

   $ helm template openshift-helm-charts/redhat-knative-istio-authz --version 1.31.0 --set "name=team-bravo" --set "namespaces={team-bravo-1,team-bravo-2}" > team-bravo.yaml

5. 認可ポリシー設定を適用します。

   $ oc apply -f team-alpha.yaml team-bravo.yaml

手順

1. 両方のテナントの namespace に Knative Services をデプロイします。

   team-alpha のコマンド例

   $ kn service create test-webapp -n team-alpha-1 \
       --annotation-service serving.knative.openshift.io/enablePassthrough=true \
       --annotation-revision sidecar.istio.io/inject=true \
       --env RESPONSE="Hello Serverless" \
       --image docker.io/openshift/hello-openshift

   team-bravo のコマンド例

   $ kn service create test-webapp -n team-bravo-1 \
       --annotation-service serving.knative.openshift.io/enablePassthrough=true \
       --annotation-revision sidecar.istio.io/inject=true \
       --env RESPONSE="Hello Serverless" \
       --image docker.io/openshift/hello-openshift

   あるいは、次の YAML 設定を使用します。

   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: test-webapp
     namespace: team-alpha-1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true"
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
           - image: docker.io/openshift/hello-openshift
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"
   ---
   apiVersion: serving.knative.dev/v1
   kind: Service
   metadata:
     name: test-webapp
     namespace: team-bravo-1
     annotations:
       serving.knative.openshift.io/enablePassthrough: "true"
   spec:
     template:
       metadata:
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
           - image: docker.io/openshift/hello-openshift
             env:
               - name: RESPONSE
                 value: "Hello Serverless!"

2. 接続をテストするために curl Pod をデプロイします。

   $ cat <<EOF | oc apply -f -
   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: curl
     namespace: team-alpha-1
     labels:
       app: curl
   spec:
     replicas: 1
     selector:
       matchLabels:
         app: curl
     template:
       metadata:
         labels:
           app: curl
         annotations:
           sidecar.istio.io/inject: 'true'
       spec:
         containers:
         - name: curl
           image: curlimages/curl
           command:
           - sleep
           - "3600"
   EOF

3. curl コマンドを使用して設定を確認します。

   許可されているクラスターのローカルドメインを介して team-alpha-1 → team-alpha-1 をテストします。

   コマンドの例

   $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-alpha-1:80

   出力例

   HTTP/1.1 200 OK
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:49:59 GMT
   server: envoy
   x-envoy-upstream-service-time: 9
   
   Hello Serverless!

   許可されている外部ドメインを介して team-alpha-1 から team-alpha-1 への接続をテストします。

   コマンドの例

   $ EXTERNAL_URL=$(oc get ksvc -n team-alpha-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
   oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

   出力例

   HTTP/2 200
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:55:30 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 3629
   
   Hello Serverless!

   クラスターのローカルドメインを介して team-alpha-1 から team-bravo-1 への接続をテストしますが、これは許可されていません。

   コマンドの例

   $ oc exec deployment/curl -n team-alpha-1 -it -- curl -v http://test-webapp.team-bravo-1:80

   出力例

   * processing: http://test-webapp.team-bravo-1:80
   *   Trying 172.30.73.216:80...
   * Connected to test-webapp.team-bravo-1 (172.30.73.216) port 80
   > GET / HTTP/1.1
   > Host: test-webapp.team-bravo-1
   > User-Agent: curl/8.2.0
   > Accept: */*
   >
   < HTTP/1.1 403 Forbidden
   < content-length: 19
   < content-type: text/plain
   < date: Wed, 26 Jul 2023 12:55:49 GMT
   < server: envoy
   < x-envoy-upstream-service-time: 6
   <
   * Connection #0 to host test-webapp.team-bravo-1 left intact
   RBAC: access denied

   許可されている外部ドメインを介して、team-alpha-1 から team-bravo-1 への接続をテストします。

   コマンドの例

   $ EXTERNAL_URL=$(oc get ksvc -n team-bravo-1 test-webapp -o custom-columns=:.status.url --no-headers) && \
   oc exec deployment/curl -n team-alpha-1 -it -- curl -ik $EXTERNAL_URL

   出力例

   HTTP/2 200
   content-length: 18
   content-type: text/plain; charset=utf-8
   date: Wed, 26 Jul 2023 12:56:22 GMT
   server: istio-envoy
   x-envoy-upstream-service-time: 2856
   
   Hello Serverless!

4. 検証用に作成されたリソースを削除します。

   $ oc delete deployment/curl -n team-alpha-1 && \
   oc delete ksvc/test-webapp -n team-alpha-1 && \
   oc delete ksvc/test-webapp -n team-bravo-1

手順

1. OpenShift Container Platform Web コンソールの Developer パースペクティブで、+Add に移動し、Import from Git オプションを選択します。

   

2. Import from Git ダイアログで、次の手順を実行してプロジェクトのメタデータを指定します。

   • Git リポジトリー URL を指定します。
   • 必要に応じて、コンテキストディレクトリーを指定します。これは、アプリケーションのソースコードのルートが含まれるリポジトリー内のサブディレクトリーです。
   • オプション: アプリケーション名を指定します。デフォルトでは、リポジトリー名が使用されます。
   • Serverless デプロイメント リソースタイプを選択します。
   • Add pipeline チェックボックスをオンにします。パイプラインはソースコードに基づいて自動的に選択され、その視覚化がスキーム上に表示されます。

   • その他の関連設定を指定します。

     
3. Create をクリックしてサービスを作成します。

4. サービスの作成が開始すると、Topology 画面に移動します。この画面では、サービスと関連するトリガーが視覚化され、それらを操作できます。

   

5. オプション: Pipelines ページに移動して、パイプラインが作成され、サービスが構築およびデプロイされていることを確認します。

   

6. パイプラインの詳細を表示するには、Pipelines ページでパイプラインをクリックします。

   

7. 現在のパイプライン実行の詳細を表示するには、Pipelines ページで実行の名前をクリックします。

   

手順

1. Knative サービスを作成し、--limit nvidia.com/gpu=1 フラグを使用して、GPU リソース要件の制限を 1 に設定します。

   $ kn service create hello --image <service-image> --limit nvidia.com/gpu=1

   GPU リソース要件の制限が 1 の場合、サービスには専用の GPU リソースが 1 つ必要です。サービスは、GPU リソースを共有しません。GPU リソースを必要とするその他のサービスは、GPU リソースが使用されなくなるまで待機する必要があります。

   1 GPU の制限は、1 GPU リソースの使用を超えるアプリケーションが制限されることも意味します。サービスが 2 つ以上の GPU リソースを要求する場合、これは GPU リソース要件を満たしているノードにデプロイされます。

2. オプション: 既存のサービスの場合は、--limit nvidia.com/gpu=3 フラグを使用して、GPU リソース要件の制限を 3 に変更できます。

   $ kn service update hello --limit nvidia.com/gpu=3