Menu Close
Settings Close

Language and Page Formatting Options

第6章 管理

6.1. グローバル設定

OpenShift Serverless Operator は、KnativeServing および KnativeEventing カスタムリソースからシステムの 設定マップ への値の反映を含む Knative インストールのグローバル設定を管理します。手動で適用される設定マップの更新は Operator によって上書きされます。ただし、Knative カスタムリソースを変更すると、これらの設定マップの値を設定できます。

Knative には、名前にプレフィックス config- が付けられた複数の設定マップがあります。すべての Knative 設定マップは、適用するカスタムリソースと同じ namespace に作成されます。たとえば、KnativeServing カスタムリソースが knative-serving namespace に作成される場合、すべての Knative Serving 設定マップもこの namespace に作成されます。

Knative カスタムリソースの spec.config には、設定マップごとにconfig-<name> という名前の <name> エントリーが1つあり、設定マップ data で使用される値を持ちます。

6.1.1. デフォルトチャネル実装の設定

default-ch-webhook 設定マップを使用して、Knative Eventing のデフォルトのチャネル実装を指定できます。デフォルトのチャネル実装は、クラスター全体、および 1 つ以上の namespace に対して指定できます。現在、InMemoryChannel および KafkaChannel チャネルタイプがサポートされています。

前提条件

  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
  • デフォルトのチャネル実装として Kafka チャネルを使用する場合は、クラスターに KnativeKafka CR もインストールする必要があります。

手順

  • KnativeEventing カスタムリソースを変更して、default-ch-webhook 設定マップの設定の詳細を追加します。

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        default-ch-webhook: 2
          default-ch-config: |
            clusterDefault: 3
              apiVersion: messaging.knative.dev/v1
              kind: InMemoryChannel
              spec:
                delivery:
                  backoffDelay: PT0.5S
                  backoffPolicy: exponential
                  retry: 5
            namespaceDefaults: 4
              my-namespace:
                apiVersion: messaging.knative.dev/v1beta1
                kind: KafkaChannel
                spec:
                  numPartitions: 1
                  replicationFactor: 1
    1
    spec.config で、変更した設定を追加する設定マップを指定できます。
    2
    default-ch-webhook 設定マップは、クラスターまたは 1 つ以上の namespace のデフォルトチャネルの実装を指定するために使用できます。
    3
    クラスター全体のデフォルトのチャネルタイプの設定。この例では、クラスターのデフォルトのチャネル実装は InMemoryChannel です。
    4
    namespace スコープのデフォルトのチャネルタイプの設定。この例では、my-namespace namespace のデフォルトのチャネル実装は KafkaChannel です。
    重要

    namespace 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。

6.1.2. scale-to-zero の有効化

Knative Serving は、アプリケーションが受信要求に一致するように、自動スケーリング(autoscaling)を提供します。enable-scale-to-zero 仕様を使用して、クラスター上のアプリケーションの scale-to-zero をグローバルに有効または無効にすることができます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者パーミッション。
  • デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。

手順

  • KnativeServing カスタムリソース (CR) の enable-scale-to-zero 仕様を変更します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          enable-scale-to-zero: "false" 1

    1
    enable-scale-to-zero 仕様は、「true」または「false」 のいずれかです。true に設定すると、scale-to-zero が有効にされます。false に設定すると、アプリケーションは設定された スケーリング下限 にスケールダウンされます。デフォルト値は "true"です。

6.1.3. scale-to-zero 猶予期間の設定

Knative Serving は、アプリケーションの Pod をゼロにスケールダウンします。scale-to-zero-grace-period 仕様を使用して、アプリケーションの最後のレプリカが削除される前に Knative が scale-to-zero 機構が配置されるのを待機する上限時間を定義できます。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者パーミッション。
  • デフォルトの Knative Pod Autoscaler を使用している。Kubernetes Horizontal Pod Autoscaler を使用している場合は、ゼロにスケーリングすることはできません。

手順

  • KnativeServing カスタムリソース CR の scale-to-zero-grace-period 仕様を変更します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          scale-to-zero-grace-period: "30s" 1

    1
    猶予期間(秒単位)。デフォルト値は 30 秒です。

6.1.4. システムのデプロイメント設定の上書き

KnativeServing および KnativeEventing カスタムリソース (CR) で deployments 仕様を変更することにより、一部の特定のデプロイメントのデフォルト設定をオーバーライドできます。

6.1.4.1. Knative Serving システムのデプロイメント設定のオーバーライド

KnativeServing カスタムリソース(CR)の deployments 仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、デフォルトの設定設定のオーバーライドは、resourcereplicalabelsannotations、および nodeSelector フィールドでサポートされています。

