第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
重要namespace 固有のデフォルトを設定すると、クラスター全体の設定が上書きされます。
6.1.2. デフォルトのブローカーバッキングチャネルの設定
チャネルベースのブローカーを使用している場合、ブローカーのデフォルトのバッキングチャネルタイプを InMemoryChannel
または KafkaChannel
に設定できます。
前提条件
- OpenShift Container Platform に対する管理者権限を持っている。
- OpenShift Serverless Operator および Knative Eventing がクラスターにインストールされていること。
-
OpenShift (
oc
) CLI がインストールされている。 -
Kafka チャネルをデフォルトのバッキングチャネルタイプとして使用する場合は、クラスターに
KnativeKafka
CR もインストールする必要があります。
手順
KnativeEventing
カスタムリソース (CR) を変更して、config-br-default-channel
設定マップの設定の詳細を追加します。apiVersion: operator.knative.dev/v1alpha1 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
更新された
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/v1alpha1 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/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.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/v1alpha1 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
仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、デフォルトの設定設定のオーバーライドは、resource
、replica
、labels
、annotations
、および 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.6.2. Knative Eventing システムのデプロイメント設定のオーバーライド
KnativeEventing
カスタムリソース (CR) の deployments
仕様を変更することで、特定のデプロイメントのデフォルト設定を上書きできます。現在、eventing-controller
、eventing-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.7. 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.8. 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.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) を設定できます。
Knative サービスの PVC サポートは、テクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
手順
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 を利用できるかどうかを制御します。
-
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
注記Knative サービスで永続ストレージを正常に使用するには、Knative コンテナーユーザーのユーザー権限などの追加の設定が必要です。
6.1.12. init コンテナーの有効化
Init コンテナー は、Pod 内のアプリケーションコンテナーの前に実行される特殊なコンテナーです。これらは通常、アプリケーションの初期化ロジックを実装するために使用されます。これには、セットアップスクリプトの実行や、必要な設定のダウンロードが含まれる場合があります。KnativeServing
カスタムリソース (CR) を変更することにより、Knative サービスの init コンテナーの使用を有効にできます。
Knative サービスの初期化コンテナーはテクノロジープレビュー機能のみです。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は実稼働環境でこれらを使用することを推奨していません。テクノロジープレビューの機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行いフィードバックを提供していただくことを目的としています。
Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。
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.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 がクラスターにインストールされている。
手順
シークレットを作成します。
コマンドの例
$ oc -n knative-serving create secret generic custom-secret --from-file=<secret_name>.crt=<path_to_certificate>
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