This documentation is for a release that is no longer maintained
See documentation for the latest supported version 3 or the latest supported version 4.4.3. Serverless アプリケーションの設定
4.3.1. Knative Serving システムのデプロイメント設定のオーバーライド リンクのコピーリンクがクリップボードにコピーされました!
KnativeServing
カスタムリソース (CR) の deployments
仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。
デプロイメントでデフォルトで定義されているプローブのみをオーバーライドできます。
すべての Knative Serving デプロイメントは、デフォルトで readiness および liveness プローブを定義しますが、次の例外があります。
-
net-kourier-controller
と3scale-kourier-gateway は
readiness プローブのみを定義します。 -
net-istio-controller
とnet-istio-webhook は
プローブを定義しません。
4.3.1.1. システムのデプロイメント設定の上書き リンクのコピーリンクがクリップボードにコピーされました!
現在、resources
、replicas
、labels
、annotations
、nodeSelector
フィールド、およびプローブの readiness
と liveness
フィールドで、デフォルトの構成設定のオーバーライドがサポートされています。
以下の例では、KnativeServing
CR は webhook
デプロイメントをオーバーライドし、以下を確認します。
-
net-kourier-controller
のreadiness
プローブのタイムアウトは 10 秒に設定されています。 - デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
- デプロイメントには 3 つのレプリカがあります。
-
example-label:labellabel
が追加されました。 -
example-annotation: annotation
が追加されます。 -
nodeSelector
フィールドは、disktype: hdd
ラベルを持つノードを選択するように設定されます。
KnativeServing
CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。
KnativeServing CR の例
- 1
readiness
およびliveness
プローブオーバーライドを使用して、プローブハンドラーに関連するフィールド (exec
、grpc
、httpGet
、およびtcpSocket
) を除き、Kubernetes API で指定されているデプロイメントのコンテナー内のプローブのすべてのフィールドをオーバーライドできます。
4.3.2. Serving のマルチコンテナーサポート リンクのコピーリンクがクリップボードにコピーされました!
単一の Knative サービスを使用してマルチコンテナー Pod をデプロイできます。この方法は、アプリケーションの責任を小さな特殊な部分に分割するのに役立ちます。
Serving のマルチコンテナーサポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
4.3.2.1. マルチコンテナーサービスの設定 リンクのコピーリンクがクリップボードにコピーされました!
マルチコンテナーのサポートはデフォルトで有効になっています。サービス内の複数のコンテナーを指定してマルチコンテナー Pod を作成できます。
4.3.3. EmptyDir ボリューム リンクのコピーリンクがクリップボードにコピーされました!
emptyDir
ボリュームは、Pod の作成時に作成される空のボリュームであり、一時的な作業ディスク領域を提供するために使用されます。emptyDir
ボリュームは、それらが作成された Pod が削除されると削除されます。
4.3.3.1. EmptyDir 拡張機能の設定 リンクのコピーリンクがクリップボードにコピーされました!
kubernetes.podspec-volumes-emptydir
の拡張は、emptyDir
ボリュームを Knative Serving で使用できるかどうかを制御します。emptyDir
ボリュームの使用を有効にするには、KnativeServing
カスタムリソース (CR) を変更して以下の YAML を追加する必要があります。
KnativeServing CR の例
4.3.4. 配信のための永続ボリューム要求 リンクのコピーリンクがクリップボードにコピーされました!
一部のサーバーレスアプリケーションには、永続的なデータストレージが必要です。これを実現するために、Knative サービスの永続ボリュームクレーム (PVC) を設定できます。
4.3.4.1. PVC サポートの有効化 リンクのコピーリンクがクリップボードにコピーされました!
手順
Knative Serving が PVC を使用して書き込むことができるようにするには、
KnativeServing
カスタムリソース (CR) を変更して次の YAML を含めます。書き込みアクセスで PVC を有効にする
Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
kubernetes.podspec-persistent-volume-claim
拡張機能は、永続ボリューム (PV) を Knative Serving で使用できるかどうかを制御します。 -
kubernetes.podspec-persistent-volume-write
拡張機能は、書き込みアクセスで Knative Serving が PV を利用できるかどうかを制御します。
-
PV を要求するには、PV 設定を含めるようにサービスを変更します。たとえば、次の設定で永続的なボリュームクレームがある場合があります。
注記要求しているアクセスモードをサポートするストレージクラスを使用してください。たとえば、
ReadWriteMany
アクセスモードのocs-storagecluster-cephfs
クラスを使用できます。PersistentVolumeClaim 設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow この場合、書き込みアクセス権を持つ PV を要求するには、次のようにサービスを変更します。
ネイティブサービス PVC 設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記Knative サービスで永続ストレージを正常に使用するには、Knative コンテナーユーザーのユーザー権限などの追加の設定が必要です。
4.3.5. Init コンテナー リンクのコピーリンクがクリップボードにコピーされました!
Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。KnativeServing
カスタムリソース (CR) を変更することにより、Knative サービスの init コンテナーの使用を有効にできます。
Init コンテナーを使用すると、アプリケーションの起動時間が長くなる可能性があるため、頻繁にスケールアップおよびスケールダウンすることが予想されるサーバーレスアプリケーションには注意して使用する必要があります。
4.3.5.1. init コンテナーの有効化 リンクのコピーリンクがクリップボードにコピーされました!
前提条件
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
- クラスター管理者パーミッションがある。
手順
KnativeServing
CR にkubernetes.podspec-init-containers
フラグを追加して、init コンテナーの使用を有効にします。KnativeServing CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.6. イメージタグのダイジェストへの解決 リンクのコピーリンクがクリップボードにコピーされました!
Knative Serving コントローラーがコンテナーレジストリーにアクセスできる場合、Knative Serving は、サービスのリビジョンを作成するときにイメージタグをダイジェストに解決します。これはタグからダイジェストへの解決と呼ばれ、デプロイメントの一貫性を提供するのに役立ちます。
4.3.6.1. タグからダイジェストへの解決 リンクのコピーリンクがクリップボードにコピーされました!
コントローラーに OpenShift Container Platform のコンテナーレジストリーへのアクセスを許可するには、シークレットを作成してから、コントローラーのカスタム証明書を設定する必要があります。KnativeServing
カスタムリソース (CR) の controller-custom-certs
仕様を変更することにより、コントローラーカスタム証明書を設定できます。シークレットは、KnativeServing
CR と同じ namespace に存在する必要があります。
シークレットが KnativeServing
CR に含まれていない場合、この設定はデフォルトで公開鍵インフラストラクチャー (PKI) を使用します。PKI を使用する場合、クラスター全体の証明書は、config-service-sa
設定マップを使用して KnativeServing コントローラーに自動的に挿入されます。OpenShift Serverless Operator は、config-service-sa
設定 マップにクラスター全体の証明書を設定し、設定マップをボリュームとしてコントローラーにマウントします。
4.3.6.1.1. シークレットを使用したタグからダイジェストへの解決の設定 リンクのコピーリンクがクリップボードにコピーされました!
controller-custom-certs
仕様で Secret
タイプが使用されている場合、シークレットはシークレットボリュームとしてマウントされます。シークレットに必要な証明書があると仮定すると、ネイティブコンポーネントはシークレットを直接消費します。
前提条件
- OpenShift Container Platform のクラスター管理者パーミッションがある。
- OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
手順
シークレットを作成します。
コマンドの例
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Secret
タイプを使用するように、KnativeServing
カスタムリソース (CR) でcontroller-custom-certs
仕様を設定します。KnativeServing CR の例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.7. TLS 認証の設定 リンクのコピーリンクがクリップボードにコピーされました!
Transport Layer Security (TLS) を使用して、Knative トラフィックを暗号化し、認証することができます。
TLS は、Knative Kafka のトラフィック暗号化でサポートされている唯一の方法です。Red Hat は、Knative Kafka リソースに SASL と TLS の両方を一緒に使用することを推奨しています。
Red Hat OpenShift Service Mesh 統合で内部 TLS を有効にする場合は、以下の手順で説明する内部暗号化の代わりに、mTLS で Service Mesh を有効にする必要があります。 mTLS で Service Mesh を使用する場合の Knative Serving メトリクスの有効化 に関するドキュメントを参照してください。
4.3.7.1. 内部トラフィックの TLS 認証を有効にする リンクのコピーリンクがクリップボードにコピーされました!
OpenShift Serverless はデフォルトで TLS エッジターミネーションをサポートしているため、エンドユーザーからの HTTPS トラフィックは暗号化されます。ただし、OpenShift ルートの背後にある内部トラフィックは、プレーンデータを使用してアプリケーションに転送されます。内部トラフィックに対して TLS を有効にすることで、コンポーネント間で送信されるトラフィックが暗号化され、このトラフィックがより安全になります。
Red Hat OpenShift Service Mesh 統合で内部 TLS を有効にする場合は、以下の手順で説明する内部暗号化の代わりに、mTLS で Service Mesh を有効にする必要があります。
内部 TLS 暗号化のサポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat の実稼働環境におけるサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
前提条件
- OpenShift Serverless Operator および Knative Serving がインストールされていること。
-
OpenShift (
oc
) CLI がインストールされている。
手順
仕様に
internal-encryption: "true"
フィールドを含む Knative サービスを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow knative-serving
namespace でアクティベーター Pod を再起動して、証明書を読み込みます。oc delete pod -n knative-serving --selector app=activator
$ oc delete pod -n knative-serving --selector app=activator
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
4.3.8. 制限のあるネットワークポリシー リンクのコピーリンクがクリップボードにコピーされました!
4.3.8.1. 制限のあるネットワークポリシーを持つクラスター リンクのコピーリンクがクリップボードにコピーされました!
複数のユーザーがアクセスできるクラスターを使用している場合、クラスターはネットワークポリシーを使用してネットワーク経由で相互に通信できる Pod、サービス、および namespace を制御する可能性があります。クラスターで制限的なネットワークポリシーを使用する場合は、Knative システム Pod が Knative アプリケーションにアクセスできない可能性があります。たとえば、namespace に、すべての要求を拒否する以下のネットワークポリシーがある場合、Knative システム Pod は Knative アプリケーションにアクセスできません。
namespace へのすべての要求を拒否する NetworkPolicy オブジェクトの例
4.3.8.2. 制限のあるネットワークポリシーを持つクラスターでの Knative アプリケーションとの通信の有効化 リンクのコピーリンクがクリップボードにコピーされました!
Knative システム Pod からアプリケーションへのアクセスを許可するには、ラベルを各 Knative システム namespace に追加し、このラベルを持つ他の namespace の namespace へのアクセスを許可する アプリケーション namespace に NetworkPolicy
オブジェクトを作成する必要があります。
クラスターの非 Knative サービスへの要求を拒否するネットワークポリシーは、これらのサービスへのアクセスを防止するネットワークポリシーです。ただし、Knative システム namespace から Knative アプリケーションへのアクセスを許可することにより、クラスターのすべての namespace から Knative アプリケーションへのアクセスを許可する必要があります。
クラスターのすべての namespace から Knative アプリケーションへのアクセスを許可しない場合は、代わりに Knative サービスの JSON Web Token 認証 を使用するようにしてください。Knative サービスの JSON Web トークン認証にはサービスメッシュが必要です。
前提条件
-
OpenShift CLI (
oc
) をインストールしている。 - OpenShift Serverless Operator および Knative Serving がクラスターにインストールされていること。
手順
アプリケーションへのアクセスを必要とする各 Knative システム namespace に
knative.openshift.io/system-namespace=true
ラベルを追加します。knative-serving
namespace にラベルを付けます。oc label namespace knative-serving knative.openshift.io/system-namespace=true
$ oc label namespace knative-serving knative.openshift.io/system-namespace=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow knative-serving-ingress
namespace にラベルを付けます。oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
$ oc label namespace knative-serving-ingress knative.openshift.io/system-namespace=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow knative-eventing namespace
にラベルを付けます。oc label namespace knative-eventing knative.openshift.io/system-namespace=true
$ oc label namespace knative-eventing knative.openshift.io/system-namespace=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow knative-kafka namespace
にラベルを付けます。oc label namespace knative-kafka knative.openshift.io/system-namespace=true
$ oc label namespace knative-kafka knative.openshift.io/system-namespace=true
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
アプリケーション namespace で
NetworkPolicy
オブジェクトを作成し、knative.openshift.io/system-namespace
ラベルのある namespace からのアクセスを許可します。サンプル
NetworkPolicy
オブジェクトCopy to Clipboard Copied! Toggle word wrap Toggle overflow