以下の例では、KnativeServing CR は webhook デプロイメントをオーバーライドし、以下を確認します。

  • デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
  • デプロイメントには 3 つのレプリカがあります。
  • example-label:labellabel が追加されました。
  • example-annotation: annotation が追加されます。
  • nodeSelector フィールドは、disktype: hdd ラベルを持つノードを選択するように設定されます。
注記

KnativeServing CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。

KnativeServing CR の例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: ks
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  deployments:
  - name: webhook
    resources:
    - container: webhook
      requests:
        cpu: 300m
        memory: 60Mi
      limits:
        cpu: 1000m
        memory: 1000Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

6.1.4.2. Knative Eventing システムのデプロイメント設定のオーバーライド

KnativeEventing カスタムリソース(CR)の deployments 仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、eventing-controllereventing-webhook、および imc-controller フィールドで、デフォルトの設定設定のオーバーライドがサポートされています。

重要

replicas の仕様は、Horizontal Pod Autoscaler (HPA) を使用するデプロイのレプリカの数をオーバーライドできず、eventing-webhook デプロイでは機能しません。

次の例では、KnativeEventing CR が eventing-controller デプロイメントをオーバーライドして、次のようにします。

  • デプロイメントには、CPU およびメモリーのリソース制限が指定されています。
  • デプロイメントには 3 つのレプリカがあります。
  • example-label:labellabel が追加されました。
  • example-annotation: annotation が追加されます。
  • nodeSelector フィールドは、disktype: hdd ラベルを持つノードを選択するように設定されます。

KnativeEventing CR の例

apiVersion: operator.knative.dev/v1beta1
kind: KnativeEventing
metadata:
  name: knative-eventing
  namespace: knative-eventing
spec:
  deployments:
  - name: eventing-controller
    resources:
    - container: eventing-controller
      requests:
        cpu: 300m
        memory: 100Mi
      limits:
        cpu: 1000m
        memory: 250Mi
    replicas: 3
    labels:
      example-label: label
    annotations:
      example-annotation: annotation
    nodeSelector:
      disktype: hdd

注記

KnativeEventing CR ラベルおよびアノテーション設定は、デプロイメント自体と結果として生成される Pod の両方のデプロイメントのラベルおよびアノテーションを上書きします。

6.1.5. EmptyDir 拡張機能の設定

emptyDir ボリュームは、Pod の作成時に作成される空のボリュームであり、一時的な作業ディスク領域を提供するために使用されます。emptyDir ボリュームは、それらが作成された Pod が削除されると削除されます。

kubernetes.podspec-volumes-emptydir の拡張は、emptyDir ボリュームを Knative Serving で使用できるかどうかを制御します。emptyDir ボリュームの使用を有効にするには、KnativeServing カスタムリソース(CR)を変更して以下の YAML を追加する必要があります。

KnativeServing CR の例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    features:
      kubernetes.podspec-volumes-emptydir: enabled
...

6.1.6. HTTPS リダイレクトのグローバル設定

HTTPS リダイレクトは、着信 HTTP リクエストのリダイレクトを提供します。これらのリダイレクトされた HTTP リクエストは暗号化されます。KnativeServing カスタムリソース (CR) の httpProtocol 仕様を設定して、クラスターのすべてのサービスに対して HTTPS リダイレクトを有効にできます。

HTTPS リダイレクトを有効にする KnativeServing CR の例

apiVersion: operator.knative.dev/v1alpha1
kind: KnativeServing
metadata:
  name: knative-serving
spec:
  config:
    network:
      httpProtocol: "redirected"
...

6.1.7. 外部ルートの URL スキームの設定

セキュリティーを強化するために、外部ルートの URL スキームはデフォルトで HTTPS に設定されています。このスキームは、KnativeServingカスタムリソース (CR) 仕様のdefault-external-schemeキーによって決定されます。

デフォルト仕様

...
spec:
  config:
    network:
      default-external-scheme: "https"
...

default-external-schemeキーを変更することにより、HTTP を使用するようにデフォルトの仕様をオーバーライドできます。

HTTP オーバーライド仕様

...
spec:
  config:
    network:
      default-external-scheme: "http"
...

6.1.8. Kourier Gateway サービスタイプの設定

Kourier Gateway は、デフォルトで ClusterIP サービスタイプとして公開されます。このサービスタイプは、KnativeServing カスタムリソース (CR) の service-type 入力仕様によって決定されます。

デフォルト仕様

...
spec:
  ingress:
    kourier:
      service-type: ClusterIP
...

service-type 仕様を変更することで、デフォルトのサービスタイプをオーバーライドして、代わりにロードバランサーサービスタイプを使用できます。

LoadBalancer オーバーライド仕様

...
spec:
  ingress:
    kourier:
      service-type: LoadBalancer
...

6.1.9. PVC サポートの有効化

