第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/v1beta1
    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. デフォルトのブローカーバッキングチャネルの設定

チャネルベースのブローカーを使用している場合、ブローカーのデフォルトのバッキングチャネルタイプを InMemoryChannel または KafkaChannel に設定できます。

前提条件

  • OpenShift Container Platform に対する管理者権限を持っている。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
  • OpenShift (oc) CLI がインストールされている。
  • Kafka チャネルをデフォルトのバッキングチャネルタイプとして使用する場合は、クラスターに KnativeKafka CR もインストールする必要があります。

手順

  1. KnativeEventing カスタムリソース (CR) を変更して、config-br-default-channel 設定マップの設定の詳細を追加します。

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      config: 1
        config-br-default-channel:
          channel-template-spec: |
            apiVersion: messaging.knative.dev/v1beta1
            kind: KafkaChannel 2
            spec:
              numPartitions: 6 3
              replicationFactor: 3 4
    1
    spec.config で、変更した設定を追加する設定マップを指定できます。
    2
    デフォルトのバッキングチャネルタイプの設定。この例では、クラスターのデフォルトのチャネル実装は KafkaChannel です。
    3
    ブローカーをサポートする Kafka チャネルのパーティションの数。
    4
    ブローカーをサポートする Kafka チャネルのレプリケーションファクター。
  2. 更新された KnativeEventing CR を適用します。

    $ oc apply -f <filename>

6.1.3. デフォルトブローカークラスの設定

config-br-defaults 設定マップを使用して、Knative Eventing のデフォルトのブローカークラス設定を指定できます。クラスター全体または 1 つ以上の namespace に対して、デフォルトのブローカークラスを指定できます。現在、MTChannelBasedBroker および Kafka ブローカータイプがサポートされています。

前提条件

  • OpenShift Container Platform に対する管理者権限を持っている。
  • OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
  • Kafka ブローカーをデフォルトのブローカー実装として使用する場合は、クラスターに KnativeKafka CR もインストールする必要があります。

手順

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

    apiVersion: operator.knative.dev/v1beta1
    kind: KnativeEventing
    metadata:
      name: knative-eventing
      namespace: knative-eventing
    spec:
      defaultBrokerClass: Kafka 1
      config: 2
        config-br-defaults: 3
          default-br-config: |
            clusterDefault: 4
              brokerClass: Kafka
              apiVersion: v1
              kind: ConfigMap
              name: kafka-broker-config 5
              namespace: knative-eventing 6
            namespaceDefaults: 7
              my-namespace:
                brokerClass: MTChannelBasedBroker
                apiVersion: v1
                kind: ConfigMap
                name: config-br-default-channel 8
                namespace: knative-eventing 9
    ...
    1
    Knative Eventing のデフォルトのブローカークラス。
    2
    spec.config で、変更した設定を追加する設定マップを指定できます。
    3
    config-br-defaults 設定マップは、spec.config 設定またはブローカークラスを指定しないブローカーのデフォルト設定を指定します。
    4
    クラスター全体のデフォルトのブローカークラス設定。この例では、クラスターのデフォルトのブローカークラスの実装は Kafka です。
    5
    kafka-broker-config 設定マップは、Kafka ブローカーのデフォルト設定を指定します。「関連情報」セクションの「Kafka ブローカー構成の設定」を参照してください。
    6
    kafka-broker-config 設定マップが存在する namespace。
    7
    namespace スコープのデフォルトブローカクラス設定。この例では、my-namespace namespace のデフォルトのブローカークラスの実装は MTChannelBasedBroker です。複数の namespace に対してデフォルトのブローカークラスの実装を指定できます。
    8
    config-br-default-channel 設定マップは、ブローカーのデフォルトのバッキングチャネルを指定します。「関連情報」セクションの「デフォルトのブローカーバッキングチャネルの設定」を参照してください。
    9
    config-br-default-channel 設定マップが存在する namespace。
    重要

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

6.1.4. 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/v1beta1
    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.5. 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/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
    spec:
      config:
        autoscaler:
          scale-to-zero-grace-period: "30s" 1

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

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

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

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

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

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

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

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

KnativeServing CR の例

apiVersion: operator.knative.dev/v1beta1
kind: KnativeServing
metadata:
  name: ks
  namespace: knative-serving
spec:
  high-availability:
    replicas: 2
  deployments:
  - name: net-kourier-controller
    readinessProbes: 1
      - container: controller
        timeoutSeconds: 10
  - 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

1
readiness および liveness プローブオーバーライドを使用して、プローブハンドラーに関連するフィールド (execgrpchttpGet、および tcpSocket) を除き、Kubernetes API で指定されているデプロイメントのコンテナー内のプローブのすべてのフィールドをオーバーライドできます。

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

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

重要

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

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

  • readiness プローブのタイムアウト eventing-controller は 10 秒に設定されています。
  • デプロイメントには、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
    readinessProbes: 1
      - container: controller
        timeoutSeconds: 10
    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

1
readiness および liveness プローブオーバーライドを使用して、プローブハンドラーに関連するフィールド (execgrpchttpGet、および tcpSocket) を除き、Kubernetes API で指定されているデプロイメントのコンテナー内のプローブのすべてのフィールドをオーバーライドできます。
注記

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

6.1.7. EmptyDir 拡張機能の設定

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

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

KnativeServing CR の例

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

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

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

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

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

6.1.9. 外部ルートの 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.10. 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.11. PVC サポートの有効化

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

手順

  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.12. init コンテナーの有効化

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

注記

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

前提条件

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

手順

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

    KnativeServing CR の例

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

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

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.13.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/v1beta1
    kind: KnativeServing
    metadata:
      name: knative-serving
      namespace: knative-serving
    spec:
      controller-custom-certs:
        name: custom-secret
        type: Secret

6.1.14. 関連情報