2.5. カスタム PodSpec 設定


SonataFlow のカスタムリソース (CR) でカスタム PodSpec 設定を使用することで、Red Hat OpenShift 上の特定のコンテナーおよびデプロイメント要件を満たすことができます。

この機能は、以下のような高度な設定に使用できます。

  • CPU とメモリーの要求と制限を設定する
  • サイドカーコンテナーの追加
  • ボリュームとマウントの設定
  • デフォルト以外のデプロイメントモデルを選択する

サーバーレスロジック 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 はデフォルトでそれらを無効にしています。
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

Red Hat ドキュメントについて

Legal Notice

Theme

© 2026 Red Hat
トップに戻る