第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 チャネルを使用する場合は、クラスターに
KnativeKafkaCR もインストールする必要があります。
手順
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 チャネルをデフォルトのバッキングチャネルタイプとして使用する場合は、クラスターに
KnativeKafkaCR もインストールする必要があります。
手順
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: KafkaChannel2 spec: numPartitions: 63 replicationFactor: 34 更新された
KnativeEventingCR を適用します。$ 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 ブローカーをデフォルトのブローカー実装として使用する場合は、クラスターに
KnativeKafkaCR もインストールする必要があります。
手順
KnativeEventingカスタムリソースを変更して、config-br-defaults設定マップの設定の詳細を追加します。apiVersion: operator.knative.dev/v1alpha1 kind: KnativeEventing metadata: name: knative-eventing namespace: knative-eventing spec: defaultBrokerClass: Kafka1 config:2 config-br-defaults:3 default-br-config: | clusterDefault:4 brokerClass: Kafka apiVersion: v1 kind: ConfigMap name: kafka-broker-config5 namespace: knative-eventing6 namespaceDefaults:7 my-namespace: brokerClass: MTChannelBasedBroker apiVersion: v1 kind: ConfigMap name: config-br-default-channel8 namespace: knative-eventing9 ...- 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-namespacenamespace のデフォルトのブローカークラスの実装は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: false3 注記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 がクラスターにインストールされている。
- クラスター管理者パーミッションがある。
手順
KnativeServingCR に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