2.5. カスタム PodSpec 設定
SonataFlow のカスタムリソース (CR) でカスタム PodSpec 設定を使用することで、Red Hat OpenShift 上の特定のコンテナーおよびデプロイメント要件を満たすことができます。
この機能は、以下のような高度な設定に使用できます。
- CPU とメモリーの要求と制限を設定する
- サイドカーコンテナーの追加
- ボリュームとマウントの設定
- デフォルト以外のデプロイメントモデルを選択する
OpenShift Serverless Logic Operator は、SonataFlow CR 内の .spec.podTemplate 属性を通じてこれらのカスタマイズを可能にします。
以下の例は、定義されたリソース要求と制限、およびワークフローコンテナーの環境変数を含む SonataFlow CR を示しています。
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
name: <name>
spec:
podTemplate:
container:
resources:
limits:
cpu: "250m"
memory: "128Mi"
requests:
cpu: "100m"
memory: "64Mi"
env:
- name: EXAMPLE_VAR
value: "value"
# ...
.spec.podTemplate 属性は、標準の Kubernetes PodSpec API で定義されているほとんどのフィールドをサポートしており、Kubernetes API の検証ルールが適用されます。
2.5.1. K ネイティブデプロイメントモデル リンクのコピーリンクがクリップボードにコピーされました!
デフォルトでは、各 SonataFlow インスタンスは Kubernetes デプロイメント オブジェクトとしてデプロイされます。インスタンスを Knative Serving Service オブジェクトとしてデプロイするには、.spec.podTemplate.deploymentModel フィールドを knative に設定します。
以下に例を示します。
apiVersion: sonataflow.org/v1alpha08
kind: SonataFlow
metadata:
name: <name>
spec:
podTemplate:
deploymentModel: knative
# ...
- 開発 プロファイルでは、Knative のデプロイメントモデルを使用しないでください。このオプションを指定しても、Operator はそれを無視します。
- Knative はアイドル状態の Pod を終了させることができ、これにより長時間実行されるワークフローが中断されたり、外部サービスが遅くなったりする可能性があります。
- コールバック状態を使用するワークフローの永続性を有効にし、Pod の終了後もワークフローを再開できるようにします。
-
ワークフローで必要な場合は、
initContainers を明示的に有効にしてください。Knative はデフォルトでそれらを無効にしています。