2.3. OpenShift Serverless Serving のスケーリングとパフォーマンス

• 170 Knative サービス
• Knative Service ごとに 1 - 2 回の修正
• 主にコントロールプレーンのテストに重点を置いた 89 のテストシナリオ
• Knative Service が削除され、再作成されるシナリオを 48 回再現する
• 41 の安定したシナリオ。リクエストはゆっくりと継続的にシステムに送信されます。

手順

• KnativeServing カスタムリソース (CR) を使用して、最小限のワークロード用に Knative Serving を設定できます。

  KnativeServing CR における最小限のワークロード設定

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 1 

  1

  
    workloads:
      - name: activator
        replicas: 2 

  2

  
        resources:
          - container: activator
            requests:
              cpu: 250m 

  3

  
              memory: 60Mi 

  4

  
            limits:
              cpu: 1000m
              memory: 600Mi
      - name: controller
        replicas: 1 

  5

  
        resources:
          - container: controller
            requests:
              cpu: 10m
              memory: 100Mi
            limits: 

  6

  
              cpu: 200m
              memory: 300Mi
      - name: webhook
        replicas: 2
        resources:
          - container: webhook
            requests:
              cpu: 100m 

  7

  
              memory: 60Mi
            limits:
              cpu: 200m
              memory: 200Mi
    podDisruptionBudgets: 

  8

  
      - name: activator-pdb
        minAvailable: 1
      - name: webhook-pdb
        minAvailable: 1

  Copy to Clipboard Toggle word wrap

  1

  これを 1 に設定すると、すべてのシステムコンポーネントが 1 つのレプリカにスケーリングされます。

  2

  ダウンタイムを回避するために、Activator は常に最低でも 2 つのインスタンスにスケーリングする必要があります。

  3

  Activator CPU リクエストは 250m 未満に設定しないでください。HorizontalPodAutoscaler は、これをスケールアップおよびスケールダウンの基準として使用するためです。

  4

  メモリーリクエストを前の表のアイドル値に調整します。また、予想される負荷に応じてメモリー制限を調整します (最適な値を見つけるにはカスタムテストが必要になる場合があります)。

  5

  最小限のワークロードのシナリオでは、1 つの Webhook と 1 つのコントローラーで十分です。

  6

  これらの制限は、最小限のワークロードのシナリオには十分ですが、具体的なワークロードに応じて調整することを推奨します。

  7

  Webhook CPU リクエストは 100m 未満に設定しないでください。HorizontalPodAutoscaler はこれをスケールアップおよびスケールダウンの基準として使用するためです。

  8

  ノードメンテナンス中に問題が発生しないように、PodDistruptionBudgets を replicas よりも低い値に調整します。

• すべてのデータプレーンコンポーネントは、リクエストやペイロードのシナリオが増えると CPU 使用率が増加するため、CPU リクエストと制限をテストし、必要に応じて増やす必要があります。
• アクティベーターコンポーネントは、より多くの、またはより大きなリクエストペイロードをバッファーリングする必要がある場合、より多くのメモリーを必要とする可能性があるため、メモリーリクエストと制限も同様に増やすことを推奨します。
• 1 つのアクティベーター Pod は、レイテンシーが増加し始め、ある時点でエラーが発生するまで、1 秒あたり約 2500 件のリクエストを処理できます。
• 1 つの 3scale-kourier-gateway または istio-ingressgateway Pod も、レイテンシーが増加し始め、ある時点でエラーが発生する前に、1 秒あたり約 2500 件のリクエストを処理できます。
• 各データプレーンコンポーネントは、1 秒あたり 2500 件のリクエストを処理するために最大 1 仮想 CPU の CPU を消費します。これは、ペイロードサイズと Knative Service バックエンドの応答時間に大きく依存することに注意してください。

手順

• インストールを微調整するには、以前の調査結果と独自のテスト結果を組み合わせて、KnativeServing カスタムリソースを設定します。

  KnativeServing CR での高ワークロード設定

  apiVersion: operator.knative.dev/v1beta1
  kind: KnativeServing
  metadata:
    name: knative-serving
    namespace: knative-serving
  spec:
    high-availability:
      replicas: 2 

  1

  
    workloads:
      - name: component-name 

  2

  
        replicas: 2 

  3

  
        resources:
          - container: container-name
            requests:
              cpu: 

  4

  
              memory:
            limits:
              cpu:
              memory:
    podDisruptionBudgets: 

  5

  
      - name: name-of-pod-disruption-budget
        minAvailable: 1

  Copy to Clipboard Toggle word wrap

  1

  このパラメーターを少なくとも 2 に設定して、すべてのコンポーネントのインスタンスが常に少なくとも 2 つ実行されるようにします。workloads を使用して、特定のコンポーネントのレプリカをオーバーライドすることもできます。

  2

  workloads リストを使用して、特定のコンポーネントを設定します。コンポーネントの deployment 名を使用し、replicas フィールドを設定します。

  3

  Horizontal Pod Autoscaler (HPA) を使用する activator、webhook、および 3scale-kourier-gateway コンポーネントの場合、replicas フィールドでレプリカの最小数を設定します。レプリカの実際の数は、CPU 負荷と HPA によって実行されるスケーリングによって異なります。

  4

  以前の調査結果と独自のテスト結果も考慮しながら、少なくともアイドル時の消費量に応じて、リクエストおよび制限された CPU とメモリーを設定します。

  5

  ノードのメンテナンス中に問題が発生しないように、PodDistruptionBudgets を replicas よりも低い値に調整します。デフォルトの minAvailable は 1 に設定されているため、必要なレプリカを増やす場合は、minAvailable も増やす必要があります。