一部のサーバーレスアプリケーションには、永続的なデータストレージが必要です。これを実現するために、Knative サービスの永続ボリュームクレーム (PVC) を設定できます。

重要

Knative サービスの PVC サポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、開発プロセスの中でお客様に機能性のテストとフィードバックをしていただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

手順

  1. Knative Serving が PVC を使用して書き込むことができるようにするには、KnativeServing カスタムリソース (CR) を変更して次の YAML を含めます。

    書き込みアクセスで PVC を有効にする

    ...
    spec:
      config:
        features:
          "kubernetes.podspec-persistent-volume-claim": enabled
          "kubernetes.podspec-persistent-volume-write": enabled
    ...

    • kubernetes.podspec-persistent-volume-claim 拡張機能は、永続ボリューム (PV) を Knative Serving で使用できるかどうかを制御します。
    • kubernetes.podspec-persistent-volume-write 拡張機能は、書き込みアクセスで Knative Serving が PV を利用できるかどうかを制御します。
  2. PV を要求するには、PV 設定を含めるようにサービスを変更します。たとえば、次の設定で永続的なボリュームクレームがある場合があります。

    注記

    要求しているアクセスモードをサポートするストレージクラスを使用してください。たとえば、ReadWriteMany アクセスモードの ocs-storagecluster-cephfs クラスを使用できます。

    PersistentVolumeClaim 設定

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: example-pv-claim
      namespace: my-ns
    spec:
      accessModes:
        - ReadWriteMany
      storageClassName: ocs-storagecluster-cephfs
      resources:
        requests:
          storage: 1Gi

    この場合、書き込みアクセス権を持つ PV を要求するには、次のようにサービスを変更します。

    ネイティブサービス PVC 設定

    apiVersion: serving.knative.dev/v1
    kind: Service
    metadata:
      namespace: my-ns
    ...
    spec:
     template:
       spec:
         containers:
             ...
             volumeMounts: 1
               - mountPath: /data
                 name: mydata
                 readOnly: false
         volumes:
           - name: mydata
             persistentVolumeClaim: 2
               claimName: example-pv-claim
               readOnly: false 3

    1
    ボリュームマウント仕様。
    2
    永続的なボリュームクレームの仕様。
    3
    読み取り専用アクセスを有効にするフラグ。
    注記

    Knative サービスで永続ストレージを正常に使用するには、Knative コンテナーユーザーのユーザー権限などの追加の設定が必要です。

6.1.10. init コンテナーの有効化

Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。KnativeServing カスタムリソース (CR) を変更することにより、Knative サービスの init コンテナーの使用を有効にできます。

重要

Knative サービスの初期化コンテナーはテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。これらの機能は、近々発表予定の製品機能をリリースに先駆けてご提供することにより、開発プロセスの中でお客様に機能性のテストとフィードバックをしていただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、https://access.redhat.com/ja/support/offerings/techpreview/ を参照してください。

注記

Init コンテナーを使用すると、アプリケーションの起動時間が長くなる可能性があるため、頻繁にスケールアップおよびスケールダウンすることが予想されるサーバーレスアプリケーションには注意して使用する必要があります。

前提条件

  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。
  • クラスター管理者パーミッション。

手順

  • KnativeServing CR に kubernetes.podspec-init-containers フラグを追加して、init コンテナーの使用を有効にします。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        features:
          kubernetes.podspec-init-containers: enabled
    ...

6.1.11. タグからダイジェストへの解決

Knative Serving コントローラーがコンテナーレジストリーにアクセスできる場合、Knative Serving は、サービスのリビジョンを作成するときにイメージタグをダイジェストに解決します。これはタグからダイジェストへの解決と呼ばれ、デプロイメントの一貫性を提供するのに役立ちます。

コントローラーに 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 設定 マップにクラスター全体の証明書を設定し、設定マップをボリュームとしてコントローラーにマウントします。

6.1.11.1. シークレットを使用したタグからダイジェストへの解決の設定

controller-custom-certs 仕様で Secret タイプが使用されている場合、シークレットはシークレットボリュームとしてマウントされます。シークレットに必要な証明書があると仮定すると、ネイティブコンポーネントはシークレットを直接消費します。

前提条件

  • OpenShift Container Platform のクラスター管理者パーミッションがある。
  • OpenShift Serverless Operator および Knative Serving がクラスターにインストールされている。

手順

  1. シークレットを作成します。

    コマンドの例

    $ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>

  2. Secret タイプを使用するように、KnativeServing カスタムリソース (CR) で controller-custom-certs 仕様を設定します。

    KnativeServing CR の例

    apiVersion: operator.knative.dev/v1alpha1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      controller-custom-certs:
        name: custom-secret
        type: Secret

6.1.12. 関連情報